Random Testing Questions

What is a test bed?

A test bed is a test environment used for testing an application. A test bed configuration can consist of the hardware and software requirement of the application under test including - operating system, hardware configurations, software configurations, tomcat, database etc.

What is defect density?

Defect density is the measure of density of the defects in the system. It can be calculated by dividing number of defect identified by the total number of line of code(or methods or classes) in the application or program.


Severity: It is the extent to which the defect can affect the software.
Priority: Priority defines the order in which we should resolve a defect. Should we fix it now, or can it wait?
Give an example of Low priority-Low severity, Low priority-High severity, High priority-Low severity, High priority-High severity defects.
  1. Low priority-Low severity - A spelling mistake in a page not frequently navigated by users.
  2. Low priority-High severity - Application crashing in some very corner case.
  3. High priority-Low severity - Slight change in logo color or spelling mistake in company name.
  4. High priority-High severity - Issue with login functionality.

What is a blocker?

A blocker is a bug of high priority and high severity. It prevents or blocks testing of some other major portion of the application as well.

What is stub?

In case of top-down integration testing, many times lower level modules are not developed while beginning testing/integration with top level modules. In those cases Stubs or dummy modules are used that simulate the working of modules by providing hardcoded or expected output based on the input values.

What is driver?

In case of bottom-up integration testing, drivers are used to simulate the working of top level modules in order to test the related modules lower in the hierarchy.

What is Difference between Ad-hoc and Monkey Testing?

Ad-hoc Testing is performed without any planning or preparation. After the program is functional, the programmer or tester will test the software using his knowledge of the program. Monkey Testing is similar to Ad hoc Testing. However, it can be done without any knowledge or information about the software.
What is the difference between regression and retesting?

Regression testing involves testing the application to verify that a new code change doesn't affect the other parts of the application. Whereas, in retesting, we verify if the fixed issue is resolved or not.

What is code coverage?

Code coverage is the measure of the amount of code covered by the test scripts. It gives the idea of the part of the application covered by the test suite.
What is cyclomatic complexity?

Cyclomatic complexity is the measure of the number of independent paths in an application or program. This metric provides an indication of the amount of effort required to test complete functionality. It can be defined by the expression - 
L – N + 2P, where: 
L is the number of edges in the graph 
N is the number of node 
P is the number of disconnected parts
What is the difference between testing and debugging?

Testing is the primarily performed by testing team in order to find the defects in the system. Whereas, debugging is an activity performed by development team. In debugging the cause of defect is located and fixed. Thus removing the defect and preventing any future occurrence of the defect as well. 

What is an exit criteria?

Exit criterion is used to determine whether a given test activity has been completed or NOT. Exit criteria can be defined for all of the test activities right from planning, specification and execution. Exit criterion should be part of test plan and decided in the planning stage.

What is Requirement Trace-ability Matrix(RTM)?

Requirement Traceability Matrix or RTM captures all requirements proposed by the client or development team and their traceability in a single document delivered at the conclusion of the life-cycle.
In other words, it is a document that maps and traces user requirement with test cases. The main purpose of Requirement Traceability Matrix is to see that all test cases are covered so that no functionality should miss while testing.






All Types of Software Testing

In this post, we will try to cover each type of software testing and also categorize them based on different parameters.

Depending on the objective of testing

1. Functional testing - Functional testing is a type of testing that involves validating the application with its functional specifications or the business requirements.

2. Non-functional testing - Non functional testing includes testing the non-functional requirements of the system like performance, security, scalability, usability, robustness etc.

Based on test execution method - manual or automated

3. Manual testing - Manual testing is a type of testing in which test case execution is performed manually by humans.

4. Automated testing - Automation testing is a type of testing in which automated test case execution is performed using different automation tools and scripts.

Based on test design technique

5. Black box testing - Black box testing is a type of testing in which the tester is not required to have any knowledge of the internal architecture or implementation of the system.

6. White box testing - White box testing is a type of testing in which the tester analyses the internal architecture of the system as well as the quality of source code on different parameters like code optimization, code coverage, code reusability etc.

7. Glass box testing - Same as white box testing

