The Squash toolkit comprises a range of different modules for structuring and industrialising functional tests for software programmes or computer applications. Let’s take a look at this tool together!
Squash TM (Test Management) is a free and 100% web asset management tool (mainly functional). It is compatible with Firefox, Chrome, Internet Explorer and Safari.
However, unlike its competitors it can be used to work on multi- and inter-projects
Squash TM has three spaces: Requirements, Test Cases and Campaigns, which are linked as follows:
- a requirement can be linked to one or several test cases,
- a test case can respond to one or several requirements,
- a test case can be linked to one or several test campaigns,
- a test campaign can contain one or several test cases.
The following order is recommended by AUSY to define the spaces i.e. requirements, test cases and campaigns.
1. The requirements space
This is where you define the expression of a need i.e. the description of what the product must be able to do. In other words, it corresponds to the business rules to be applied.
A title and description are given to each created requirement, as well as a level of criticality (minor, major or critical) and a category (functional, ergonomic, technical, etc.) in order to optimise monitoring reports.
The requirements are placed in an open tree structure created by the user. AUSY implements and recommends the following good practice: use the features of the application to be tested to segment the tree structure.
Fig 1 - Example of the Requirements space and its tree structure
2. Test case space
This is where we list all the tests to be conducted by the project. Each test is then associated with several requirements.
The tests can be placed in a tree structure identical to the one created for the requirements.
Fig 2 - Example of the tree structure of a Test Case and a test step
A test is defined by adding one or more test steps i.e. stages of a test with the expected result for each one in the software to be tested.
Fig 3 - Example of defining the test steps
Each test step can contain variables in order to share the test case in question with several elements to be tested.
For example, if you want to test access to the login page of an application, you can define the login and password as a variable when defining the test steps:
Then add the data sets you want to test in the Settings section.
During execution, you can repeat this test case as many times as there are defined data sets.
3. Campaign space
This is where you execute the test cases. There is also the concept of a tree structure in this space too as we created it previously in a folder (by version) in which we will add a test campaign. You can add test cases to it, each associated with iterations.
Tests are run manually in Squash TM, taking place at the same time as actions carried out on the software to be tested. Test steps are developed one by one and their status is indicated (success, fail, blocked and non-testable). A temporary schedule is filled in, the actual schedule is created during execution.
Fig 5 – Example of running a test case
If an anomaly is observed when executing a test step, Squash TM will enter this anomaly directly from the test step in question in several bugtrackers. Obviously, the customer has to be familiar with and use this type of tool.
Fig6 - Executing test steps Fig7 - Anomaly report to JIRA for example
Once the anomaly has been created by Squash TM, it can then be consulted directly in the bugtracker. The description of the anomaly contains the test steps which were executed and that showed an error plus a written explanation from the tester. Documents can also be uploaded. The anomaly’s life cycle is then managed in the bugtracker.
In addition to the three previously described modules, Squash TM also has a dashboard. It can be used to extract (in a table) and summarise the progress of tests by project, campaign or requirement coverage.
These tables are quick to produce, easy to analyse and a good means of communication in terms of sharing the test teams’ progress. The extraction can take several forms (XLS, PDF, HTML) and be shared with other teams or the wider organisation.
Agility and Squash: example of the JIRA bugtracker
AUSY tester teams work on application ecosystems with an increasing degree of agility. The Squash tool is compatible with agile principles. To meet these types of needs, we use the XSquash configurable plug-in as this allows Squash TM to be integrated into the JIRA Workflow.
This plug-in makes it possible to synchronise the information in JIRA and Squash TM, share the test information and then create a link with the User Stories created by the Product Owner in JIRA. It is possible to centralise information by making it available and reliable, as well as preventing double entries thus speeding up decision-making.
It can also be adapted to the organisation level. You can create a Squash folder via a sprint defined in JIRA. It is possible to manage synchronised requirements in Squash TM after creating the User Stories in JIRA. At this stage, you can create test cases directly in Squash TM. And when it comes to steering, you can track progress i.e. the design and execution of all test cases is carried out in JIRA. It is possible to present (by ticket) the associated test case(s), the data sets used and the writing rate.
However, it should be noted and taken into account that JIRA controls the requirements while Squash TM controls the anomalies.
Squash TM is an innovative tool that is easy to access and whose features can be quickly understood. It is 100% web, which facilitates its use. It is also a great tool for sharing information, managing data sets and disseminating steering reports. Squash TM is robust and extremely ergonomic. Moreover, it is constantly being developed to take into account areas for improvement based on user feedback.
For all these reasons, AUSY uses Squash TM to manage the tests of several of its customers.