The main objective of testing is to find the early defects in the SDLC. If the defect is found early, then the cost will be lower than when the defect is found during the production or in the implementation stages. Moreover, testing is carried out to assure the quality and reliability of the software. In order to find the defect as soon as possible, the testing activities should start early, that is, in the Requirement phase of SDLC and continues till the end of the SDLC. The testing team should create the test cases based on the defined requirements.
The Coding phase of the SDLC includes various testing activities to validate and verify the functionality based on the design and the developer's code for the design. The developers themselves conduct the tests. In case of Test driven development, the test scripts and test scenarios are created first based on the requirement and the code is developed.
As soon as the developer completes the coding, the developer conducts the unit testing
Unit testing: This is the first level of testing in the SDLC. The developer takes the smallest piece or unit of testable code and determines whether the code behaves exactly as expected. In object-oriented programming, the smallest unit is a method which belongs to a class. The method usually has one or few inputs and one output. Frameworks, drivers, Stubs and mock, or fake objects are used to assist in unit testing.
Once the coding is complete for the agreed requirements, all the units are integrated and the product is built as a single package. Then the other phases or forms of testing are executed.
Integration testing: This type of testing is carried out between two or more modules or functions along with the intent of finding interface defects between them. This testing is completed as a part of unit or functional testing, and sometimes becomes its own standalone test phase. On a larger level, integration testing can involve putting together groups of modules and functions with the goal of completing and verifying that the system meets the system requirements. Defects found are logged and fixed later by the developers. There are different ways of integration testing such as top-down and bottom-up , which are as follows:
Top-down approach: This is the incremental testing technique which begins with the top level modules followed by low-level modules. The top-down approach helps in early detection of design errors which helps in saving development cost and time as the design errors can be fixed before implementation.
Bottom-up approach: This is exact opposite to the top-down approach. In this case the low level functionalities are tested and integrated first and then followed by the high level functionalities.
Umbrella approach: This approach uses both the top-down and bottom-up patterns. The inputs for functions are integrated in bottom-up approach and then the outputs for functions are integrated in the top-down approach.
System testing: This type of testing is used for comparing or verifying the specifications against the developed system. The system test design is derived from the design documents and is used in this phase for planning and executing the tests. System testing is conducted after all the modules are integrated and completed with Integration testing. To avoid repeating the same process during multiple cycles of system testing, the tests are automated using automation testing tools. Once all the modules are integrated, several errors may arise because of dependencies and various other factors. The defects are usually maintained using a defect tracking tool and the development team prioritizes and fixes the defects. There are different types of testing followed under system testing, but they differ from organization to organization. Here are the common types of tests widely followed in the industry:
Sanity testing: Whenever there are some defect fixes to the existing product and because of that a new build is created, sanity test is conducted on that build instead of performing full testing on the software. Sanity test is conducted to make sure that the existing functionality of the product is not impacted or broken because of the defect fixes.
Regression testing: The main objective of this type is to determine if defect fixes or any other changes have been successful and have not introduced any new defects. This is also to verify if the existing functionalities are not affected.