8. Gray box testing - In gray box testing, the tester has partial access to the internal architecture of the system e.g. the tester may have access to the design documents or database structure. This information helps tester to test the application better.

9. Specification based testing - Same as black-box testing.

10. Structure based testing - Same as white-box testing.

Levels of testing





11. Unit testing - Unit Testing is the first level of testing usually performed by the developers. In unit testing, a module or component is tested in isolation.

12. Integration testing - Integration testing is the testing of a group of related modules. It aims at finding interfacing issues between the modules.

13. System testing - System testing is the level of testing where the complete integrated application is tested as a whole. It aims at determining if the application conforms to its business requirements.

14. Acceptance testing - Acceptance testing is the final and one of the most important levels of testing on successful completion of which the application is released to production.

Type of integration testing

15. Big bang Integration Testing - In big bang integration testing, testing starts only after all the modules are integrated.

16. Top-down Integration Testing - In top down integration, testing/integration starts from top modules to lower level modules.

17. Bottom-up Integration Testing - In bottom up integration, testing starts from lower level modules to higher level module up in the heirarchy.

18. Hybrid Integration Testing - Hybrid integration testing is the combination of both Top-down and bottom up integration testing. In this approach the integration starts from middle layer and testing is carried out in both the direction

Type of acceptance testing

19. Alpha testing - Alpha testing is a type of acceptance testing that is performed end users at the developer site.

20. Beta testing - Beta testing is the testing done by end users at end user's site. It allows users to provide direct input about the software to the development company.

Black box testing or specification based testing types

21. Equivalence partitioning testing - Grouping test data into logical groups or equivalence classes with the assumpation that any all the data items lying in the classes will have same effect on the application.

22. Boundary value analysis testing - Testing using the boundary values of the equivalence classes taken as the test input.

23. Decision tables testing - Testing using decision tables showing application's behaviour based on different combination of input values.

24. Cause-effect graph testing - Testing using graphical representation of input i.e. cause and output i.e. effect is used for test designing.

25. State transition testing - Testing based on state machine model.

26. Use case testing - Testing carried out using use cases.

White-box or structural testing types

{These testing types are performed by devs and white-box testers only, feel free to ignore these in case you are not into white-box testing}
27. Statement testing - Test scripts are designed to execute code statements and coverage is the measure of line of code or statements executed by test scripts.

28. Decision testing/branch testing - Measure of the percentage of decision points(e.g. if-else conditions) executed out of the total decision points in the application.

29. Condition testing - Testing the condition outcomes(TRUE or FALSE). So, getting 100% condition coverage required exercising each condition for both TRUE and FALSE results using test scripts(For n conditions we will have 2n test scripts).

30. Multiple condition testing - Testing the different combinations of condition outcomes. Hence for 100% coverage we will have 2^n test scripts. This is very exhaustive and very difficult to achieve 100% coverage.

31. Condition determination testing - It is an optimized way of multiple condition testing in which the combinations which doesn't affect the outcomes are discarded.

32. Path testing - Testing the independent paths in the system(paths are executable statements from entry to exit points).

33. Mutation testing - Mutation testing is a type of white box testing in which the source code of the application is mutated to cause some defect in its working. After that the test scripts are executed to check for their correctness by verifying the failures caused the mutant code.

34. Loop testing - Loop testing is a type of white box testing in which primarily focus on validating the different kinds of loop constructs.

Performance testing types

35. Performance testing - Performance testing is type of testing performed to evaluate the different performance attributes of the application like - responsiveness, stability, reliability etc. For determining these attributes, we have different types of performance testing techni

36. Load testing - Load testing is a type of testing which involves evaluating the performance of the system under expected workload. A typical load test includes determining the response time, throughput, error rate etc during the course of the load test.

37. Stress testing - Stress testing is a type of performance testing where we evaluate application's performance at load much higher than the expected load. Another aspect of the stress testing is to determine the breakpoint of the application, the point at which the application fails to respond in correct manner.

38. Endurance testing - Endurance testing is also known as 'Soak Testing'. It is done to determine if the system can sustain the continuous expected load for long durations. Issues like memory leakage are found with endurance testing.

39. Soak testing - Same as endurance testing.

