It is one of the Non-Functional Testing. In this testing, documents and specification used to create test cases are validated. The validation of requirements specifications is a baseline testing. A majority of the issues that could crop up during development phase is resolved by this testing by reviewing, brain-storming and identifying the gaps in the requirements before the requirement specification is signed-off.
Generally, The Development, QA and BA team will work together on this during the Requirements Phase. The requirements gathering may be iterated until the gaps are bridged that brings consensus among the teams. Every amendment is performed keeping the client in loop and with their consensus. Then the requirements are frozen for sign-off.
Basis Path Testing:
A white-box test case design technique that uses the algorithmic flow of the program to design tests for every execution path of code.
Backward Compatibility Testing:
Performed to check newer version of the software can work successfully installed over previous version and newer version works fine with the table structure, data structure and files that were created previous version of the software. See Forward Compatibility Testing also.
Tests that use representative sets (or different versions) of programs and data designed to evaluate the performance of software in a given configuration (Hardware and Operating Systems). See Comparison Testing also.
A formal testing conducted by end customers before releasing to market. A successful completion of Beta Testing confirms to customer acceptance of the software.
This test is performed after Alpha testing has been successfully performed. In beta testing a sample of the intended audience tests the application. Beta testing is also known as pre-release testing. Beta test versions of software are ideally distributed to a wide audience on the Web, partly to give the program a “real-world” test and partly to provide a preview of the next release. In this phase the audience will be testing the following:
- Users will install, run the application and send their feedback to the project team.
- Typographical errors, confusing application flow, and even crashes.
- Getting the feedback, the project team can fix the problems before releasing the software to the actual users.
- The more issues you fix that solve real user problems, the higher the quality of your application will be.
- Having a higher-quality application when you release to the general public will increase customer satisfaction.
Binary Portability Testing:
Testing an executable application for portability across system platforms and environments, usually for conformation to an Application Binary Interface (ABI) specification.
Big Bang Testing:
This is a type of Integration Testing where almost all modules or components or sub-systems are completely developed and integrated or coupled, and testing is performed for intactness of the sub-systems in conjunction with the co-existence of other sub-systems. See Integration Testing also.
Black Box Testing:
The technique of testing based on an analysis of the specification of a piece of software without having any knowledge of the interior workings of the application is Black Box testing. The goal is to test how well the component conforms to the published requirements for the component.
The tester is oblivious to the system architecture and does not have access to the source code. Typically, when performing a black box test, a tester will interact with the system’s user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.
Software API’s are also tested in black-box way by passing the appropriate inputs (both positive and negative) and verify the expected output and expected exceptions. This needs a little bit of coding to call the API to pass the input, but need not know the internal structure of the API. Also few APIs can be pipelined to perform a full or part functional flow and test the same. This kind of testing is called Black-Box API/Unit Testing. See White-Box API/Unit Testing also.
Note: For every event happening through UI (front-end), there is a relevant API call happening in the back-end. So any functionality tested through UI can also be tested by pipelining the respective APIs and achieve the same functional outcome, and can be benchmarked against each other for the correctness.
An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested. See Integration Testing also.
Boundary Value Testing:
Test based on “error aggregates at boundaries”, which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests). If the field accepts value from 1 to 100 then testing is performed for values 0, 1, 2, 99, 100 and 101. Here the test should fail for 0 and 101 and pass for the rest.
This is a White-Box approach, testing all branches in the program source code are tested at least once during Unit Testing.
A test suite that exercises the full functionality of a product but does not test features in detail.
Browser Compatibility Testing:
This is a subset of Compatibility Testing wherein web applications are tested with combination of different browsers and operating systems. This is performed to ensure the Web UI Objects are correctly rendered and functional.