...
Additionally, it allows to understand the number of TC and task iterations applicable on a test case and visualize the data associated with different steps for different task and TC iterations.
Key Features of Qualitia Debugger
The Qualitia Debugger provides an in-depth test case debugging experience to the testers along with the following facilities:
...
Debugger facilitates the test case development process and cannot be treated as a replacement for the test case development process.
Launching the Debugger
To debug a test case, from the Test Case editor screen, click the Debugger button (
).
...
- Add or Remove the break-point at any step of test case by clicking the line numbers. You can add/remove the breakpoints on the Debugger windows as well.
- Clear All Breakpoints by right-clicking the appropriate step with a single click.
- Skip / Unskip the steps from executing / debugging by right-clicking at the appropriate step.
For more information about the Skip functionality, refer to the Skip feature documentation. - View the detailed debugging logs of the last test cases by clicking the Debug Log button (
) . - Shift the focus to any line number of the test case by clicking the Go To button.
Getting Familiar with Debugger Controls
...
1. Test Case Name
The Debugger Window title bar shows the test case name being debugged.
2. Test Case Iterations
A drop-down list containing the test case iteration numbers, its current execution status, and data set tag information. At all times the test case iteration status is updated as per its execution status.
For more information, please refer to the Status section below.
3. Execution, Detail and Change Log Views
Qualitia logs are divided into 3 different parts as follows;
- The Execution view displays the Debugger test case view which in-turn shows the tasks, task iterations, data and so on per test case iteration.
- Detail view displays the step execution details.
- Change log view displays the details of all the steps that have been modified during debugging.
4. Add / Remove Break-Points
You can add/remove break-points before or between executions (when debugger is paused). The break-points that are added from test case development view are maintained in the debugger view and vice versa. The break-points are saved locally on your system and are not shared across Qualitia users.
| Anchor | ||||
|---|---|---|---|---|
|
Qualitia uses following flags to indicate the status of the test step being executed. These statuses apply to all test steps except for an IF-ELSE condition, task name or all the steps that are skipped in execution due to OnError condition:
6. Step Under Execution
A test step which is next step to be executed and has the execution pointer highlighting it is the step under execution. Only after you press Next or Play buttons the step is executed.
7. Debugger on Top
Selecting this option keeps the debugger window on top of all the other applications. Deselect it to allow other windows overlapping the debugger view which can cause debugger window to be hidden behind other application windows.
8. Execution State
Depicts the current state of the test case execution which can be:
- Not Executed
- In-Progress
- Completed
9. Debugger Toolbar
The debugger toolbar allows you to control all your actions after the debugger is launched.
...
Modifying Steps
While debugging test cases, there can be instances where you may want to change the parameters or object details such as locator type/value and so on. The Modify step functionality provides facility to do so when debugging the test case. This feature is most useful when you want to check the impact of a certain parameters' data change or an object locator type/value change or a conditional expression change on the test case.
...
All the debugger operations are applicable to the tasks and test cases that are shared for Design Updates.
Points to Know
- In a step, you can modify the following:
- Replace or edit an object,
- Change static and variable parameters
- Edit the conditional steps
- However, these changes cannot be saved in the test case.
- When debugging a test suite of a desktop project, you cannot edit an OR object.
Modifying Parameters of Step
Modify operation on a step only allows modifying the parameters of that step (if any). The modified parameters can only have static/literal data. The modification of data is only applicable to that particular task iteration for a task step and only for that TC iteration for a TC level step. The change of parameter’s data does not get propagated to subsequent Task and TC iterations.
Modifying Objects of Step
Qualitia users can modify object's locator type and value of an existing step. The modified object will reflect in all the subsequent instances of the objects wherever it is used in the test case.
Modifying Conditional Structure
You can modify conditional structure using modify step functionality of debugger. This option is available on the context-menu (right-click) of the current execution pointer.
The test case execution during debugging will get terminated with appropriate notification for an invalid expression.
Adding Comments
Qualitia users can add comments as per the requirements when debugging test cases.
Once comments are added you can also edit and remove comments using the context-menu options. For more information on commenting the steps, please refer to the comment feature documentation.
Viewing Additional Information
View Test Case Information Per Test Case Iteration
The debugger view loads the test case information per test case iteration. The test case iteration number can be selected from the drop-down at the left-top corner of the debugger window.
...
The Details tab also displays the test case iteration number in addition to other detailed information of each step being executed during the test case.
View Task Step Details by Task Iteration
You can view the task level details of respective task iteration. This can be done before test case debugging starts, debugger is waiting at some break-point, when doing step by step debugging using Next (F6), or the test case execution is complete.
You can view the TC level details by changing the TC iterations from the Test case iteration list. You can also view the Task iterations details by selecting appropriate task iteration number from the task iteration list which is present along with the task header at the start of every task.
Executing Test cases with Debugger
Test Case Execution with Debugger
Once all the break-points are added, Qualitia users can initiate the test case execution pressing the Play button (keyboard shortcut F5) on the debugger view. Once clicked the Play button, Webdriver is launched and test case starts executing.
...
Once completed the execution, Qualitia report is displayed. It is not generated in certain cases. For more information on this, please refer to the Error Handling and Notifications section.
Debugging Step By Step
One of the key features of Qualitia Debugger is to be able to debug the test case execution step by step. This helps when you want to understand the flow of execution and if there is any specific step in the test case which could is causing the problem.
Qualitia users can start debugging test case step by step using the Next (F6) button from the Debugger window. Once the step is executed, the details of the step are displayed immediately after the execution is completed.
Debugging Test Execution with Break-Points
This feature allows you to put break-points when executing test cases. If you do not wish to debug the test case step by step you can put a break-point on any step and click the Play button, the test case execution will pause once it reaches to the break-point. This is especially helpful when you want to check the impact of a new step before a specific step or you want to modify a specific step.
- To pause test case execution on a step, you can add a break-point on any step from the Execution window in Qualitia Automation Studio.
- To add a break-point click the line number before the test case execution starts or whenever the execution is in pause state in the Qualitia Debugger window.
- You can add break-points to any step except for a Task Name or Conditional Structure (If, Else) step.
- During the course of test case execution debugger waits for user to press Next or Play button whenever it reaches to the break-point. Only after one clicks Play / Next the debugger will execute that step.
- Debugger allows removing break-points from debugger view. The breakpoints added from test case development view reflect in debugger view and vice versa.
Debugging Test Execution with Break-Points on Failure
This feature is very helpful in debugging test cases where it is not clear which step will fail during the execution and the reason for its failure. Qualitia users can use this option to enable the break on failure. Debugger will pause the test case execution as soon as it encounters a failed (or defect) step. You can evaluate the failed step and continue with the debugging.
...
- Select the Break on Failure checkbox on the Qualitia Debugger window.
Viewing Object, Action, and Parameter Details of Test Step
At any point before or after execution of a step, you can double-click the step and see its detailed information. At the start of the debugger / step by step debugging / post execution one can perform this operation.
Detail View
The Detail view provides the execution details of every step. The Object, Action, Parameters, and test step execution result is shown in the detail view.
Change Log
Information about any modified steps is logged in the Change Log section. The change log view shows all the changes that have been made to test steps. The change log for a debugged test case is maintained till any test case is debugged again. This can be accessed using the Log button on the Test cases screen in Qualitia Automation Studio.
You can copy a modified step by selecting the row and pressing Ctrl + C and paste it using Ctrl + V on the Test Cases screen in the Qualitia Automation Studio.
Error Handling and Notifications
| Possible Error Conditions | Expected behavior and Solution |
|---|---|
| Expected at the time of launching the debugger | |
| The config file path is invalid | In case of occurrence of any of these errors the debugger does not get launched. You can try and launch the debugger again after the error has been fixed. |
| Property file contains invalid properties | |
| Invalid logpath set in config path | |
| No test case iterations to execute. Need at least one iteration to execute test case. | |
| A generic exception has occurred in initializing the test execution engine | |
| No tests to execute | |
| Expected during test case execution | |
Unable to launch browser due to one of the following possible reasons:
| Expected during test case execution, the execution report will not be generated in case of any of these exceptions. |
| An error occurred in calculating roll up status | |
| Report file not found | |
| An error occurred in updating the summary report | |
| An error occurred in releasing the report | |
| Unable to write to the report file | |
| Expected during test case execution | |
| Invalid Expression Exception occurred | The test case execution report will be generated even if these exceptions occur. |
| Selenium clean up failed, error occurred in cleaning up the Selenium Webdriver. | |
| Expected at the time of launching the debugger or at the time of test execution. | |
| A generic exception has occurred along with the exact cause of the error | Debugger either does not get launched or stops the execution depending on the wherever the error occurs. Debugger also shows the Error message from the test execution engine in this case. |
...