How can you handle exceptions in QTP?

Exception handling is one of the major features of any test automation and testing software suite. The same is with the HP’s quick test professional which is also a test automation and software testing suite. 

How exceptions are handled in QTP?

- The exception handling thing is managed by the quick test professional by means of some recovery scenarios. 

- The basic goal of exception handling in quick test professional is to have the tests running even if some unexpected failure is encountered. 

- There is some memory space associated with the applications that are tested. 

- This memory space is hooked by the HP quick test professional and this in turn gives rise to some exceptions which may cause the quick test professional to falter, terminate and become unrecoverable. 

- The recovery scenarios used by the quick test professional come in built with the whole software package. 

- But it is not always beneficial to rely on the recovery scenarios rather it is always better if you can handle the exceptions and errors yourself. 

- A recovery scenario manager is also available which has an in – built wizard using which you yourself can define you very own recovery scenarios. 

- This wizard can be accessed by going to the tools menu and then selecting the option “recovery scenario manager”. 

- These recovery scenarios deal in three steps as stated below:

1. Triggered events
2. Recovery steps and
3. Post recovery test run.

Some may think that using the recovery scenarios is the only option for handling the exception in quick test professional but it is not so.  

- Another option is which involves the use of descriptive programming.

- This approach is better than the former option since using it your application can gain more visibility and robustness. 

- Though, the recovery manager can be used for many scenarios but some of the real time scenarios cannot be handled using it. 

- In such cases descriptive programming is the alternative. 

- Third option will be make use of the exception handling capabilities of the visual basic script like the following:

1. Err object
2. On error resume next
3. On error go to 0 statements and so on.

- The last two can be used at the script level. 

- The in–built recovery scenario of the quick test professional supports only 4 exceptions:

1. Object state exceptions
2. Pop up exceptions
3. Application crash exceptions and
4. Test run error exceptions

- A simple example is when you play back the recorded script, the AUT screen is minimized and a run time error is generated as “object not visible”.

- A “test run handler” can be used for this. 

- Four trigger events have been defined during which the recovery manager is supposed to be used:

1. When  a pop up window appears while an application is open for the test run,
2. When the value or the state of a property of an object changes,
3. When a step in the test run becomes unsuccessful or fails terribly, and
4. When the open application itself fails while the test is in progress.

- All of the above mentioned 4 triggers are nothing but exceptions. 

- The quick test professional can be instructed accordingly regarding how to recover from an unexpected event or failure that occurred during the test run in the application development environment. 

- Separate individual files can be created for different scenarios as per the requirements. 

- If you search the web you can find an advance qtp script that can attach as well as enable the recovery scenario file when the test run is in progress. 

What are the types of Exception available in Win Runner? How do you handle an Exception in WinRunner?

In this article, we talk about the various kinds of exceptions available in winrunner and how to handle them. Basically 4 types of exceptions are available in winrunner and they have been mentioned below:

1. Pop up exceptions
2. Object exceptions
3. TSL exceptions and lastly
4. Web exceptions

Web exceptions are available only if you have installed the web add- ins.

How are different types of exceptions are handled in WinRunner?

- A pop up exception handler is provided in the wirunner package for handling the pop up exceptions that often show up during the execution of the test scripts during the running of acceptance user test.  

- Winrunner can be made to handle pop ups by making it learn the window and by specifying a handler for the exception. 

- These handlers can be:

1. User defined handlers: The names of these handlers can be specified by clicking on the user defined function name and changing it according to your own will.
2. Default actions: Winrunner makes its own choice whether to press ok or cancel option. The desired default handler can be selected in the dialog box.

What if your batch test is executing up on a highly unstable version of the software system or application? 

- Obviously it will crash and you would want to recover the test execution. 

- This is possible only through the TSL exceptions which help in the test recovery by instructing the winrunner to exit the current test and restart the application.

- The winrunner can be easily instructed upon how an unexpected event or error can be handled that may occur in the testing environment while you test your web site. 

