Agile Testing

  

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