Overview

Overview

Welcome to QTP interview questions

Hello software Quality engineers. Welcome to our Software testing world and common QTP(Quick test pro) related technical issues, interview questions etc. . Over 2 years, I am trying to update all possible interview questions in testing area of QTP. With your continuous comments on the topics and suggestions, we are growing day by day.

White Box Testing

What is white box testing,  Grey box testing and Test coverage?
White box testing is when the tester has access to internal data structures and algorithms, including the code to implement.
Types of white box testing
    
The following types of white box testing are:

        
* Test API (application programming interface) - Monitoring the application using the API public and private
        
* Code coverage - creating tests to satisfy some criteria of code coverage (for example, the designer can create tests to prove that all statements in the program must be tested at least once)
        
* Methods of Fault Injection - improving the coverage of a test with the introduction of defects to test code paths
        
* Test methods mutation
        
* The static testing - White box testing includes all static testing
Test coverage
    
white box testing methods can be used to assess the completeness of a test suite that was created with black box testing methods. This software allows the team to review the parts of a system which are rarely tested and ensure that the points of the most important function was tested [24].

    
Two common forms of code coverage are:

        
* Function, which reports on work performed
        
* Declaration of coverage, which reports on the number of lines executed to complete the test
Both return a code coverage metric, measured in percentage. 


Grey Box Testing
gray box testing (American spelling: gray box testing) involves having access to internal data structures and algorithms for designing test cases, but the test user, or "box" black level. Handling input and output formatting are not considered gray area, because the input and output are clearly outside the "black box" that we call the system under test. This distinction is particularly important when performing integration testing between two modules of code written by two different developers, where only the interfaces are exposed to the test. However, changing a data repository is not considered gray zone, you should not normally be able to modify data outside the system under test. gray box testing can also include reverse engineering to determine, for example, limit values or error messages.