TAST DokuWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Running ======


This option of the TAST tool allows the user ** to execute the Test Sets. **
Also, it allows ** to create new Test Sets to be executed. **

The RUNNING option has two tabs:\\  
  * Test Set Management 
  * Planning


===== Test Set Management =====

With this option the Test Sets corresponding to a specific diagram can be managed.
Here in Test Set Management are two different “tabs”:  
  * Test Sets.
  * Test Set.

==== Test Sets Window ====
{{:en:tsmanagement-testsets_eng.png?2600|}}\\ \\ 
It shows the list of Test Sets of a specific domain and project, with information about its status, as well as its Test Case Datasets.
In general, it can be filtered by:
  * Domain.
  * Project.
  * Test set.
  * User.

It will also allow creating, editing and deleting a folder.

In the main window of MANAGEMENT OF TEST SETS, the list of Test Case Sets for the filters used will be displayed, with the following information:\\ 
  * Name of the Test Set.
  * Date and time of creation.
  * Number of diagrams.
  * Number of data sets of test cases (TCD).
  * Status: The status shows the state of the Test Set execution, it also includes a global status, being aware of the individual status of every Test Case Data on the Test Set. That means we have different status:
    * Pending: Message **“not executed”** in a gray color. This status mean that never has existed an execution of that Test Set.
    * Executing: This status is not visible, it happens when the user executes the Test Set.
    * Partially Executed: The message in orange **“Partially Executed”** comes with a Test Set with various TCD when some of then were executed and the other ones don’t.
    * Completed: in this status we could get two messages:\\ - **Executed (in green):** This means that all the execution went right, and everything finished without problems.\\ - **Executed (in red):** This means that a problem has occurred in the Test Set or TCD.\\ \\ The only way to get the status Executed in green, is when all the TCD are in green too. If something failed, then it will be red.\\ \\  
  * Uploaded to ALM: YES or NO.
  * Action: with the following indicators:
    * Owner.
    * Delete Test Set.
    * Run Test Set.
     