Here now we explain how to handle such exceptions. 

- Whenever you load some web test add in, the winrunner can be very well instructed up on how a particular exception can be handled that occurred during a test run in your web site. 

- The simplest example that can be given is of the security alert dialog box that some times appears during the test run. 

- The user can resume the normal testing by clicking on the yes button of the security alert dialog box. 

- All the exceptions that are supported by the winrunner are mentioned in a list and can be viewed in the web exception editor.

- This list can be modified and additional exceptions that you want the winrunner to support can be configured and added to the list. 

- All the new exceptions are to be added to the list of exceptions stored in the web exception editor. 

- You need to go down to the tools menu and select the option of web exception handling.

- This opens the web exception editor. 

- There is a pointing hand, clicking on that adds a new exception to the list. 

- For categorizing the exception you need to select a category in the type list. 

- The MSW_class, message and title of the exception are displayed by the editor.

- There is an action list available which provides you the options for carrying out the following execution:

1. Web_ exception_ handler_ dialog_ click_ default: For activating the default button.
2. Web_ exception_ handler_ fall_ retry: For reloading the web page as well as activating the default button.
3. Web_ exception_ enter_ user name_ password: For using the given user id and password.
4. Web_ exception_ handler_ dialog_ click_ yes: For activating the yes button.
5. Web_ exception_ handler_ dialog_ click_ no: For activating the no button.

- The other operations that can be carried out in winrunner up on exceptions are defining, modifying, activating and deactivating them. 

What are different characteristics of white box testing?

White-box testing or clear box testing, transparent box testing, glass box testing, structural testing as it is also known can be defined as a method for testing software applications or programs.

White box testing includes techniques that are used to test the program or algorithmic structures and working of that particular software application in opposition to its functionalities or the results of its black box tests. White-box testing includes designing of test cases and an internal perspective of the software system.

Expert programming skills are needed to design test cases and internal structure of the program i.e., in short to perform white box testing. The tester or the person who is performing white box tests inputs some certain specified data to the code and checks for the output whether it is as expected or not. There are certain levels only at which white box testing can be applied.

The levels have been given below in the list:
- Unit level
- Integration level and
- System level
- Acceptance level
- Regression level
- Beta level

Even though there’s no problem in applying white box testing at all the 6 levels, it is usually performed at the unit level which is the basic level of software testing.

White box testing is required to test paths through a source codes, between systems and sub systems and also between different units during the integration of the software application.

White box testing can effectively show up hidden errors and grave problems.But, it is incapable of detecting the missing requirements and unimplemented parts of the given specifications. White box testing includes basically four kinds of basic and important testings. These have been listed below:

- Data flow testing
- Control flow testing
- Path testing and
- Branch testing

In the field of penetration testing, white box testing can be defined as a methodology in which a hacker has the total knowledge of the hacked system. So we can say that the white box testing is based on the idea of “how the system works?” it analyzes flow of data, flow of information, flow of control, coding practices and handling of errors and exceptions in the software system.

White box testing is done to ensure that whether the system is working as intended or not and it also validates the implemented source code for its control flow and design, security functionalities and to check for the vulnerable parts of the program.

White box testing cannot be performed without accessing the source code of the software system. It is recommended that the white boxing is performed at the unit level testing phase.

White box testing requires the knowledge of insecurities and vulnerabilities and strengths of a program.

- The first step in white box testing includes analyzing and comprehensing the software documentation, software artifacts and the source code.
- The second step of white box testing requires the tester to think like an attacker i.e., in what ways he/ she can exploit and damage the software system.
He/ she needs to think of ways to exploit the system of the software.
- The third step of white boxing testing techniques are implemented.

These three steps need to be carried out in harmony with each other. Other wise, the white box testing would not be successful.

White box testing is used to verify the source code. For carrying out white box testing one requires full knowledge of the logic and structure of the code of the system software. Using white box testing one can develop test cases that implement logical decisions, paths through a unit, operate loops as specified and ensure validity of the internal structure of the software system.

Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional

