(DV-2002) Test Management

In this chapter we are going to discuss basic functionalities and step guides of different parts of Test management. Test management part enables you to define the Test Cases, add these cases to Test Plans, assign to testers and monitor the status of Test Plans.

You can start the Test Management via the Dashboard or by calling the transaction /DVD/KATE_TM.

Validate Dashboard

Test Management is divided into two tabs:

  1. Test Cases
  2. Test Plans

Test Management, Test Cases tab

It is important to understand the difference between Test cases and Test plans. Test plan is basic organizational entity. Test plan allows you to combine different types and any number of Test cases together. There are several specific actions that can be done on top of the Test Plan, mentioned in the text further. Definition of directories may seem similar to a Test plan definition but they have less/different options and are more folder like. Any Test Case cannot be executed without a Test Plan. Test plan serves as a frame for its Test cases. Test plan holds further definition of execution, settings, testers, statuses, documents and others. Test case carries basic information about the type (type of tested subject) and variants (particular details about tested objects).

Test Cases Tab

Here you can do the following:

  • New Test Case (Shift + F1)
  • Create new directory (Shift + F2)
  • Delete selected Test Case/Directory (Shift + F4)
  • Find (Shift + F7)
  • Find next (Shift + F8)
  • Go to Variant Editor (this option is only available if Backend Test Cases, like Query Test Case for example, is enabled in Validate Setup /DVD/VALIDATE_SETUP)

New Test Case

One of the first steps while using Validate benefits is a Test case creation. 

Test case is basic entity that allows you to perform different testing scenarios according to their type.

There are 3 ways to create a new Test case:

  • New Test case button,
  • Right-clicking at directory and selecting Add Test Case.
  • Hotkey Shift + F1


Creating new test case

The technical name for the Test case (e.g. TST_CASE) has a Description field and a Directory field that can be selected to be pre-populated with the current directory. If it's not selected you can manually add the directory. Note: this field is mandatory and you cannot create a Test case outside of the directory.

New Test Case window

The Fields marked with a checkbox are mandatory. 
The Test Case Type is a drop down menu, which contains the different types of Test Cases. Test Case Type 'Manual Test Case' is always pre-selected by default.

When the Manual Test Case option is chosen, you are presented with the possibility to add a Test Case Document.

Depending on your Validate setup, only certain Test Case Types may be visible. 
For example, if the Validate setup also contains BW Test Case Types, you will see an additional button at the bottom of the 'New Test Case window'. Here you can define additional information, based on these Test Case Types. 



Variants Management for Validate BW Test Cases

Create new directory

Directories serve the organizational purpose. You can create directories and subdirectories to sort out Test cases and Test plans for simple and effective access.

By pressing the Create new directory, (Shift + F2) a new directory is created and you can add subdirectories in the context menu of an existing directory and choosing Add Subdirectory


Creating new directory


A New Directory window looks like this:

New Directory window


Dir. Technical Name contains the technical name (e.g. FIELD_TST_DIR), whereas the Dir. Description is what is displayed in the navigation tree panel.
The Parent Directory field is pre-populated with the current directory. If this option is not selected the Parent directory needs to be filled manually.

Delete directory and Test Cases

If Test Cases and/or directories are no longer necessary these can be deleted.

  • In the context menu of an existing Test case/directory and choosing delete.
  • By Selecting Test Case/Directory and pressing the delete button, (Shift + F4)

Deleting items

Before performing any deletion the directory must be empty; otherwise it won't be deleted.

Transport Test Cases

Via the use of transports, Test Cases and their content can be transported from one system to another system. Therefore you can define Test Cases in one system and then reuse the same Test case in another system. If the same Test Cases or directories already exist, these will be overwritten when transported into the system.

Transport Test Cases for given directory

If you want to import Test Cases to the same system where they were created (e.g. after refresh of system), refer to the section Transport of Settings.

Find and Find next

If you have many Test cases and/or directories you can use the Find and Find next search features. To do so you can use the Find button or (Shift + F7).


Search window


In the tree structure you can search for elements individually or jointly by using the (star) asterisk for replacing a character or character sequences. If it's a broad search and has a high number of hits, you can search through these by using Find next (Shift + F8).

Where used for Test Cases

If you want to check all Test Plans where a particular Test Case is used, use the "Where Used" feature found in the context menu of a Test case. The Result table contains all Test Plan information where this variant is used.


Where-Used for given Test Case


Where-Used results list

Test Plans Tab

This part of the Test Management is dedicated to the test planning and test monitoring.

Test Plan as a basic organisational entity allows you to combine different types of Test cases and any number of them altogether. Test plan holds a definition of execution, settings, testers, statuses, documents and others.


