Document toolboxDocument toolbox

Header

(8.4.X) Qualitia Debugger

Qualitia provides an easy to use interface for you to develop test cases. Qualitia Debugger allows you to understand the course of test case execution and change it if required without re-executing entire test case every time you made any changes to it.

When developing test cases in Qualitia, users can verify whether it works as expected without running it end to end. A test case execution once initiated can be paused in between, or can it be modified mid-way during execution. So if you come across any fatal error that is failing your test case due to certain step or data at a given TC/Task iteration, you can modify the test case during test case execution.

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:

  1. Debug and execute test case step by step.
  2. Pause execution at the failure point. You can also pause the test case execution at any step using break-point facility. These facilities could be utilized for reaching and analyzing the point of failure without having to execute the test case entirely or single stepping entire test case.
  3. Modify test step, its parameters, and its object details while debugging test cases.
  4. Comprehensive and user-intuitive interface for you to see various TC and Task iterations and their details.
  5. Highlight any step in the test case using its line number.

(info) 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 ().

You can perform the following operations while debugging a test case:

  1. 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.
  2. Clear All Breakpoints by right-clicking the appropriate step with a single click.
  3. 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.
  4. View the detailed debugging logs of the last test cases by clicking the Debug Log button () .
  5. 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.

5. Status Flags

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.

No.

ControlsIconDescription
1Break on Failure

Select this checkbox if you want to auto break/pause the debugger on a failed step during the test case execution.
2

Qualitia Configuration properties

(Keyboard shortcut key F1)

Displays the Qualitia configuration settings set when execution of the test case.
3

Go To 

(Keyboard shortcut key Ctrl + G)

Pops-up the following dialog to accept the line number, highlights and brings specified step into view.
4

Play

(Keyboard shortcut key F5)

Initiate the debugging of a test case execution, execute the test case without interruption until it hits a Break-point or Break on Failure.
5

Stop

(Keyboard shortcut key Ctrl + F4)

End the test case execution anytime during the debugging.
This button is activated only after the test case execution is initiated and debugging is paused or during step by step execution.
6

Next

(Keyboard shortcut key F6)

Initiate the debugging session of a test case execution and single step the test steps.
7Current Line number 

shows the current line number under execution. For every step that gets executed the current line number gets updated to that step’s line number. You can click on the line number to go to the respective line number in the debugger view.

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.

Double-click the step under execution to launch the Modify Step dialog. This loads the selected step information in the dialog box.

Only a step which is currently under execution can be modified.

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.

(warning) 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 status of the test case iteration execution is updated along with the test case iteration number. Only a step that is under execution is allowed to be edited during debugging, no other steps can be modified. The debugger view allows you navigating through all executed and unexecuted TC and Task iterations before the debugging starts, while the test case is either waiting on a break-point, being debugged step by step, has finished execution. 

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. 

The test case execution continues till execution reaches a break-point or it has completed. The Detail view and Change log view of the debugger are only accessible when either the execution is waiting at a break-point or is being debugged step by step or has ended.

The detail view is a consolidated view of the test case execution. All the steps which were modified and executed during debugging; their details are shown in the detail view. The change log view gets updated whenever the step is modified.

There is no status associated with all the test steps which are skipped due to OnError conditions.

Please note that the facility of navigating a step to its execution detail in the detail view or its change details in the change log view is being considered for future releases and is not part of present release.

Once completed the execution, Qualitia report is displayed. It is not generated in certain cases. For more information on this, please refer to the (8.4.X) 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.

To use this feature:

  • 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 ConditionsExpected 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:

  1. The path of driver is not set correctly
  2. Unsupported combination of Selenium jar version and browser version





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.

Footer