When do you use Break Points? What is Toggle Break Points? How it differ from Break points?

What you got to do when you are in need of pausing a test run in between its execution? 

- Break points are used to mark such points in the test script where you want the test to be paused. 

- Break points have proved to be a very useful tool in the discovery of the flaws that might be present in a test script. 

- A break point marker marks the break point present in the test script. 

- This break point marker resides in the left margin of the test scripts.

- The test run is paused by the winrunner whenever it encounters a break point. 

- On a particular break point following tasks can be carried out:

1. The effects of the test run can be examined.
2. The current value of the variables can be viewed.
3. Any necessary changes can be made.
4. Test can be continued to further execution.

How to use Break Points?

- To continue the execution of the test after completing the task to be carried out on the break point the “run from arrow” command can be given and the test will restart from the break point. 

- Once, it gets in to the execution process again it will continue to execute until and unless it encounters another break point or till the test is complete. 

- One thing that should always be taken care of is to make sure that the winrunner is out of batch mode otherwise it won’t pause. 

- For winrunner to pause on break points, it is mandatory that it comes out of the batch mode. 

- If it is not, it is sure to ignore the break points. 

- There are 3 main uses of the break points:

1. They are used to suspend the test run at a particular point so that the state of your software system or application can be inspected.
2. They are used for monitoring the entries that are there in the watch list.
3. They are used to mark certain points throughout the test script for the stepping purpose by using the step commands.

Types of Break Points

We have two types of break points as mentioned below:

1. Break at location point: This break point makes the test to stop at some line number specified by the user in a test script and
2. Break in function point: This break point makes the test to stop whenever a functioned specified by the user is called in a loaded compiled module.

The break points that you define in a session remain active for that particular winrunner session only. Once you terminate that particular winrunner then you must redefine the break points to continue the debugging of the test script in the successive session.

Toggle Break Point and how they differ from normal break point

- Toggle break point command is used whenever you have to set a break at the location break point. 

- For doing this, you just need to move the point of insertion to that line of the test script where according to your desire the test must stop executing. 

- Now go to the debug menu and click on the option “toggle break point” or you can simply go for the button entitled toggle break point. 

- Once you have clicked on this you can observe a symbol of break point towards the left margin of the current window of the winrunner. 

- This break like other break points is also listed in the break points list.

- There is just one simple difference which is that the toggle break points automatically make use of the pass count of 0 and if some other pass count is required these break points can be easily modified. 

How to define effective metrics? What is the use of quality metrics?

The goal of software engineering is to develop a product that is of high quality. Metrics that are derived from these measures indicates the effectiveness of individual. Metric is a standard for measurement. A metric is a measure that captures performance and allows comparisons and supports business strategy.

The use of quality metrics is to spot the performance trends, comparing alternatives and predicting the performance. However, the costs and benefits of a particular quality metric should be considered as collecting data will not necessarily result in higher performance levels.

Effective metrics should define performance in quantifiable entity and a capable system exists to measure the entity. Effective metrics allow for actionable responses if the performance is unacceptable.

Identifying effective metrics is a bit difficult. Ranges can be identified for an acceptable performance of a metric. It can be referred as breakpoints in case metrics are defined for services and targets, tolerances, or specifications for manufacturing.

Breakpoints are levels where there is a chance that the improved performance will change the behavior of the customer. A target is a desired value of a characteristic. A tolerance is an allowable deviation from target value.

What are some of the formal approaches used for exploratory testing? Continued...

Some of the formal approaches used for exploratory testing are:

- Identify the break points
Break points are the situations where the system starts behaving abnormally. It does not give the output it is supposed to give. So, by identifying such situations also, testing can be done. Use boundary values or invariance for finding the break points of the application. In most of the cases, it is observed that system would work for normal inputs and outputs. Try to give input that might be the ideal situation or the worse situation. By trying to identify the extreme conditions or the breakpoints would help the tester to uncover the hidden bugs. Such cases might not be covered in the normal scripted testing. hence, this helps in finding the bugs which might not be covered in normal testing.

- Check the UI against Windows Interface etc standards
The exploratory testing can be performed by identifying the user interface standards. There are set standards laid down for the user interfaces that need to be developed. These user standards are nothing but the look and feel aspects of the interfaces, the user interacts with. The user should be comfortable with any of the screens that he or she is working on. These aspects help the end user to accept the system faster. By identifying the user standards, define an approach to test because the application developed should be user friendly for the user's usage.

- Identify expected results
The tester should know what he is testing for and expected output for the given input. Until and unless, the aim of the testing is not known, there is no use of the testing that is done because the tester may not succeed in distinguishing the real error and normal work-flow. The tester needs to analyze what is the expected output for the scenario he is testing.

- Identify the interfaces with other interfaces/external applications
In the age of component development and maximum re-usability, developers try to pick up the already developed components and integrate them. In some cases, it would help the tester explore the areas where the components are coupled. The output of one component should be correctly sent to other component. Hence, such scenarios or work-flows need to be identified and explored more. There may be external interfaces, like the application is integrated with another application for the data. In such cases, focus should be more on the interface between the two applications.