40. Stability testing - Same as endurance testing

41. Spike testing - In spike testing, we analyze the behavior of the system on suddenly increasing the number of users. It also involves checking if the application is able to recover after the sudden burst of users.

42. Volume testing - Volume testing is performed by feeding the application with high volume of data. The application can be tested with large amount of data inserted in the database or by providing a large file to the application for processing. Using volume testing, we can identify the bottleneck in the application with high volume of data.

Experience based testing

43. Experience based testing - The experienced based testing techniques are completely based on the experience or intution of the tester. Two most common forms of experienced based testing are - adhoc testing and exploratory testing.

44. Adhoc testing - Adhoc testing is an unstructured way of testing that is performed without any formal documentation or proper planning.

45. Exploratory testing - Exploratory testing is a type of testing in which new test case are added and updated while exploring the system or executing test cases. Unlike scripted testing, test design and execution goes parallely in exploratory testing.

All other types of testing

46. Retesting - Retesting is a type of testing in which we verify if the fixed issue is resolved or not.

47. Regression testing - Regression testing includes testing the application to verify that a new code change doesn't affect the other parts of the application.

48. Smoke testing - Smoke testing is a type of testing in which the all major functionalities of the application are tested before carrying out exhaustive testing.

49. Sanity testing - Sanity testing is the subset of regression testing, which is carried out when there is some minor fix in application in a new build.

50. Dynamic testing - Testing performed by executing or running the application under test either manually or using automation (opposite of reviews and walk- throughs).

51. Static testing - Static testing is a type of testing in which testing is carried out without actually running the code. It involves activities like reviews, inspections and walk-throughs.

52. Monkey testing - Monkey testing is a type of testing that is performed randomly without any predefined test cases or test inputs.

53. Gorilla testing - Gorilla testing involves testing an individual module or functionality of the application heavily in order to test its robustness.

Usability testing - Usability testing is the type of testing that aims at determining the extent to which the application is easy to understand and use.

54. Accessibility testing - Accessibility is the type of testing which aims at determining the ease of use or operation of the application specifically for the people with disabilities.

55. Compatibity testing - Testing software to see how compatible the software is with a particular environment - Operating system, platform or hardware.

56. Configuration testing - Configuration testing is the type of testing used to evaluate the configurational requirements of the software along with effect of changing the required configuration.

57. Localisation testing - Localisation testing is a type of testing in which we evaluate the application's customization(localized version of application) to a particular culture or locale. Generally the content of the application is checked for updation(e.g. content language).

58. Globalisation testing - Globalisation testing is a type of testing in which application is evaluated for its functioning across the world.

59. Internationalization testing - Same as globalisation testing

60. Negative testing - Negative testing is a type of testing in which the application's robustness(graceful exiting or error reporting) is evaluated when provided with invalid input or test data.

61. Security testing - Security testing is a type of testing which aims at evaluating the integrity, authentication, authorization, availabilty, confidentiality and non-repudation of the application under test.

62. Penetration testing - Penetration testing or pen testing is a type of security testing in which application is evaluated(safely exploited) for different kinds of vulnerabilities that any hacker could expolit.

63. Crowdsourced testing - Crowdsourced testing is a type of testing which is carried out by a large group or community of QA professionals instead of in-house QAs or hired QA consultants.