Search-Based Testing: Automating White-Box Testing

Software Testing Interview Questions You'll Most Likely Be Asked

Step 1 and Step 2 To test API : Identify the initial condition and Input/Parameter Selection

STEP 1: Identify the initial condition
The testing of an application programming interface (API) would depend largely on the environment in which it is to be tested. Hence, initial condition plays a very vital role in understanding and verifying the behavior of the API under test. the initial conditions for testing APIs can be classified as:

- Mandatory Pre-setters
The execution of an API would require some minimal state, environment. These type of initial conditions are classified under the mandatory initialization for the API. For example, a non-static member function API requires an object to be created before it could be called. This is an essential activity required for invoking the API.

- Behavioral Pre-setters
To test the specific behavior of the API, some additional environmental state is required. These types of initial conditions are called the behavioral pre-setters category of initial condition. These are optional conditions required by the API and need to be set before invoking the API under test thus influencing its behavior. Since these influence the behavior of the API under test, they are considered as additional inputs other than the parameters.

Thus, to test any application programming interface, the environment required should also be clearly understood and set up. Without these criteria, API under test might not function as required and leave the tester's job undone.

STEP 2: Input/Parameter Selection
the list of valid input parameters need to be identified to verify that the interface actually performs the tasks that it was designed for. While there is no method that ensures this behavior will be tested completely, using inputs that return quantifiable and verifiable results is the next big thing. The techniques like boundary value analysis and equivalence partitioning need to be used while trying to consider the input parameter values. The boundary values or limits that would lead to errors or exceptions needs to be identified.

It would also be helpful if the data structures and other components that use these data structures apart from the API are analyzed. The data structure can be loaded by using the other components and the API can be tested while the other component is accessing these data structures.

The availability of the source code to the testers would help in analyzing the various input values that could be possible for testing the API. It would also help in understanding the various paths which could be tested. Therefore, not only are testers required to understand the calls, but also all the constants and data types used by the interface.

Understanding Application Programming Interfaces(APIs)

Application Programmable Interfaces (APIs) are collections of software functions or procedures that can be used by other applications to fulfill their functionality. APIs provide an interface to the software component.These form the critical elements for the developing the applications and are used in varied applications from graph drawing packages, to speech engines, to web-based airline reservations systems, to computer security components.

Each API is supposed to behave the way it is coded i.e. it is functionality specific. These APIs may offer different results for different type of the input provided. The errors or the exceptions returned may also vary. However, once integrated within a product, the common functionality testing/integration testing may cover only those paths. By considering each API as a black box, a generalized approach of testing can be applied. But, there may be some paths which are not tested and lead to bugs in the application. Applications can be viewed and treated as APIs from a testing perspective.

The distinctive attributes that make testing of APIs slightly different from testing other common software interfaces like GUI testing.
- Testing APIs requires a thorough knowledge of its inner workings: Some APIs may interact with the operating system kernel, other APIs, with other software to offer their functionality. Thus, an understanding of the inner workings of the interface would help in analyzing the call sequences and detecting the failures caused.
- Adequate programming skills: API tests are in form of sequences of calls, namely, programs.Each tester must possess expertise in the programming language that are targeted by the API.
- Lack of domain knowledge: Involve the testers from the initial stage of development. This would help the testers to have some understanding on the interface and avoid exploring while testing.
- No documentation: Without the documentation, it is difficult for the test designer to understand the purpose of calls, the parameter types and possible valid/invalid values, their return values, the calls it makes to other functions and usage scenarios. Hence, proper documentation would help test designer design the tests faster.
- Access to source code: The availability of the source code would help tester to understand and analyze the implementation mechanism used; and can identify the loops or vulnerabilities that may cause errors.
- Time constraints: Thorough testing of APIs is time consuming, requires a learning overhead and resources to develop tools and design tests.