Agile Test Strategy Example Template - DevQA - Io PDF
Agile Test Strategy Example Template - DevQA - Io PDF
The purpose of the agile test strategy document is to list best practices and some form of
structure that the teams can follow. Remember, agile does not mean unstructured.
Here, we take a look at a sample Agile Test Strategy and what to include in the document.
A test strategy usually has a mission statement which could be related to the wider business
goals and objectives.
To Constantly Deliver Working Software that Meets Customer’s Requirements _by means
of _Providing Fast Feedback _and _Defect Prevention, rather than Defect Detection.
Supported by:
No code may be written for a story until we first define its acceptance criteria/tests
A story may not be considered complete until all its acceptance tests pass
In the Agile Test Strategy document, I would also include a reminder to everyone about
Quality Assurance
In SCRUM (agile) QA is the responsibility of everyone, not only the testers. QA is all the
activities we do to ensure correct quality during the development of new products.
Test Levels
Unit Testing
WHY: To ensure code is developed correctly
WHAT: All new code + re-factoring of legacy code as well as Javascript unit Testing
Acceptance Testing
Testing in Agile
WHY: To ensure customer’s expectations are met
Agile Tester Traits
From Waterfall to Agile WHO: Developer / SDET / Manual QA
Agile Testing Mindset
WHAT: Verifying acceptance tests on the stories, verification of features
Agile Testing Challenges
Whole Team Approach WHEN: When the feature is ready and unit tested
Agile Exploratory Testing
WHERE: CI / Test Environment
Testing Without QA
WHAT: Scenario Testing, User flows and typical User Journeys, Performance and security
Further Reading
testing
All Agile Articles >>
WHEN: When Acceptance Testing is completed
Product Backlog
Most common cause of software development failure is due to unclear requirements and
different interpretation of requirements by different members of the team.
User stories should be simple, concise and unambiguous. As a good guideline, it is best to
follow the INVEST model for writing user stories.
As a [role]
I want [feature]
So that [benefit]
It is important not to forget the “Benefit” part, as everyone should be aware of what value
they are adding by developing the story.
Acceptance Criteria
Each of the User stories must contain acceptance criteria. This is possibly the most important
element which encourages communication with different members of the team.
Acceptance criteria should be written at the same time the user story is created and should
be embedded within the body of the story. All acceptance criteria should be testable.
Each Acceptance Criteria should have a number of Acceptance Tests presented as scenarios
written in Gherkin format, e.g.
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
Developers should have a good understanding of the technical details that are involved in
delivering the story, and QA should know how the story will be tested and if there are any
impediments to test the stories.
Preventing Defects
Scenarios (valid, invalid and edge cases) should be thought of (QA can add huge value here
by thinking abstractly about the story) and written down in feature files.
It is important to note that it is the scenarios (more than anything else) that will reveal
defects when testing the product, so the more effort and time spent on this activity, the best
results at the end.
Because the majority of defects are due to unclear and vague requirements, this activity will
also help prevent implementation of incorrect behavior as everyone should have the same
understanding of the story.
Likewise, in the sprint planning meetings, the estimates given for a story should include the
testing effort as well and not just coding effort. QA (manual and automation) must also
be present in the sprint planning meetings to provide an estimate for testing of the story.
Development
When development starts, new production code and/or modification to legacy code should be
backed by unit tests written by developers and peer-reviewed by another developer or a
skilled SDET.
Any commit to the code repository should trigger an execution of the unit tests from the CI
server. This provides a fast feedback mechanism to the development team.
Unit tests ensure that the system works at a technical level and that there are no errors in
the logic.
Developer Testing
As a developer, behave as if you don’t have any QA in the team or organization. It is true
that QAs have different mindset but you should test to the best of your ability.
You think you are saving time by quickly moving on to the next story, but in reality, when a
defect is found and reported, it takes longer to rectify the issue than spending few minutes
making sure the feature works well.
Any new code and/or refactoring of legacy code should have appropriate unit tests that will
be part of the unit regression test.
Automated acceptance tests are usually written in Gherkin language and executed using a
BDD tool such as cucumber.
Because these tests typically require communication over HTTP, they need to be executed on a
deployed application, rather than run as part of the build.
Non-functional tests such as Performance and Security tests are as equally important as
functional tests, therefore need to be executed on each deploy.
Security Tests should check for basic security vulnerabilities derived from OWASP
It is vital that this should be a completely automated process with very little maintenance to
get the most benefit out of automated deployments. This means there should be no
intermittent test failures, test script issues, and broken environment.
Failures should only be due to genuine code defects rather than script issues, therefore any
failing test which is not due to genuine failures should be fixed immediately or removed from
the automation pack, to be able to get consistent results.
Regression Testing
Not expecting to find many defects. Their purpose is only to provide feedback that we haven’t
broken major functionality. There should be a very little amount of manual regression testing.
Smoke pack – Should be no more than 15 mins
This pack contains only high-level functionality to make sure the application is stable enough
for further development or testing.
For example, for an eCommerce website, tests included in this pack could be:
Product Search,
Product Review
Purchase Item
Account Creation / Account Login
This pack contains the full regression suite of tests and contains everything else which is not
included in the smoke pack.
Here, the goal is to get a quick feedback with a larger set of tests. If the feedback takes
more than 1 hour, it is not quick. Either reduce the number of tests by using pairwise test
technique, create test packs based on risk or run the tests in parallel.
PO (Product Owner) should run User Acceptance Tests or Business Acceptance Tests to
confirm the built product is what was expected and that it meets user’s expectations.
Exploratory testing should focus on user scenarios and should find bugs that automation
misses. Exploratory testing should not find trivial bugs, rather it should find subtle issues.
Done Criteria
Once all the above activities are completed and no issues found, the story is Done!
The above are some guidelines on what can be included in an Agile Test Strategy Document.
Obviously this needs to be tailored to your organization’s needs, but hopefully, this template
would assist you in creating your own Agile Test Strategy document.
agile strategy
qa (23) agile (30) automation (20) strategy (5) featured (11) selenium (20) cucumber (1)
perf (15) jmeter (6) est-assured (1) java (22) testng (1) devops (3) tips (7) json (6)
Explore → javascript (2) tools (1) api-testing (9) rest-assured (3) karate (3) http (3) gatling (5)
quiz (3) cypress (1) git (2) ceh (12) security (8) linux (2) node js (1) networking (2)
bash (1) python (9) sql (1) brew (1) mac os (1) aws (1)
Copyright © 2020 DevQA Contact Privacy