Xsquash Tutorial

This tutorial is made to allow you to learn about Xsquash and its new features.
You would be able to follow this demo step by step by using the "Xsquash - Bac à sable" project on our online demo (available here).
You also can watch our Xsquash demo video by clicking on this link

 

Context

The team working on agile projects is composed of different members as a product owner, a scrum master, programmers and testers.
The product owner role is to create User-story, which are equivalent to the feature description to develop. As long as a User-story is not processed, it will remain in the backlog.
The scrum master will then create sprint and transfer User-story from the backlog into a sprint. A sprint is a short period when Agile team will design, develop and test User-story with the aim to get a 'viable' product.
Thanks to Xsquash, all these steps now could be achieved in JIRA or Squash TM by different contributors.

 

Summary

STEP 1 – In JIRA: creation of user story, sub-task and sprint

STEP 2In Squash TM: management of a JIRA user-story synchronized requirement

STEP 3In Squash TM: creation and association of a test case with the synchronized issue

STEP 4In JIRA: monitoring of test conception progression

STEP 5In Squash TM: automatic creation of a test plan from a sprint created in JIRA

STEP 6In JIRA: monitoring of test execution progression

 

STEP 1In JIRA: creation of user-story, sub-task and sprint

Context: The product owner will create user-stories from JIRA that will go in the backlog. The product owner will then create a new sprint and transfer user-stories from the backlog into the new sprint.

1.1 Open JIRA : https://jira.squashtest.org
1.2 Login with these data: Login: Xsquash          Password: password
1.3 Access to the "Demo-Xsquash" project 
  • Top menu, click on [Projects]
  • Drop-down menu, click on [Demo-Xsquash]
1.4 Create an issue "Story" in this project
  • Top menu, cliqk on [Create]
  • Issue Type, maintain the selected choice "Story"
  • Specify at least the "Summary" field
  • Click on [Create]
1.5 Access to the created issue form and create a sub-task
  • Issue tabs menu, click on « More »
  • Drop-down menu, click on [Create a sub-task]
  • Specify at least the "Summary" field
  • Click on [Create]
1.6 Go back in the backlog
  • Navigation bar on the left-hand side, first tab called « Backlog »
1.7 Create a new sprint and drag-and-drop the "Story" issue in this sprint
  • Scroll down the page until you access to the backlog section
  • Click on the right-hand button [Create a sprint]
  • Transfer an issue from the backlog into your sprint sprint, thanks to a "drag-and-drop"

 

You must obtain the following result:

     (A) A sprint
     (B) A story issue type
     (C) One (or several) sub-task(s) linked to the issue

 

STEP 2In Squash TM: management of a JIRA user-story synchronized requirement

Context : In Squash TM, elements created by the product owner and the scrum master in JIRA will be displayed. A new folder is now placed in the workspace, each folder is directly linked to a sprint created by the scrum master. The user-stories created by the product owner are displayed as synchronized requirements. For the testing team, it will be like a baseline before to begin the test conception phase.

2.1 Open Squash TM https://demo.squashtest.org/squash 
2.2 Login with these data: Login: Xsquash          Password: password
2.3 Access to the Requirements workspace
2.4 Access to the "Demo-Xsquash (EN)" project
2.5 Access to the synchronized folder called "Demo-Xsquash (EN) - BOARD"

 In this synchronized folder, you can note that different elements created in JIRA have been synchronized in Squash:

     (A) Sprint: a new folder with the name of the sprint you have created during step 1
     (B) Issue "Story": in this folder, a synchronized requirement with the reference and name specified in JIRA, as well as the URL link to JIRA ticket and synchronization status
     (C) Issue sub-task : sub-tasks are directly translated into sub-requirements in Squash, each sub-requirement is named by the reference and name entered in JIRA

 

 
Synchronization folder: this folder is created after the first synchronization with the JIRA project, and will be updated automatically (synchronized on a regular basis).
Folder organisation: for each synchronization with the scrum board in JIRA, the folder will be organised as follows:
  • At the root of the folder: issues which are in the backlog.
  • Sub-folders: each sprint is linked to issues from each sprint.
For any other kind of synchronization (filter, JQL query): every elements are located in the root of the synchronization folder. 
Folder re-organisation: folders and requirements can be re-organised in the target directory. The only restriction is to prevent delete a sprint sub-folder, otherwise it will be re-created.
Synchronized requirements: synchronized user-stories are displayed in a different color (grey) to distinguish them from the native Squash requirements. It also displays two new information compared to a native requirement:
  • An URL link to the original JIRA ticket.
  • A synchronization status that allows to warn a user if the communication between SquashTM & JIRA is broken or if an error occured during the last synchronization.
Modification: a synchronized requirement can be modified from Squash TM. However, these modifications will be erased after the next synchronization with the JIRA information. In contrast, non-synchronized elements - depending on how you customize your synchronization - can be freely modified and will not be erased.
Deletion: a synchronized requirement can be delete from Squash TM. However, it will be re-created after the next synchronization. If the issue is deleted in JIRA or if the synchronization is deleted, synchronized requirement in Squash TM will not be deleted (non-deletion policy). 
Link user-story/requirement: the link between a user-story - or task - and sub-task in JIRA is translated into a link requirement/sub-requirement in Squash TM. It is also possible to add some native sub-requirements in a synchronized requirement.
Migration: the migration of a synchronized requirement out of the synchronization project converts this requirement into a native requirement. To copy-paste a synchronized requirement will also convert it into a native requirement.

 

