Agile Test Strategy
Big picture (ten words or less to speak to what this is that we are testing)
Drive behavior and set testing boundaries
Outline automation approach (typically executed after end-to-end testing)
Test data management (need to have clean data or will any data do?)
Test data should be re-usable and accessible in non-production environments
Collaborate with your data Team and Engineering Team
Defect management
UAT bug definition as agreed on by Product
QA bug
Create a ‘Bug’ and link to the story that the bug has been found in
Communicate to the Product owner for priority and assignment
When a bug is blocking a ticket, send an email to all stake holder stating so
Bugs ought to be resolved in the same sprint or carried over into the next sprint with the relative ticket
If the bug is NOT resolved and the ticket needs to move to Production then we will put it in the backlog and label with #techdebt
Large risks to our product quality
Our mindset is one of the end-users aka anyone using our tools and products.
Value of the test plan
An agile test plan will harden what the customer and the Team agree on
Identify gaps
Set expectations
Details of acceptance criteria
Notes: Continue collaboration via reviews, syncs, standups and maybe even a demo. Expect code, configuration and product to be changing every sprint.
Quality can drive velocity in agile
Velocity is measured by our Developers
Quality is reflected by the QA Team
An increase in quality increases velocity
Bugs caught earlier saves time and money
releasing w/ no re-work due to bugs saves time and money
list more bullets' or do folks get it?
Who is responsible for quality ? EVERYONE. Our work is to reflect the quality that has been designed and engineered into the products that we support.
Who is responsible, accountable, consulted and informed from the quality perspective
<insert link to QA RACI blog post here>
First QA iteration - Test Design
Ask questions of the ENTIRE TEAM; product, app dev, data and/or vendors/third parties. The requested change is signed off on and prior to development or design work, QA will participate in Product meetings to understand the following, prior to coding or changes made;
what should I be testing? What are we automating?
With what tools will be needed? Postman, iPhone, automation, data sets, environments, …
What will be manually tested due to complexity?
Where do you expect to find issues?
What should we explore and for how long? (main user path and edge cases, integrations, …)
Test Requirements and testing design
What is to be tested? and how…
Who is doing the testing? (Unit, functional, integration, acceptance, …)
defer to QA RACI link above
Regression testing based on;
Complexity, Overlapping functionality (APIs), Value, Stability and integrated, Dependencies for automation, …
Out of scope
Second iteration - Story / Feature Verification
Start your testing on the defined scenarios and readiness of code
Refer back to your plan
Team will be creating testing
Testing will be done as development completes and data is available
Identify test cases for automation
Update test data for QA and UA testing
Conduct manual validation
Create any stubs
Ensure the feature or changes are working as expected
Validate component interaction / integration testing
Write bugs and re-test for fixes
Third iteration - System
Complete end-to-end testing of features and functionality
Run regression to validate prior feature are NOT broken
Ensure regression test are updated
Remove any stubbing if possible
Continue a correct a fix defect (critical)
Update the plan with any other change and communicate to the Team.
Dependencies & assumptions
Assumptions;
Systems are working as expected prior to change
Skills and time to complete the testing need
Which Teams are developing what
Dev, Vendor, Data, Product, …
Test data: what specific types of data will we need
Mock data, Stubbed data
Production ‘like’ data (NPPI removed)
DO NOT USE REAL USER information.
Customers private data will NOT be used for testing as it s private.
Tech debt - what’s that? Credit debt analogy
Test acceptance Criteria
Do we have what QA needs for us to start?
Product/Dev/EDE review and sign off on the testing plan
