Squash offers an integrated solution to meet the needs of each feature team member involved in BDD testing.
Gherkin formalization assistance
Improve your productivity and make your BDD test scenarios formalization in Gherkin more reliable, thanks to a simple and intuitive interface, with autocompletion to avoid syntax errors.
Action library to facilitate automation
Design modular tests suitable for automation, using libraries of variabilized actions that can be reused in your different test scenarios.
Agnostic test design to implementation choices
Write scenarios compatible with several automation technologies:
from the scenarios, Squash automatically generates the script skeleton expected by the different automation frameworks (Cucumber or Robot Framework).
Industrialization of the execution and analysis of automated BDD tests
Plan the automated execution of your tests or trigger them via a CI/CD pipeline, then take advantage of an interface that facilitates the analysis of the results.
HOW IT WORKS
Click on the numbered boxes to go directly to the related details.
Analyze the US and identify the necessary BDD scenarios
Before the developments, the Product Owner, developers and testers meet to collaboratively analyze the user stories and identify the resulting BDD scenarios or acceptance criteria.
As a tester, create in Squash TM the scenarios identified during these workshops as BDD test cases, and complete their description with the test objectives.
Behavior Driven Development focuses on behavior and not on implementation details (GUI, navigation), infrastructure or user path descriptions.
BDD scenarios can be complemented with navigation and GUI tests as well as exploratory tests.
Formalize the BDD scenarios to cover the US in Squash TM
Following these workshops, formalize these scenarios in Squash by adopting a modular approach consisting in factoring the actions/steps that are found in several tests.
You can also variabilize your BDD test cases. Example: instead of having several actions "the machine is running", "the machine is stopped", prefer a single variabilized action "the machine is "state"".
These two approaches allow to:
ensure the consistency of test cases
facilitate asset maintenance by avoiding redundancies
accelerate future test automation
Manage your BDD action library
Thanks to the Action Library workspace, build a pool of actions (to be reused in your BDD tests) based on a common terminology, which will facilitate the understanding, writing, maintenance and automation of BDD test cases:
Create/delete actions (new actions entered when writing BDD test cases are directly added to the action library)
Manage variables associated with actions
View the list of tests using the action
Identify actions that have been automated
Share the tests to be automated with the automation engineer and follow the progress
As a functional tester, identify the tests to be automated and pass on the list to the automation engineer or developer as automation tasks.
Squash automatically generates an automation script skeleton in Cucumber or Robot Framework format from each BDD test case. Then, it automatically pushes it in the automation team's Git repository and links it to the BDD test case.
Then track the progress of each automation task to be notified when a test automation is completed.
GOOD TO KNOW
Implement automated scripts
As a test automation developer, take cognizance of automation tasks and manage their progress to give visibility to the tester.
Retrieve generated scripts from the Git repository and implement the actions they contain while reusing the implementation of already automated actions.
Once the implementation is complete, update the status of the automation task to signal the end of the automation.
Integrate automated test execution into the CI/CD pipeline.
As a functional tester, define which automated test plan(s) to run and when to run them. You can, for example, in addition to testing the UI level every night, test the web services on every pull request / merge request...
As an SRE engineer, integrate into the CI/CD pipeline:
the execution of the automated test plan (plan retrieval in Squash TM, execution, results feedback and reporting in Squash TM), and
optionally, a quality gate to define if the test results are acceptable or not to continue the execution of the downstream pipeline.
Once the configuration is done, the tests are automatically launched according to the defined strategy.
GOOD TO KNOW
Analyze the results of automated tests
As a tester, review every morning the results of automated tests that were run overnight and identify tests that need analysis.
Analyze these results using reports, screenshots, execution history and save time by identifying tests that fail for the same reason.
At the end of the analysis, indicate if the test is ok, unstable, obsolete and declare any issues related to the test.
To go further: using Jira + Squash
Synchronize Jira user stories in Squash and associate them with BDD test cases.
Share BDD test cases with developers in Jira (in a TDD approach).
Follow the progress of the execution (manual and automated) of the tests and the validation of the user stories in Jira.
Delegate the management of automation tasks to Jira in order to integrate them into sprints.