What exactly is agile testing, and why would we need an agile process playbook for software testing? Let me explain in this post…
QA’s Place in the Agile Conversation (or Lack Thereof)
One frustration I have commonly observed with software development is that there are no clear-cut steps for when to include QA in the conversation. It's possible that this is only my experience with software development process and talking about testing.
Either way, if QA is not included in agile processes or planning, software quality will suffer. So will the overall organizational communication that is an important part of effective software delivery.
This is why it is so important to create an agile process playbook for software testing. Below, I explain the steps you should take in developing such a playbook.
The Players on the Agile Team
Every team is made up differently, of course, but in general, the following members belong on your software development team and should be part of the testing process:
Project Manager
Product Manager
Designer
Developer
Quality Assurance (QA)
Performance
Security
Site Reliability Engineer (SRE)
How We Test
My goal is to help others understand the cadence of how we test things, which enables clear guidelines and processes for testing in an agile environment. To reinforce the idea of agile testing, QA involvement belongs at the beginning of the discovery stage, and a shift in mindset and culture is a must.
Building quality software starts by improving speed, efficiency, ownership, and collaboration by communicating the QA agile process workflow stages to the entire team. To achieve this goal of better quality, let's take a closer look at the different stages—how we test things.
Discovery Stage
To simplify the onboarding of new projects for testing, the discovery stage allows the QA team to understand the requirements, research tooling, define a quality strategy, and set milestones.
Component | Description | Actions |
Research | Every project is different. During the discovery stage, will our existing test solution work, or do we need to allocate time researching a new test solution required for this specific project? | Technology Analysis and Targeted Audience |
Requirements | The product manager verbalizes the vision as to why the new product will exist and how it will work by reviewing the Business Requirement Document (BRD). | Review Business Requirement Document (BRD), Release Date, and |
Knowledge Transfer | ||
Quality Plan | By getting involved at the beginning, we have a clear understanding of the requirements that allow us to explain what quality approach will be required to build, test, and deploy the product. | QA Drives Process, Quality Strategy, T-Shirt Size Estimations, and Deployment Strategy |
Milestones | The QA team would identify the key milestones required to execute and reveal the product quality strategy. | Set Testing Milestones, Identify Risks, Finalize Project LOE, and Definition of Done |
Execute Stage
This stage allows the team to kick off two-week sprint cycles of development based on the feature prioritization done during the discovery stage. The user stories and acceptance criteria are finalized and documented. It allows the QA team to refine estimations and velocity, get the quality strategy approved by the entire team, and begin development of test code in parallel with developers. The key is to collaborate, collaborate, collaborate with the team frequently.
Component | Description | Actions |
Requirements | The lightweight documentation helps to ensure proper reveal and lifetime support of testing. | Three Amigos, Refine Estimations, Feature Prioritization, Review Acceptance Criteria, and Approve Quality Strategy |
Design | Taking the informed deliverables from the discovery stage, UX continues to iterate, test and finalize the design for the project. | Mockups, HTML Element (Locator) Annotations, Browser Support, Wireframes, and Visual Strategy |
Development | Developers and QA begin by working in parallel on the foundations of the prototype and implement code from requirements. | Outline Test Cases, App Infrastructure, Pseudocode, Collaboration, Finalize Test Code (ATDD), Test Management, and CI Pipeline Code |
Quality Gates | Everything gets tested, validated, and reported, from concepts to code. | CI Pipeline - Continuous Testing, Testing Results, Code Reviews, Creation/Merge PR Validation, Everyone Owns Quality, Security Scans |
Project Management | Everything gets tested, validated, and reported, from concepts to code. | Sprint Planning, Sprint, Retrospective, Status Reporting, Backlog Grooming, Daily Stand-ups, and Velocity |
Release Stage
At the end of each sprint, the team will demo internally to ensure that all acceptance criteria have been met. When all features have been built and tested, we are ready to showcase the project to the product stakeholders for a final review before planning the rollout to production.
Component | Description | Actions |
Internal | Each sprint, the team reviews that the work has been completed and satisfies the defined acceptance criteria. | Sprint Demo, All Tests Pass, Acceptance Criteria Met, and Go / No Go Meeting |
External | When enough features have been built, external demos with stakeholders ensure that we’ve met expectations. | Stakeholder Review and Go / No Go Meeting |
Rollout Plan | Begin planning general market rollout— involves deployment strategy, testing, and monitoring per market. | Market Rollout Plan, CI Deployment Pipeline, Production Testing, and Monitoring |
Evaluation Stage
No one ever plans for continuous support for rollout projects. Things break, and real users expose bugs. Providing the appropriate level of testing support going forward is important. We need to continue to assess and evaluate the project in the wild through monitoring and data analysis.
Component | Description | Actions |
Support | The appropriate level of monitoring, testing support from reported bugs, and small feature enhancements. | Monitoring, Bug Fixes, Enhancements, On-going Support, and Continuous Testing |
Evaluate | Taking time to reflect on the sprint positives, negatives, and how to improve going forward. | Project Retrospective and Data Analysis |
The process is now transparent, and is now beginning to strengthen our relationship with the entire team. We see how we need to test things in an agile environment, and the process is an essential component in this transition. (Stay tuned for a future blog post discussing how to pick the right plays for agile testing.)
Conclusion
Is your QA team involved early and often in the project discovery phase?If not, I recommend using my agile process playbook as a template to start having conversations with the entire team about shifting the culture. It's your time to shine, take control, and build your agile process playbook for software testing to build quality into your application, early and often. To test the right things, QA must be part of the discovery phase.
Greg Sypolt (@gregsypolt) is a Test Automation Architect at Gannett | USA Today Network, Fixate IO Contributor, and co-founder of Quality Element. He is responsible for test automation solutions, test coverage (from unit to end-to-end), and continuous integration across all Gannett | USA Today Network products. In the last three years, he has helped change the testing approach from manual to automated testing across several products at Gannett | USA Today Network. To determine areas for improvement and testing gaps, he conducted a face-to-face interview survey process to understand all the product development and deployment processes, testing strategies, tooling, and interactive in-house training programs.
