System-Test: User story Acceptance Test Strategy
Dear Testing Community,
This is the next blog in our practical “Guideline for the Standard Test Levels” used in agile SW-Projects from Sogeti Testlab Hub Stuttgart. In this blog, we want to talk about the user story acceptance test strategy.
Let’s begin with a short introduction to the agile concept and going on with a deep dive look at the user story acceptance testing.
Short Introduction to Agile Test Strategies
Short time-to-market cycles is one of the strategic targets of agile software development. To achieve this we need to start talking with the client sooner and have to maintain time boxed Design-, Build-, and Deployment-Processes. This includes an integrated seamless test process and the application of a Test-Left Principle as soon as possible in the development and sprint cycle.
In this sprints we combine two test levels, first the unit-test including the internal flow, we have talked about it in the latest blog, and second the user story acceptance test.
Diagram 1: Testing Phases of a sprint cycle
How is the user story embedded in the agile sprint cycle?
User story acceptance tests are included in the time-boxed sprint cycle and run basically on new features after Implementation. user story acceptance tests are part of the DoD criteria catalog. Beside this they are fulfilling the three basic test purposes:
- The features meet the acceptance criteria and show the Conformance with the user’s requirements.
- Possible defects will be found.
- The user gets the first feeling for the SW and gains initial confidence in it.
If you are not used to the agile wording here a short explanation of the terms:
- Acceptance Criteria: Criteria, which are defined by the whole team and the client to ensure that the user story fulfills its purpose for the business. It is as well our primary guideline for the test case creation for the user story Acceptance Test.
- Definition of Ready (DoR): DoR is the template that defines what a user story has to fulfill to be accepted as a user story by the team and to be ready for implementation.
- Definition of Done (DoD): DoD is a list of conditions in the form of a template that a user story has to fulfill. If the client agrees that the implementation reaches the DoD a user story can be closed.
Diagram 2: JIRA Workflow with US-Test as DoR- and DoD-Criteria
How to create test cases for the user story acceptance test?
The user story acceptance test cases can be executed manually or automatically and test the feature (user story) from the user’s perspective. This means we need a user interface with a Point of Control (PoiC) and a Point of Observation (PoiO) to inject our test data into the system and to control the expected result.
Besides the acceptance criteria we need perhaps further requirements as a test base in order to answer the following 9 questions:
Diagram 3: Use test key-items as testability checker for the user story
There is an eternal conflict between speed and clearness in agile. Do we need further documented requirements or can we create test cases using our corporate knowledge in the cross-functional teams? I would say it is finally a question of the criticality of the user story and as a consequence the need to be tested exhaustively.
Here is an example of how an agile test case can be constituted:
Diagram 4: Use cases are very suitable candidates for test bases
In the agile community, a suitable test tool also for story acceptance testing is i.e. Xray plugin of Jira) from ATLASSIAN.
The test cases can be created out of the user story within JIRA and will be stocked and executed within x-ray. So the test process will be linked to the user story and the back-traceability is maintained and a defect cycle and the reporting can be a controlled and integrated process.
Diagram 5: the manual test cases will be edited in the step template of the test issue. The x-ray test type has to be “Manual”.
Some Tips for Automation
In order to keep the pace with the agile sprint flow, it is expedient to automatize at least the test cases used for regression tests overall test levels at will.
So we need an automation tool and a test automation solution (TAS), in order to execute user story acceptance tests.
Here we present a list of selected UI-test tools which are also suitable to automatize test cases for the user story acceptance tests.
Diagram 6: Test tools for user story acceptance tests and other functional test levels.
A detailed introduction to test automation and how to use them will be given in one of the next blogs.
This Blog was a collaboration of Sabine Reißenweber (technical test expert) and Stephan Schramm (Q&T-Manager at Sogeti).
Sabine Reißenweber appears courtesy from Sogeti-Stuttgart.
Stephan Schramm is a member of the Sogeti Lab Stuttgart.
References 1. Leffingwell, D.: Agile SW-Requirement; Addison-Wesley, 2011 [ISBN 978-0321635846] 2. Cockburn, A.: Writing effective Use Cases, Addison-Wesley, 2000[ISBN 978-0201702255]
About Stephan Schramm
Stephan Schramm is currently working for Robert Bosch projects at Stuttgart in the field of BI/Big Data/Data Lake/SAP environment and Intralogistics/DevOps/Deployment pipelines/in a µ-Service/Jenkins/Docker Architecture-environment. His main topics are currently the modelization of a Quality based Test fixture all along the Production Development process and Deployment pipeline applying a DevOps approach.
More on Stephan Schramm.