Test Management, Test Plans tab


In the Test Plans tab you can find these buttons:

  • New Test Plan (Shift + F1) / Edit Test Plan (Double-click on existing plan)
  • Manage Test Plan Scope
  • Assign testers (Shift + F2)
  • Set Status (Shift + F4)
  • Worklist view (Shift + F5)
  • Filter (Shift + F6)
  • Refresh (F5)
  • Find (Shift + F7)
  • Find next (Shift + F8)
  • Go to Backend Variant Editor (F9)

New Test Plan / Edit Test Plan

Test Plan creation is another step to take when you want to order your Test cases and explore other possible operations with Test cases.

A new Test Plan is created by pressing the New Test Plan button (Shift + F1).

Creating Test Plan


New Test Plan window


Mandatory fields are marked with a checkbox. The Dialog box now contains new button Scope and allows you to edit the content of the Test Plan immediately. Test Cases can be also assigned/edited afterwards via the Edit command or in the context menu of the created plan and choosing Edit

The Technical Name contains a technical name (e.g. TST_PLAN), whereas the Description is visible in the description of the Test Plan in the tree navigation panel.

In the Edit Test Plan dialog box both Technical name and Description must be filled out.

Edit Test Plan window

 You cannot edit the Technical name of the Test Plan. If you want to change the Technical name of the Test Plan, a new one must be created.

Manage Test Plan Scope

From this dialog window you can edit existing Test Plans and create new Test Plans.


Manage Test Plan Scope window

This dialog window contains two main parts:

  • Left part contains the tree of Existing Test cases
  • Right part contains your currently selected Test Plan tree

You can add new items to the Test Plan either by drag and drop or double-clicking on desired item. 
Please be aware there are some actions, which are invalid:

  • Deleting Test Plan itself,
  • Dragging items from Test Plan tree to Test Cases tree,
  • Dragging parent onto its children,
  • Dragging item outside of the plan,
  • Dragging already incorporated Test case / directory again
  • Dragging or deleting variants of Test case.

Except above mentioned, the items are fully movable. You can add new items / directories, change their order or parent, delete undesired items / directories, or select variants that are to be used in the testing. However, you are unable to create a new folder in the Test plan or rename any of the items.

 It is possible to move only one directory / item at a time.

Assign testers

You can assign existing Test Plans to a specific person or to a list of people responsible for testing. By clicking on the Assign testers icon or in the context menu of the plan and choosing Assign testers (Shift + F2).


Assign testers window

The User Name is the SAP login for the tester and here you can use the SAP F4 help. You can assign one or more testers to a Test Plan, a Test Case directory and/or individual Test Cases.

Set Status

When setting the status of a Test Plan, it is necessary to have the status on Active so the testers can see this in their Worklist. 
Test Plans can have following statuses:

  • Active and Closed.

Test Cases can have following statuses:

  • UntestedIn processFailedSuccessful.

Set Status window


Test Cases and Test Plans can have a Status Document, here you can add more detailed description of testing results. To create a status document, click on the context menu of a Test Case/Test Plan and select „Create Status Document" option.

Status Document

Worklist view

In the worklist view, you can display all the Test Cases assigned to a given user and are visible in their worklist. You can navigate via worklist view button (Shift + F5).


Worklist window


Simply enter the user's SAP login and press confirm. If you wish to reset the view, leave the User name field blank and press confirm.

Filter

You can filter the Test Cases by pressing Filter icon (Shift + F6). Test Cases or Test Plans can both be filtered by their Technical name. Test Cases can be filtered according to their status. It is also possible to use an (star) asterisk to broaden the filter.


Filter window

Find and Find next

When you have many Test cases and/or directories, use the Find and Find next search by pressing the Find button (Shift + F7).


Find window

Test Plan Report

You can generate a documentation from the Test Plan in the form of MS Word document or HTML document. This report contains a list of all the Test Cases, including their statuses, Status Documents and additional information depending on the type of the Test Case.


Generating Test Plan Report


Before actual generation, you can select Test Cases to be part of a Test Plan Report, type of generated document for Test Plan Report and what kind of information needs to be generated.


Test Plan Report Options



MS DOC Test Plan Report


HTML document is more suitable for reports with large volumes of data, e.g. variant details. Default directory for HTML document is Desktop. You can select different directory by clicking on Browse button. HTML document does not contain Status Document.


HTML Test Plan Report

Test Plan Scheduling

You can schedule Test Plans to run on the regular basis and send notifications about the result.

Prerequisites

For scheduling to take place, you need to start Scheduling Checker in the Test Management Settings.



Test Management Settings icon