==== Test Set Window ====
{{:en:tsmanagement-testset_eng.png?2600|}}\\ \\ 
It is accessed by clicking on any Test Set in the // Test Sets // window.
In this window you can perform actions on the Test Sets, as well as manage the Test Case Data associated with the Test Set:
  * At the Test Set level:
    * Create a Test Set.
    * Run a Test Set.
    * Upload the Test Set to ALM: all steps of the set of test cases will be added to the tool [[https://en.wikipedia.org/wiki/HP_Application_Lifecycle_Management|ALM (Application Lifecycle Management).]]
  * At the Test Case Data level:
    * Add a Test Case Data.
    * Delete a Test Case Data.
    * Select / unselect  the screenshots of the Test Case Data (of some Test Case Data or of all).

The list of all the Test Case Data corresponding to the Test Set on which it has been previously clicked will be displayed, with the following information:
  * Order.
  * Domain.
  * Project.
  * Folder.
  * Name of the diagram.
  * Type of Test Case Data (validation or value).
  * Result: Executed or Not executed.
  * Uploaded or not to ALM.
  * Action: with the following indicators:
     * Capture of the screenshots of the test case.
     * Scroll up or down the Test Case Data.
     * Delete Test Case Data.

{{:tsmanagement-addtcdata-eng.png?2600|}}\\ \\ 
To include Test Case Data in the Test Set, press button "+" at the right of the Test Set name. A new window will open and will allow to select the Diagram, so that all available and selectable Test Case Data will be shown in the left-hand list.
     * Clicking over eachTest Case Data or "Select all" button will move the Test Case Data to the right-hand list.
     * The Test Case Data on the right-hand listwill show a "check/minus" button to show if the capture of evidences is active for that Test Case Data. We can alter the status by clicking on that button. There is a general button on top of the list to alter the status of all the elements at once.
     * Clicking on any Test Case Data on the right we will move it to the left if it belongs to the selected diagram, or will dissapear if it doesn´t.
     * All Test Case Data on the right-hand list will be loaded to the Test Set once we click over the "Accept" button of the screen.\\ \\ 

==== Debug Mode Execution in client for TC_Validation ====

The objective is to provide Tast Client application with the ability to launch the execution of a Test Case Validation (TCV from now on) in debug mode. In this way, the user will be able to run a TCV step by step until the end, or to stop at the steps that are considered appropriate.\\ \\ On the other hand, the user will be able to stop the execution in debug mode of a TCV at any time and switch to normal execution.\\ \\  
At all times, the debug execution results will be available, showing the steps that have been executed in a log.
Also you can debug more than one test at a time.

===Use of the debug in TAST===

For this purpose, two new columns "Step" and "Debug" are enabled on the Tast Client, to control the debugging execution of the TCVs as shown at the image below.


{{:en:debuggs1.png?700|}}

From the Debug column, the user will be able to tart/continue, or stop the debug execution of a TCV.
The Step column will show the evolution of the TCV debug mode execution, and it also allows the user to enter, if desired, the step to which he wants to go forward.
Once the execution in debug mode has started, the Step field will always show the last step executed, as well as information related to it.\\ \\ 
We will see all of this below in more detail, where the operations will be explained.\\ 


1. **Starting a //TCV// execution in debug mode**

Before running a //TCV// in debug mode, we will see that the value of the **Step field** initially is  "_._". This will indicate that the execution in debug mode has not yet started.\\ \\ 
To start the debug execution of a //TCV//, we will have to press the button “**Run to next step**” below the **Debug** column.\\ \\ 
There will be 2 ways to start the debug execution:\\ 


   * From the initial Step field "_._" we will press the **Run to next step** button.\\ \\ {{ :en:debuggs2.png?600 |}}\\ \\ Then the application will start the debug execution, and it will execute only the first step of the diagram (or the first step that could be executed according to the logic of the diagram).\\ \\ Once executed, the **Step field** will show the first step executed, which will normally be the step 1.0\\ \\ {{ :en:debuggs3.png?600 |}}\\ 


  * From the initial Step field “_._” if the user would want to go forward to a certain step, he could enter the desired step in the **Step field** and then press the **Run to next step** button.\\ \\ {{ :en:debuggs4.png?600 |}}\\ \\ Then the application will start the debug execution and will successively execute all the steps from the beginning until the step typed by the user, stopping at the immediately previous step (or at the immediately previous one according to the logic of the diagram).\\ \\ {{ :en:debuggs5.png?600 |}}\\ 


2. **Continue the execution of a //TCV// in debug mode**

Once the debug execution of a //TCV// has started, there will be several ways to continue with it.\\  

   * **//Run to next step//**\\ \\  If you only want to execute one more step, simply press the **Run to next step** button again.\\ \\ {{ :en:debuggs6.png?600 |}} \\ \\ After this, the step executed will be reflected in the **step field**. From this point we can continue the execution in the desired way.

  * **//Run to a higher step//**\\ \\ Again, we can advance to a higher step by entering the desired step in the **Step field**, and then pressing the **Run to next step** button.\\ \\ {{ :en:debuggs7.png?600 |}} \\ \\ Thus, the application will execute all the steps from the current one to the one immediately prior to this. From here we can continue the execution in the desired way.

  * **//Run to the last step of the TCV//**\\ \\ From any step, we will be able to advance directly to the end of the diagram, and there will be two ways to do this:\\ \\ a. By entering the last step of the diagram and pressing **Run to next step**. Remember: the execution will continue until the step immediately preceding the last step.\\ or \\ b. By pressing the **Start** button in the **Action column**. Then the application will run from the current step to the end of the diagram.\\ \\ {{ :en:debuggs8.png?600 |}}\\ \\ 

3. **Stopping the debug execution of a //TCV//**

At any time the user will be able to stop the execution of a //TCV// in debug mode, by pressing the **Stop debugging** button in the **Debug** column.\\ \\ {{ :en:debuggs9.png?600 |}} \\ \\ Reasons why the user may want to stop the execution:\\ \\ 1. Either because you have already checked the parts of the diagram that you wanted to check, so you conclude the debug execution.\\ or \\ 2. When you need to make changes to the diagram, so you will need to stop the execution and restart it later in order than the application can update the //TCV//.\\ \\
 
4. **Step field notation**

In the **Step field** the user will be able to see the current step or enter the step number he wants to advance.\\  
The notation of the steps in this field is practically the same as the one we currently see in logs.\\ \\ 
**Step_= step_main.step_gate1.step_gate2 ....**\\ \\ 
Where each point means a gate deep.\\ \\ For example, if we wanted to advance to step 11 of the main diagram, we could type **11** or **11.0**, due to it would not be necessary to use the point at the first level (main diagram).\\ 
However, if we wanted to go to a certain step inside a gate, then we would need to use points.\\ \\ 
For example, if we see (or type) this in the **step field**:\\ \\ {{ :en:debuggs10.png?600 |}}\\ It would mean that current step is (or if the user has typed it, he wants to advance to):\\ 
Step 10 of the main diagram (in this example, step 10 would be a Gate, e.g. gate1),\\ 
and within gate1 to its step 5 (in this example step 5 of gate1 is another nested gate, e.g. gate2),\\  
and finally to the step 1 inside gate2.\\ \\ 


5. **Other considerations**

At any time during the execution, the user will be able to review the results through the **Log file**, where the steps that are being executed will be gradually reflected. As always, you can press the **Log** button in the **Logs column** to access to the log file of that //TCV//.\\ \\ 

{{ :en:debuggs11.png?600 |}}\\ 

The result of executing any step will be reflected in the **Status column** (with the usual //Executed// -green- or //Erroneous//-red- statuses).\\ \\ 
{{ :en:debuggs12.png?600 |}}\\ \\ 
Placing the mouse over the **Current Step** field, the application will show a tooltip with information about that step, such as the step number as it appears in the logs and the name of the executed function.\\ \\ 
{{ :en:debuggs13.png?600 |}}\\ \\ 
Once the debug execution of a //TCV// has started, the **Results uploading** will be automatically disabled for obvious reasons. The user can enable it again when the debug execution ends, or when he wants to run the normal execution mode.\\ \\  
{{ :en:debuggs14.png?600 |}}\\ \\ 



===== Planning =====

In TAST it is possible to schedule the Test Sets to be executed later.
These plannings can be periodic.

The PLANNING option has two tabs:

  * Calendar
  * Plan List

==== Calendar ====

In this Running option, you can see a calendar with the status of the existing plans for a Domain, Project, and, optionally, for a Specific Server:

{{:Calendar.png??nolink&9000}}

Below the meaning of the colored circles that appear in calendar days:

{{:Calendar_1.png??}}number of plannings requested. This is the initial status, when a planning is created \\
{{:Calendar_2.png?}} number of plannings confirmed. The planning is put //confirmed// when the user clicks the //Confirm// button that appears when editing the planned Test Set (tab [[en:running#plan_list|Plan List]])\\
{{:Calendar_3.png?}} number of plannings rejected. The user has the option to reject the planning for different reasons (clicking the //Reject// button that appears when editing the planned Test Set (tab [[en:running#plan_list|Plan List]])\\
{{:Calendar_4.png?}} number of plannings executed. This status appears once the planning has been executed.

==== Plan List ====

==== Flow in the Test Cases Planning ====

The steps to follow until the execution of the planned test cases are:

  - Include the diagram (s) in a Test Set: through the TAST option [[en:running#test_set_management|TS Management]]
  - Include the Test Set in a planning: through the New planification buttom of Planning  
  - Confirm the planning

Once the Test Set has been executed, the result of the execution will be shown in the table of [[en:results|Results]].

If the Test Set has not been executed, it will be canceled.

^ Situation	^ Probable causes^ Corrective actions^
|The planned Test Set has not been executed|The server was not available|- Check the server is in the list\\ - Check the PC client is active in the server\\ - Check the Test Set is programmed for that server|
TAST DokuWiki

User Tools

Site Tools

Page Tools