STEP 3In Squash TM: creation and association of a test case with the synchronized issue

Context: The testing team will be able to keep working on the conception tasks by creating test cases and by linking these test cases to JIRA user-stories, in order to certify all requirements are covered.

3.1 Access to the test cases workspace
3.2 Create one ou several test cases
3.3 Link them to a synchronized requirement from the "Story" issue created during step 1
3.4 Change status for at least one test case into "Under review" or "Approved"

 


STEP 4
In JIRA: monitoring of test conception progression

Context: The product owner, the scrum master and programmers will be able to follow up the testing team conception progression for each JIRA issue, thanks to several indicators and a test cases board linked to the JIRA issue.

 

Access to the "Story" issue form created during step 1.

 Several data about the issue linked test cases are displayed:

     (A) A first overall indicator: go to More information to learn which are these indicators
     (B) A "redaction ratio" field
     (C) A "Squash TM Test Cases" tab listing all the issue related test cases and their details

 

 

STEP 5In Squash TM: automatic creation of a test plan from a sprint created in JIRA

Context: In Squash TM, the test plan conception will be easier and will allow the testing team to find out every test cases to be executed depending on their release(s), sprint(s) or JIRA JQL query.

5.1 Access to the campaign workspace
5.2 Click on the "Demo-Xsquash" campaign on the left-hand side part
5.3 Click on the star tab then click on "Jira Execution Plan Designer"
5.4 Follow the different steps detailed by this wizard:
5.5 Action: "Create a new iteration in the selected campaign"
5.6 JIRA tickets source: select "In Sprints"
5.7 Boards selection:
Boards: select "JIRA boards related to 'name of the JIRA project' "
Criteria on sprints: select "Name of the sprint contains" and specify the name of the sprint created during step 1
5.8 Sprints selection: let checked the found sprint
5.9 Tickets selection: let selected the found ticket(s)
5.10 Case test selection: let selected the found test case(s)
5.11 Create the iteration: specify at least the "Name" field
5.12 Your test plan has been automatically created thanks to the selected elements in the creation wizard
5.13 Execute at least one test case from the execution plan
 

 

STEP 6In JIRA: monitoring of test execution progression

Context: For each JIRA ticket, the product owner, the scrum master and programmers will be able to follow up the testing team execution progression thanks to indicators and a board of the JIRA issue related test cases.

Access to the "Story" issue form created during step 1.

 Different data about the issue related test cases are displayed:

     (A) A first overall indicator: go to More information to learn which are these indicators
     (B) A "Verification ratio" field
     (C) A "Validation ratio" field
     (D) A "Squash TM Executions" tab

 

Testing status:
It is a summarized field to present the different steps recap of a testing phase for any requirement.
"Not initialized": when the test cases conception has not started - and none of the test cases with a "Under review" or "Approved" status have been linked to this issue.
"Ongoing conception": when the test cases conception is not finished - and only some of issue linked test cases are with a "Under review" or "Approved" status.
"To be executed": when the test cases conception is finished but execution has not begun - and every issue linked test cases are with a "Under review" or "Approved" status, but none of them have been executed.
"Ongoing execution": when only some test cases have been executed.
"Non approved": when at least one test case is in failure.
"Approved": when every test cases have been executed at least once with a passed or settled status for each of them.  
 
Redaction Rate:
This rate allows to monitor the test cases redaction progression.
For each synchronized requirement, this rate is equal to:
Number of test cases which covered the requirement or one of its linked sub-requirements and which are with a "Under review" or "Approved" status
/ Number of test cases which covered the requirement or one of its linked sub-requirements, regardless of their status
If a requirement is not covered, the rate is 0.
Redaction Ratio:
This field is the redaction rate value followed by the number of test cases in question (X/Y test cases).
 
Verification Rate:
This rate allows to monitor the execution progression of the test cases linked to a requirement or to one of its sub-requirements.
For each synchronized requirement, this rate is equal to:
Number of ITPI linked to a test case which covered a synchronized requirement or one of its linked sub-requirement with a final execution status (Ready, Failure, Blocked, Passed, Settled), by taking into account only the last execution (or the last fast pass)
/ Number of ITPI linked to a test case which covered a synchronized requirement or one of its linked sub-requirement
An ITPI is an Iteration Test Plan Item. It is about elements included in the execution plans of iterations placed in the Campaign workspace of Squash TM. 
Verification Ratio:
This field is the verification rate value followed by the number of test cases in question (X/Y test cases).
 
Validation Rate:
This rate allows to monitor the validation of a requirement.
For each synchronized requirement, this rate is equal to:
Number of ITPI linked to a test case which covered a synchronized requirement or one of its linked sub-requirement with a "Passed" or "Settled" execution status, by taking into account only the last execution (or the last fast pass)
/Number of ITPI linked to a test case which covered a synchronized requirement or one of its linked sub-requirement with a final execution status, by taking into account only the last execution (or the last fast pass)
An ITPI is an Iteration Test Plan Item. It is about elements included in the execution plans of iterations placed in the Campaign workspace of Squash TM. 
Validation Ratio:
This field is the validation rate value followed by the number of test cases in question (X/Y test cases).