The Scheduling Checker is reoccurring background job that checks for all scheduled Test Plans every 15 minutes (i.e. if Scheduling Checker is executed on 17:40 it will check for Test Plans that are scheduled between 17:25 and 17:40).
You can set the Checking Period, which defines how often the Scheduling Checker checks for the scheduled Test Plans.
The actual precision of the scheduled time is dependent on this Checking Period – the smaller the number, better the precision. It is recommended to set a limit of up to 10 minutes. For a Checking Period of 10 minutes, the deviation is +10 minutes (so a Test Plan executed for 16:30 can be actually executed between 16:30 and 16:40).
You can also set the number of background jobs that are to be executed within a given Test Case.
Each run of the Scheduling Checker is logged and these logs are available from the Test Management Settings.



Test Management Settings


In order for the notification functionality to be working properly, the mail server has to be functioning on the system in which Validate is installed on. To test whether Validate can send emails correctly, go in to the Test Management Settings and in the 'Notification' section, type your email address. If a test email arrives, Validate can then send notification emails as expected.
Validate uses Business Communication Service (BCS) for sending emails.

Scheduling Overview

To see only the Test Plans that have been scheduled, you can change the view by customizing the filter.



Filter only scheduled Test Plans


Test Plans with this filter enabled have additional columns that are relevant to scheduling, such as logs, execution time, email address etc.



Overview of scheduled Test Plans (with filter enabled)

How to Schedule a Test Plan

To schedule a given Test Plan, go to context menu of the Test Plan and select 'Schedule Test Plan'.



Creating new Scheduling for the Test Plan


You can schedule a Test Plan to be run just once, daily or weekly. There is also the option to execute given Test Plan up to 3 times per day.



New Test Plan Scheduling window

For each Test Plan you can defined the scope - select which Test Cases have to be executed in scheduled Test Plan.

Selection of Test Cases

For each Test Case type, execution steps are available and therefore specific process of execution to each Test Case type can be defined.

Selection of Test Steps


Test Plans that are scheduled, have the icon of the calendar with a clock, near the Test Plan.



Scheduled Test Plans with the icon


Once the Test Plan has been scheduled and executed, you can check the logs in the context menu of the Test Plan.



Show Scheduling Logs


Scheduling Logs for given Test Plan


If the email address is available and has been set, a notification about the results will be sent. 

The email notification is dependent on the mail server of the system (see previous section 'Prerequisites' for more).


Notification mail sent after finished Test Plan

Scheduling Checker Algorithm

When Scheduling Test Plans, it is useful to know the algorithm for the Scheduling Checker to better understand its behavior.
Scheduling Checker is scheduled as a background job every X minutes (X is a Checking Period in Test Management settings). During the Scheduling Checker execution, two actions are being performed:

  1. Scheduling Checker will execute in the background all Test Plans that are scheduled within a given date range and within 15 minutes intervals (i.e. if Scheduling Checker is executing at 15:45, it will execute all Test Plans that are scheduled between 15:30 and 15:45).
  2. Scheduling Checker will send email notifications for finished Test Plans where an email address is set.

Test Plan Snapshot

You can create a historical snapshot of a Test Plan backend for Test Cases. This snapshot will save information about selected Test Plan and the actual execution status. To create the snapshot go in the context menu of desired Test Plan and select 'Variants Overview' -> 'Create New Snapshot' option from the context menu. You can then select which Test Cases should be included in the snapshot.



Creating New History Snapshot for Test Plan


It is possible to create snapshots automatically after each scheduled Test Plan execution by selecting 'Create Snapshot After Execution' option within scheduling options of a Test Plan. The Snapshot will be created only for Test Cases executed in scheduled execution.


Automatic Snapshot Creation for Scheduling


In current version of Validate snapshots are created only for backend Test Cases Types:

  • ListCube
  • Table
  • Query

To review historical snapshots that were created, go in the context menu of desired Test Plan and select 'Variants Overview'->'Show Variants Overview' option from the context menu. A New screen will be displayed with already created snapshots.


History Overview of Test Plan


At the top of the screen you can select a period for which you want to display created snapshots as you can display multiple Test plan history snapshots at once. By using F4 help you can change the date range and then by using of F8 refresh button, you will load the data of appropriate snapshots. The History overview screen contains 5 main tabs:

  1. Test Case Overview
  2. Variant Overview
  3. ListCube Variants Details [optional]
  4. Table Variants Details [optional]
  5. Query Variants Details [optional]

Test Case Overview Tab

In this tab you can see one record for each Snapshot/Test Case pair. It contains information about the total number of variants present in the Test Case when snapshot was created, overall status of a Test Case, untested/successful/failed variant counts, and rows information.