64. Databse testing - Database testing is checking the integrity of actual data in the front end with the data present in the database. It involves validating the data in the database, checking that there are no orphan records (record with a foreign key to a parent record that has been deleted"), no junk records are present, updating records in database and verify the value in the front end.

65. API testing - API testing is a type of testing that involves testing of the Restful APIs and SOAP webservices directly using some client like Advanced Rest Client or tools like SOAPUI.

66. ETL testing - ETL(Extract-Transform-Load) testing is a type of testing that involves checking the consitency of data after extraction from source to destination.

67. Data warehouse testing - Same as ETL testing.

68. Robustness testing - Robustness testing is a type of testing that is performed to find the robustness of the application i.e. the ability of the system to behave gracefully in case of erroneous test steps and test input.

69. A/B testing - A/B testing is a type of testing in which the two variants of the software product are exposed to the end users and on analysing the user behaviour on each variant the better variant is chosen and used thereafter.

70. Concurrency testing - Concurrency testing is a multi-user testing in which an application is evaluated by analyzing application's behaviour with concurent users acccessing the same functioanity.

71. All pair testing - All pair testing is a type of testing in which the application is tested with all possible combination of the values of input parameters.

72. Failover testing - Failover testing is a type of testing that is used to verify application's ability to allocate more resources(more servers) in case of failure and transfering of the processing part to back-up system.

73. Fuzz testing - Fuzz testing is a type of testing in which large amount of random data is provided as input to the application in order to find security loopholes and other issues in the application.

73. Fault injection testing - Fault injection testing is a type of testing in which fault is intentionally introduced in the application in order to improve the test coverage.

74. UI testing - UI or user interface testing is a type of testing that aims at finding Graphical User Interface defects in the application and checks that the GUI conforms to the specifications.

75. Pilot testing - Pilot testing is a testing carried out as a trial by limited number of users evaluate the system and provide their feedback before the complete deployment is carried out.

76. Backend testing - Backend testing is a type of testing that invloves testing the backend of the system which comprises of testing the databases and the APIs in the application.

77. Compatibility testing - Compatibility testing is a type of non-functional testing that invloves checking the compatibility of the application with different environment factors like - operating system, hardware, browser, network, devices, software versions etc.

78. Browser compatibility testing - Browser compatibility testing is a type of testing that invloves validating the correctness and consistency of the application over different browsers.

79. Cross-browser testing - Same as browser compatibility testing.

80. Forward compatibility testing - Forward compatibility testing involves validating the application with newer version of the other platform or softwares.

81. Backward compatibility testing - Backward compatibility testing involves validating the application with older version of the other platform or softwares.

82. Downward compatibility testing - Same as Backward compatibility testing

83. Component testing - Component testing is a type of testing that is involves testing the functionality of the individual components or module of the application.

84. Module testing - Same as component testing

85. 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 continously evolving project instead of being confined to a particular phase.

86. End to end testing - End to end testing is a type of testing in which the application's flow is tested from start to end under real world scenarios in order to ensure that application works as per the requirement.

87. Happy path testing - Testing the positive or default flow of the application with valid input is called happy path testing.

88. Incremental testing - Incremental testing is also know as incremental integration testing. In this testing, integration between the modules is tested and on successful testing new modules are incrementlly added till the time each module of the application is integrated and tested.

89. Recovery testing - Recovery testing is a type of non-functional testing that involves testing the ability of the system to recover from a carsh or failure.

90. Risk based testing - Risk based testing is a type of testing in which test cases are prioritised on the basis of risk involved or the impact of the failure.

91. Vulnerability testing - Vulnerability testing involves testing and identification of the vulnerability or weakness in the application.

92. Compliance testing - Compliance testing is a type of non-functional testing that involves validating that the built product conforms the organization's standards and other

93. Conformance testing - Same as compliance testing

94. Destructive testing - A type of testing that aims at checking the robustness of the application by intentionally breaking or crashing the application.

95. Dependency testing - Dependency testing involves checking the pre-conditions or the initial state and configuration of teh system required for correct functioning of the application.

96. Scenario testing - Scenario testing is a type of testing in which testing of complex test flows is simplified by making use of scenarios i.e. user flows. It helps in testing the end to end flow of the application.

97. Installation testing - In installation testing, the installation process is checked based on the installation guide.

98. Documentation testing - Documentation testing involves reviewing and validating the documents and user manual of the system.

99. AB testing - AB testing is a way of creating and analyzing two varients of an application in order to find which varient performs better in terms of user experience, monetary benefits(e.g. for e-commerce application) or any xyz goal. And then eventually keeping the better performing varient.

100. Split testing - Same as AB testing

V Model

V Model

V model is also known as Verification and Validation model. In V model, the testing phase goes in parallel with the development phase. Thus, the testing phase starts right at the beginning of SDLC. 

 
                
As we can see in the above diagram, the test activities start in parallel with the development activities e.g. during the requirement analysis phase, acceptance-test cases are prepared by the testing team; during system design phase, the system test case are prepared. Similarly, for each phase of development a corresponding QA activity is performed. Later, when the deliverable gets ready, the QA artifacts are used to conduct the testing. Along with that, each phase of development phase is verified before moving to the next phase. 

Advantages of V Model

  • Each phase of development is tested before moving to next phase, hence there is higher rate of success.
  • It avoids defect leakage to the later phases as each phase is verified explicitely.
  • The model has clear and defined steps. So, it is easier to implement.
  • It is suitable for smaller projects where requirements are fixed.

Regression testing.

When a tested software undergoes a minor fix(or a fix that doesn't affect the whole application) then it is not advisable to conduct thorough testing of all the modules of the application. Instead, after a fix in a previously tested and working software, we only run a limited number of test cases while also ensuring proper test coverage. This type of testing is known as Regression testing.

Regression testing is the type of testing that is performed to ensure that a fix or change hasn't affected the previously working functionality.         

Smoke and Sanity testing

Smoke testing

Smoke testing is also known as "build verification" testing. It is performed right after the testing team receives the build. The functionality covered by the smoke tests are crucial, failing of which results in rejection of build. In short, we will execute the most crucial tests to make sure that the application can be considered suitable for further exhaustive testing or not.
Example- Smoke tests for some application like GMail will include test cases that are very critical to the app e.g. user should be able to login to the application, inbox should be populated with recieved mails, user should be able to send mail etc.

Sanity testing 

Sanity testing is the subset of regression testing. Like regression, in case of sanity testing, we check if a fix has not affected the other working functionalities of the application but in a lesser time and with lesser number of test cases. 
So, basically we perform sanity testing after receiving a fix (usually a minor fix). We check limited but critical part of functionality and then decide as to whether further testing is required or not.

Bug Life Cycle


A Bug life cycle is the movement of a bug or defect in different stages of its lifetime, right from the beginning when it is first identified till the time is marked as verified and closed.
Depending on the defect management tool used and the organisation, we can have different states as well different nomenclature for the states in the defect life cycle.


  • New - A bug or defect when detected is in New state
  • Assigned - The newly detected bug when assigned to the corresponding developer is in Assigned state
  • Open - When the developer works on the bug, the bug lies in Open state
  • Rejected/Not a bug - A bug lies in rejected state in case the developer feels the bug is not genuine
  • Deferred - The Bug to be fixed in next release are marked as Deferred.
  • Fixed/InTest - When a bug is resolved by the developer it is marked as fixed and assigned to the tester
  • Reopened - If the tester is not satisfied with issue resolution the bug is moved to Reopened state
  • Verified - After the Test phase if the tester feels bug is resolved, it is marked as verified
  • Closed - After the bug is verified, it is moved to Closed status.

What is "bug leakage?" and What is "bug release?"

A defect which exists during testing yet unfound by the tester which is eventually found by the end-user is also called bug leakage.

A bug release is when a particular version of s/w is released with a set of known bug(s)/defect(s). These bugs are usually low severity and/or low priority bugs. 






Test Scenario and Test Case

What is a Test Scenario?

A Test Scenario is generally a one line statement describing a feature of application to be tested. It is used for end to end testing of a feature and is generally derived from the use cases.
A single test scenario can cover one or more test cases i.e. it has a one to many relationship with test cases.        

What is a Test Case?

A test case is a set of conditions for evaluating a particular feature of a software product to determine its compliance with the business requirements. A test case has pre-requisites, input values and expected results in a documented form which cover the different test scenarios.

A test case can have following attributes-
  1. TestCaseId - A unique identifier of the test case.
  2. Test Summary - Oneliner summary of the test case.
  3. Description - Detailed description of the test case.
  4. Prerequisite or pre-condition - A set of prerequisites that must be followed before executing the test steps.
  5. Test Steps - Detailed steps for performing the test case.
  6. Expected result - The expected result in order to pass the test.
  7. Actual result - The actual result after executing the test steps.
  8. Test Result - Pass/Fail status of the test execution.
  9. Automation Status - Identifier of automation - whether the application is automated or not.
  10. Date - The test execution date.
  11. Executed by - Name of the person executing the test case.

Test Plan

What is a Test Plan?

A Test Plan is a formal document derived from requirement documents (Software Requirement Specification, Use Case documents etc.), describing in detail the scope of testing and the different activities performed in testing. It is generally prepared by a test manager and approved by the different stakeholders of the application.

Features of a Test Plan

A Test Plan needs to address the following-
  • Overall scope of testing
  • Risk Analysis
  • Test estimate
  • Resource Requirement
  • Tools used
  • Scheduling, review and analysis of test design activities
  • Creation of test cases and test data
  • Identification of test monitoring and test control activities

Test Plan Template

A test plan contains the following fields-

  • Test Plan Id - A unique identifier of the test plan and its different associated versions.
  • Introduction - A brief introduction to the application under test.
  • Purpose and scope - The overall purpose and scope of testing.
  • Testing Strategy - Describes the testing approach in the software development life cycle.
  • Features to be tested - Describes the features of the application to be tested.
  • Features not to be tested - Describes the feature not in the scope of testing.
  • Test deliverables - The different types of test artifacts to be delivered like test cases, test results etc.
  • Environmental needs - Any environment specific need of project.
  • Responsibilities - The resources involved in the testing process and their responsibilities.
  • Training needs - The project specific training requirements of different resources.
  • Schedule - The estimate or schedule of the test deliverables.
  • Risks and Mitigations - The different risks associated with the project and their mitigation strategies.
  • Tools - List of tools used (if any).
  • Approvals - The persons approving the test plan.

Test Strategy

What is Test Strategy?

A Test Strategy is a high-level document describing the way testing will be carried out. In a test strategy document, we document the test objectives and set of guidelines for achieving those objectives. It is presented by the project manager to all the stakeholders in the testing process. It can have a scope of an entire organization or a particular project.

Test Strategy Approaches

The the different apporaches to test strategy are-
  1. Analytical Approach - Based on the risk analysis
  2. Model-based Approach - Based on the various statistical models
  3. Consultative Approach - Based on the consultation with technology or domain experts
  4. Methodical Approach - Based on the experience
  5. Heuristic Approach - Based on the exploratory techniques
  6. Standard-compliant Approach - Based on the industry standards and processes

Test Strategy Document Template

A test strategy document can contain the following fields-

  • Test Strategy Id - An identifier of the test strategy document and its various versions.
  • Introduction - A brief introduction to the purpose and scope of the document.
  • Standards to use - The different standards or set of guidelines to be followed.
  • Risks and Mitigations - The different risks associated with in testing and their mitigation strategies.
  • Entry Critieria - The set of pre-requisite that must be performed before testing can start.
  • Exit Critieria - The criteria defining when the testing can be stopped.
  • Test design techniques - The test design techniques to be used like - equivalence partitioning, boundary value analysis etc.
  • Test environment - The test environment specifications.
  • Configuration management of testware - Specification of the right version of testware for testing.
  • Test process improvement - The apporaches to use for improving the test process.
  • Approvals - The persons approving the test strategy document.

Acceptance testing

Acceptance testing is the final level of software testing where the system is tested for compliance to its business requirements. It is performed by the client or the end users with the intention to see if the product is fit for delivery. It can be both formal(carried out by client's representatives) or informal/adhoc (carried out by subset of potential users to check features like usability of the product).
It is carried out after system testing and before final delivery to the client.

Two forms of Acceptance Testing

Alpha Testing

  • Alpha testing is the form of acceptance testing that takes place at the developer's site.
  • It can be carried out by both in-house developers and QAs as well as the potential end users as well.
  • Alpha testing is not open to the world.
  • These tests can also be white box along with black box tests.

Beta Testing


  • Beta testing is the form of acceptance testing that takes place at the customer's or the end user's site.
  • It is performed after alpha testing and in the real world environment without the presence or control of developers.
  • Beta tests or the beta version of the application are normally open to the whole world (or client)
  • These tests are only black box.

System testing

System testing is a type of testing where the application as a whole is tested for its compliance to functional and non-functional requirements. It is carried out by the QA team after the completion of integration testing and before the final acceptance testing. Since in system testing the whole system is tested end to end and the knowledge of coding or internal architecture is not required. Hence, system testing comes under Black-box Testing

Why do we need System Testing?

  • The system is tested as a whole in this phase of testing. Even after successful unit and integration testing, many complex scenarios may have issues undiscovered by earlier testing phases. System testing helps in uncovering those defects.
  • Both the functional as well as the non-functional requirements are tested for the whole system are tested for the first time in this phase.
  • The testing is carried on the product and environment that closely matches the final product and production environment. Hence, successful system testing brings a sense of confidence on the final delivered product.

Types of System Testing-


As stated earlier, in system testing both the functional and non-functional requirements of the system are evaluated. Hence, system testing involves different types of testing techniques which evaluates the whole system and its various attributes. The different type of system testing are- Functional testing, Performance testing, Usability testing, Reliability testing, Security testing, Scalability testing, Installation testing etc.

Integration testing

Integration testing is the second level testing performed after unit testing. In integration testing, we test the interfacing between the modules which are inter-connected with each other as well as the end to end testing of the integrated component. Integration testing can be performed by using both white box and black box testing techniques.


There are four approaches of performing integration testing namely top down, bottom up, big bang and hybrid integration. Let's see each approach one by one.

Big bang Integration Testing

In big bang integration, all the modules are first required to be completed and then integrated. After integration, testing is carried out on the integrated unit as a whole. It is different from system testing as here we focus testing on the interfacing/communication between the modules. 
The big bang approach is not very advisable and is followed for smaller projects only.

Top-down Integration Testing

Top-down integration testing is an incremental approach of integration testing where testing flow start from top level modules (modules higher in the hierarchy) towards the lower level modules. As there is very much possibility that the lower level modules might not have been developed while beginning with top level modules. So, in those cases Stubs are used. Stubs are dummy modules that simulate the functioning of a module by accepting the parameters received by the module and giving an acceptable result. Generally stubs have hard-coded input and output that helps in testing the other modules integrated with it.
The main advantage of top-down testing is - we don't have to wait for all the modules to get developed(using stubs that simulate the behavior of lower level modules).

Bottom-up Integration Testing

Bottom up integration testing is also based incremental approach and starts from lower level modules, moving upwards to the higher level modules. Again the higher level modules might not have been developed by the time lower modules are tested. So, in those cases Drivers are used. These drivers simulate the functionality of higher level modules in order to test lower level modules. 
The main advantage of bottom up integration testing is, similar to top-down testing, we don't have to wait for all the modules to get developed before starting testing.

Hybrid Integration Testing

Hybrid integration testing approach is also called Sandwich approach. This approach is combination of both top-down and bottom up integration testing. In this approach, the integration starts from middle layer and testing is carried out in both the directions - towards higher level modules(upwards) and towards lower level module(downwards). This way includes benefits of both top-down and bottom up approach and helps in faster testing of the module's interfaces.

Unit Testing

Unit testing is the first level of testing performed on individual modules, components or piece of code. In unit testing the individual modules are tested as independent components to ensure that they work correctly and are fit to be assembled/integrated with other components. This testing is performed by developers. The developers usually write unit tests for the piece of code written by them.

Unit testing cannot be performed manually. The unit tests are always automated and more specifically use White-box testing technique as the knowledge of the piece of code and internal architecture is required to test the code.

Advantages of Unit Testing

  • Defects within a module can be detected at earlier stages of development. Hence the cost of fixing the defects greatly reduces.
  • Unit testing improves testing efficiency and better resource utilisation as testing of a module can be started without having to wait for other modules to finish.
  • Exhaustive testing focusing on individual functionality is possible in unit testing.
  • Unit tests aid in faster development and debugging as the impact of new changes can be easily detected by running the unit tests.
  • Successful unit test report generates a sense of confidence about the quality of code. Modules successfully unit tested can be easily merged with other modules.

Limitations of Unit Testing


  • Unit testing cannot detect integration or interfacing issues between two modules.
  • It cannot catch complex errors in the system ranging multiple modules.
  • It cannot test non-functional attributes like usability, scalability, overall performance of the system etc.
  • Unit tests cannot guarantee functional correctness or conformance of application with its business requirements.