The Ultimate List of 100+ Types of Software Testing
In this post ‘Types of Software Testing’, I would like to mention almost all the software testing types at one place. One challenge to learning about software testing is that there are many terms in the industry, and these terms often used inconsistently. While there is no universally-accepted definitions for all the testing terms, I think a good source is to refer ISTQB Certified Tester Foundation Level Syllabus.
100+ Types of Software Testing
The Ultimate list of Types of Testing:
Let’s see different Types of Software Testing one by one.
1. Functional testing: In simple words, what the system actually does is functional testing. To verify that each function of the software application behaves as specified in the requirement document. Testing all the functionalities by providing appropriate input to verify whether the actual output is matching the expected output or not. It falls within the scope of black box testing and the testers need not concern about the source code of the application.
2. Non-functional testing: In simple words, how well the system performs is non-functionality testing. Non-functional testing refers to various aspects of the software such as performance, load, stress, scalability, security, compatibility etc., Main focus is to improve the user experience on how fast the system responds to a request.
3. Manual testing: Manual testing is the process of testing the software manually to find the defects. A tester should have the perspective of an end user and to ensure all the features are working as mentioned in the requirement document. In this process, testers execute the test cases and generate the reports manually without using any automation tools.
4. Automated testing: Automation testing is the process of testing the software using an automation tool to find the defects. In this process, executing the test scripts and generating the results are performed automatically by automation tools. Some most popular tools to do automation testing are HP QTP/UFT, Selenium WebDriver, etc.,
Learn the Difference between Manual & Automated Testing here…
5. Black box testing: Black Box Testing is a software testing method in which testers evaluate the functionality of the software under test without looking at the internal code structure. This can be applied to every level of software testing such as Unit, Integration, System and Acceptance Testing.
6. Glass box testing – Refer white box testing
7. White box testing: White Box Testing is also called as Glass Box, Clear Box, and Structural Testing. It is based on applications internal code structure. In white-box testing, an internal perspective of the system, as well as programming skills, are used to design test cases. This testing usually was done at the unit level.
8. Specification-based testing: Refer black-box testing.
9. Structure-based testing: Refer white-box testing.
10. Gray box testing: Grey box is the combination of both White Box and Black Box Testing. The tester who works on this type of testing needs to have access to design documents. This helps to create better test cases in this process.
11. Unit testing: Unit Testing is also called Module Testing or Component Testing. It is done to check whether the individual unit or module of the source code is working properly. It is done by the developers in the developer’s environment.
12. Component testing: Refer Unit Testing
13. Module testing: Refer Unit Testing
14. Integration testing: Integration Testing is the process of testing the interface between the two software units. Integration testing is done by multiple approaches such Big Bang Approach, Top-Down Approach, Bottom-Up Approach, and Hybrid Integration approach.
15. System testing: Testing the fully integrated application to evaluate the system’s compliance with its specified requirements is called System Testing AKA End to End testing. Verifying the completed system to ensure that the application works as intended or not.
16. Acceptance testing: It is also known as pre-production testing. This is done by the end users along with the testers to validate the functionality of the application. After successful acceptance testing. Formal testing conducted to determine whether an application is developed as per the requirement. It allows the customer to accept or reject the application. Types of acceptance testing are Alpha, Beta & Gamma.
17. Big bang Integration Testing: Combining all the modules once and verifying the functionality after completion of individual module testing.
Top down and bottom up are carried out by using dummy modules known as Stubs and Drivers. These Stubs and Drivers are used to stand-in for missing components to simulate data communication between modules.
18. Top-down Integration Testing: Testing takes place from top to bottom. High-level modules are tested first and then low-level modules and finally integrating the low-level modules to a high level to ensure the system is working as intended. Stubs are used as a temporary module if a module is not ready for integration testing.
19. Bottom-up Integration Testing: It is a reciprocate of the Top-Down Approach. Testing takes place from bottom to up. Lowest level modules are tested first and then high-level modules and finally integrating the high-level modules to a low level to ensure the system is working as intended. Drivers are used as a temporary module for integration testing.
20. Hybrid Integration Testing: Hybrid integration testing is the combination of both Top-down and bottom-up integration testing.
21. Alpha testing: Alpha testing is done by the in-house developers (who developed the software) and testers. Sometimes alpha testing is done by the client or outsourcing team with the presence of developers or testers.
22. Beta testing: Beta testing is done by a limited number of end users before delivery. Usually, it is done in the client place.
23. Gamma Testing: Gamma testing is done when the software is ready for release with specified requirements. It is done at the client place. It is done directly by skipping all the in-house testing activities.
24. Equivalence partitioning testing: Equivalence Partitioning is also known as Equivalence Class Partitioning. In equivalence partitioning, inputs to the software or system are divided into groups that are expected to exhibit similar behavior, so they are likely to be proposed in the same way. Hence selecting one input from each group to design the test cases.
25. Boundary value analysis testing: Boundary value analysis (BVA) is based on testing the boundary values of valid and invalid partitions. The Behavior at the edge of each equivalence partition is more likely to be incorrect than the behavior within the partition, so boundaries are an area where testing is likely to yield defects. Every partition has its maximum and minimum values and these maximum and minimum values are the boundary values of a partition. A boundary value for a valid partition is a valid boundary value. Similarly, a boundary value for an invalid partition is an invalid boundary value.
26. Decision tables testing: Decision Table is aka Cause-Effect Table. This test technique is appropriate for functionalities which has logical relationships between inputs (if-else logic). In Decision table technique, we deal with combinations of inputs. To identify the test cases with decision table, we consider conditions and actions. We take conditions as inputs and actions as outputs.
27. Cause-effect graph testing– Refer Decision Table Testing
28. State transition testing: Using state transition testing, we pick test cases from an application where we need to test different system transitions. We can apply this when an application gives a different output for the same input, depending on what has happened in the earlier state.
29. Exhaustive Testing: Testing all the functionalities using all valid and invalid inputs and preconditions is known as Exhaustive testing.
30. Early Testing: Defects detected in early phases of SDLC are less expensive to fix. So conducting early testing reduces the cost of fixing defects.
31. Use case testing: Use case testing is carried out with the help of use case document. It is done to identify test scenarios to test end to end testing
32. Scenario testing: Scenario testing is a software testing technique which is based on a scenario. It involves in converting business requirements to test scenarios for better understanding and achieve end to end testing. A well designed scenario should be motivating, credible, complex and the outcome of which is easy to evaluate.
33. Documentation testing: Documentation testing is done to validate the documented artifacts such as requirements, test plan, traceability matrix, test cases.
34. Statement coverage testing: Statement coverage testing is a white box testing technique which is to validate whether each and every statement in the code is executed at least once.
35. Decision coverage testing/branch coverage testing: Decision coverage or branch coverage testing is a white box testing technique which is to validate every possible branch is executed at least once.
36. Path testing: Path coverage testing is a white box testing technique which is to validate that all the paths of the program are executed at least once.
37. Mutation testing: Mutation testing is a type of white box testing which is to change (mutate) certain statements in the source code and verify if the tests are able to find the errors.
38. Loop testing: Loop testing is a white box testing technique which is to validate the different kind of loops such as simple loops, nested loops, concatenated loops and unstructured loops.
39. Performance testing: This type of testing determines or validates the speed, scalability, and/or stability characteristics of the system or application under test. Performance is concerned with achieving response times, throughput, and resource-utilization levels that meet the performance objectives for the project or product.
40. Load testing: It is to verify that the system/application can handle the expected number of transactions and to verify the system/application behavior under both normal and peak load conditions.
41. Stress testing: It is to verify the behavior of the system once the load increases more than its design expectations.
42. Soak testing: Running a system at high load for a prolonged period of time to identify the performance problems is called Soak Testing.
43. Endurance testing: Refer Soak testing
44. Stability testing: Refer Soak testing
45. Scalability Testing: Scalability testing is a type of non-functional testing. It is to determine how the application under test scales with increasing workload.
46. Volume testing: It is to verify that the system/application can handle a large amount of data
47. Robustness testing: Robustness testing is a type of testing that is performed to validate the robustness of the application.
48. Vulnerability testing: Vulnerability testing is the process of identifying the vulnerabilities or weakness in the application.
49. Adhoc testing: Ad-hoc testing is quite opposite to the formal testing. It is an informal testing type. In Adhoc testing, testers randomly test the application without following any documents and test design techniques. This testing is primarily performed if the knowledge of testers in the application under test is very high. Testers randomly test the application without any test cases or any business requirement document.
50. Exploratory testing: Usually, this process will be carried out by domain experts. They perform testing just by exploring the functionalities of the application without having the knowledge of the requirements.
51. Retesting: To ensure that the defects which were found and posted in the earlier build were fixed or not in the current build. Say, Build 1.0 was released. Test team found some defects (Defect Id 1.0.1, 1.0.2) and posted. Build 1.1 was released, now testing the defects 1.0.1 and 1.0.2 in this build is retesting.
52. Regression testing: Repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the changes in the software being tested or in another related or unrelated software components.
53. Smoke testing: Smoke Testing is done to make sure if the build we received from the development team is testable or not. It is also called as “Day 0” check. It is done at the “build level”. It helps not to waste the testing time to simply testing the whole application when the key features don’t work or the key bugs have not been fixed yet.
54. Sanity testing: Sanity Testing is done during the release phase to check for the main functionalities of the application without going deeper. It is also called as a subset of Regression testing. It is done at the “release level”. At times due to release time constraints rigorous regression testing can’t be done to the build, sanity testing does that part by checking main functionalities.
55. Dynamic testing: Dynamic testing involves in the execution of code. It validates the output with the expected outcome
56. Static testing: Static Testing involves in reviewing the documents to identify the defects in the early stages of SDLC.
57. Monkey testing: Perform abnormal action on the application deliberately in order to verify the stability of the application.
58. Gorilla testing: Gorilla testing is done by testers, sometimes developers also join hands with testers. It involves testing a system repeatedly to test the robustness of the system.
59. Usability testing: To verify whether the application is user-friendly or not and was comfortably used by an end user or not. The main focus in this testing is to check whether the end user can understand and operate the application easily or not. An application should be self-exploratory and must not require training to operate it.
60. Accessibility testing: Accessibility testing is a subset of usability testing. It aims to discover how easily the people with disabilities (such as visual Impairments, Physical Impairment, Hearing Impairment, Cognitive Impairment, Learning Impairment) can use a system.
61. Compatibility testing: It is to deploy and check whether the application is working as expected in a different combination of environmental components.
62. Configuration testing: Configuration testing is the process of testing an application with each one of the supported hardware and software configurations to find out whether the application can work without any issues.
63. Localization testing: Localization is a process of adapting globalization software for a specific region or language by adding local specific components.
64. Globalization testing: Globalization is a process of designing a software application so that it can be adapted to various languages and regions without any changes.
65. Internationalization testing– Refer Globalization testing
66. Positive Testing: It is to determine what system supposed to do. It helps to check whether the application is justifying the requirements or not.
67. Negative testing: It is to determine what system not supposed to do. It helps to find the defects from the software.
68. Security testing: Security testing is a process to determine whether the system protects data and maintains functionality as intended.
69. Penetration testing: Penetration testing is also known as pen testing. It is a type of security testing. It is performed to evaluate the security of the system.
70. Database testing: Data base testing is done to validate the data in the UI is matched with the data stored in the database. It involves in checking the schema, tables, triggers etc., of the database.
71. Bucket Testing: Bucket testing is a method to compare two versions of an application against each other to determine which one performs better.
72. A/B testing: Refer Bucket Testing…
73. Split testing– Refer bucket testing…
74. Reliability Testing: Perform testing on the application continuously for long period of time in order to verify the stability of the application
75. Interface Testing: Interface testing is performed to evaluate whether two intended modules pass data and communicate correctly to one another.
76. Concurrency testing: Concurrency testing means accessing the application at the same time by multiple users to ensure the stability of the system. This is mainly used to identify deadlock issues.
77. Fuzz testing: Fuzz testing is used to identify coding errors and security loopholes in an application. By inputting massive amount of random data to the system in an attempt to make it crash to identify if anything breaks in the application.
78. GUI Testing: Graphical User Interface Testing is to test the interface between the application and the end user. Mainly testers concern about appearance of the elements such as fonts and colors conforms to design specifications.
79. API testing: API stands for Application Programming Interface. API testing is a type of software testing that involves testing APIs using some tools like SOAPUI, PostMan.
80. Agile testing: Agile testing is a type of testing that involves following principles of agile software development methodology. In this agile testing, testing is conducted throughout the lifecycle of the continuously evolving project instead of being confined to a particular phase.
81. End to end testing– Refer system testing…
82. Recovery testing: Recovery testing is performed in order to determine how quickly the system can recover after the system crash or hardware failure. It comes under the type of non-functional testing.
83. Risk-based testing: Identify the modules or functionalities which are most likely cause failures and then testing those functionalities.
84. Installation testing: It is to check whether the application is successfully installed and it is working as expected after installation.
85. Formal Testing: It is a process where the testers test the application by having pre-planned procedures and proper documentation.
86. Pilot testing: Pilot testing is testing carried out under a real-time operating condition by the company in order to gain the confidence of the client
87. Backend testing: Refer Database testing…
88. Cross-browser testing: Cross Browser Testing is a type of non-functional test which helps us to ensure that our website or web application works as expected in various web browsers.
89. Browser compatibility testing: Refer browser compatibility testing…
90. Forward compatibility testing: Forward compatibility testing is to validate the application under test is working as intended in the later versions of software’s current version.
91. Backward compatibility testing: Backward compatibility testing is to validate the application under test is working as intended in the earlier versions of software’s current version.
92. Downward compatibility testing: Refer Backward compatibility testing…
93. Compliance testing: Compliance testing is non-functional testing which is done to validate whether the software meets a defined set of standards.
94. Conformance testing: Refer compliance testing…
95. UI testing: In UI testing, testers aim to test both GUI and Command Line Interfaces (CLIs)
Also, refer GUI Testing…
96. Destructive testing: Destructive testing is a testing technique which aims to validate the robustness of the application by testing continues until the application breaks.
97. Dependency testing: Dependency testing is a testing technique which examines the requirements of an application for pre-conditions, initial states, and configuration for the proper functioning of the application.
98. Crowdsourced testing: Crowdsourced testing is carried out by a community of expert quality assurance testers through an online platform.
99. ETL testing: ETL (Extract, Transform and Load) testing involves in validating the data movement from source to destination and verifying the data count in both source and destination and verifying data extraction, transformation and also verifying the table relations.
100. Data warehouse testing: Refer ETL testing…
101. Fault injection testing: Fault injection testing is a testing technique in which fault is intentionally introduced in the code in order to improve the test coverage.
102. Failover testing: Failover testing is a testing technique that validates a system’s ability to be able to allocate extra resource during the server failure and transferring of the processing part to back-up systems
103. All pair testing: All pair testing approach is to test the application with all possible combination of the values of input parameters.
104. Pairwise Testing: Refer All pair testing
Here I am going to conclude different types of software testing types. If you like this post, please share it with your friends.
Here I have hand-picked a few posts which will help you to learn more interview related stuff:
- Manual Testing Tutorial
- Agile Tutorial
- Manual Testing Interview Questions
- Agile Interview Questions
- Why You Choose Software Testing As A Career
- General Interview Questions
If you have any more question, feel free to ask via comments. If you find this post useful, do share it with your friends on Social Networking.