Test Case Overview Tab


In the 'User Comment' column you can provide any custom comment that will be saved there for later review.

Variant Overview Tab

Here you can see an overview of each Snapshot/Test Case/Variant combination. The information displayed includes the variant description, compare/reporting status, tested/error rows count and reporting status text if any.



Variant Overview Tab

ListCube Variants Details Tab

This tab is only displayed if any of the selected snapshots actually contain one or more ListCube Test Cases. For each Snapshot/Test Case/Variant combination you can see details of its variant settings and execution status of all steps.

Table Variants Details Tab

This tab is only displayed if any of the selected snapshots actually contain one or more Table Test Cases. For each Snapshot/Test Case/Variant combination you can see details of its variant settings and execution status of all steps.

Query Variants Details Tab

This tab is only displayed if any of the selected snapshots actually contain one or more Query Test Cases. For each Snapshot/Test Case/Variant combination you can see details of its variant settings and execution status of all steps.

Test Plan Replication to HP ALM

When the replication to HP ALM server is correctly setup in the Datavard Validate settings, you can replicate Datavard Validate Test Plans in the HP ALM server. To replicate a Test Plan, go in the context menu and select 'Others' -> 'Replicate to HP ALM'. To replicate multiple Test Plans, go in the context menu of a Test Plan Folder and select 'Replicate to HP ALM'.



Replicating Test Plans to HP ALM server

Choose template from the list box to fill a set of settings needed for the replication. For immediate customization of settings click on 'Edit' button. These changes will not affect any template. For the replication click on 'Continue' button. Last used template is saved for each replicated Test Plan and it will be pre-selected during next replication.

Selecting template before replication of Test Plans to HP ALM server


The following Validate objects are replicated:

  • Test Case
    • generates Test object in HP ALM Test plan area
  • Test Plan
    • generates Test Set object in HP ALM Test lab area
  • Test Case in scope of Test Plan
    • generates Test Instance under Test Set
  • Test Case status in Test Plan
    • generates HP ALM Run


Application log is generated during the replication process. It contains information about the replication status and possible errors that occurred during the replication.



Replication log


The replication works only from Validate to HP ALM. There is no transfer of data or synchronization from HP ALM back to Validate.

Worklist

This part of documentation explains basic navigation and functions of the Worklist section.



Worklist in Validate Dashboard

This area within Validate is focused on the testers, and those who see their Test Cases/Test Plans assigned to them.

Worklist


Test Plans with the status New are not displayed here, in order to make New Test plans visible, their status needs to be changed to Active. You can do this through the Test Management -> Test Plans tab. Users will only see their assigned Test Cases. Also directories are not displayed here.
To indicate which phase of testing the Test Cases are in, you can change their status. To change the status, click on the Set Status icon (Shift + F4), or go in the context menu of the Test case. In the following window you can add a description for the Test Cases and set the status to UntestedIn processFailed or Successful.

Set Status window

Test Case Mass Execution

In Test Plans tab, there is an option to execute all Test Cases in given Test Plan. For each Test Case Type, execution options are given and user can select which parts to execute and which not (i.e. execute only Before Image for all ListCube Test Cases). 



Mass Execution in Test Plans tab


For each Test Case type, execution options are available and therefore specific execution to each Test Case type can be defined.



Mass Execution – Main Screen

After clicking on "Change Selection" button, the scope of Mass Execution can be defined. Functionality is supported for all Test Cases that can be selected (i.e. Manual Test Case type cannot be selected, because it does not support the Mass Execution option).


Mass Execution – Selection of Test Cases 

Backend Test Cases Mass Execution

When backend Test Cases are selected for mass execution, you can define which test steps should be executed from each Test case type. List of test steps depends on chosen backend scenarios. Please refer to chapter 8 for more details about test steps for each type. Setting 'Number of jobs per Test Case' displayed on Figure 119 defines how many background jobs for each chosen step are to be executed. 
Each backend Test case type contains the option 'Run Sequentially'. If this setting is set, all chosen test steps will be executed in the order in which they are defined within the list. Execution of a step will be started once the preceding step is finished. There is a maximum time setting that once it is reached, while waiting for the preceding step to finish, will end the execution of the Test case. Please refer to Settings chapter for more details. If 'Run Sequentially' option is not used, all selected test steps are executed in parallel each using the specified number of jobs. No wait is used for these cases. 

Executing of some steps in parallel can lead to execution errors. For example running before/after image creation and comparison at the same time will cause comparison jobs to be executed before there is the actually data to be compared. Therefore, in most cases it is recommended to use 'Run Sequentially' option. 



Mass Execution of backend test case