Many companies over the last 10 years have struggled to adapt to Agile and many still are in the quasi phase of trying to convert. Myself, I have been through this at least 20 times in those 10 years as a consultant and as a full-time employee. Every company implements Scrum – Agile differently to what best suits their environment, and that is the beauty of Agile true adaptability.
One of the largest obstacles most face is the ability to roll QA and testing in to the same sprint as development. Ideally it is the product owner creating a story then development executes it and then QA tests it. The problem is most companies fall back in to the same trap as in the waterfall process – QA rolls over in to the next sprint or are handed off stories one day before the end of the sprint or even worse QA is not part of the storyboard.
I want to share what I have learned is the most successful way to ensure that a story is introduced – developed – tested and passed by QA in the same sprint. This requires planning upfront and training of the entire agile team and needs a strong hands-on QA leader who will enforce automation and expectations of delivery. At the project onset and at every new sprint the key leaders need to meet before the sprint planning meeting. At that time the breakdown of the stories is key to the success – down poorly you fall back in to waterfall. Each leader (design-database-IT-development-QA-support) agrees how the stories will be split up that will allow each member to assign someone a task needed for the completion. This meeting is crucial to have before the sprint planning meeting.
At the sprint planning meeting all team members need to be present and each allowed to voice and estimate how long and what time they can complete their task. If the development-design-data task itself takes the entire sprint then it should be broken down in to a smaller story or taken off the sprint and considered what I call a foundation sprint. QA should add their own stories that would not only include “test the story xxxx” but also the following:
- During the design of a story – QA should task for the review of the design of the story
- QA should task review of developments completion of unit tests as this is critical area often “skipped” in the rush to release.
- QA should task stories related to environment testing – security testing – service testing – performance testing – load/stress testing – compatibility testing – system testing – scalability and accessibility testing etc.
- QA should also task regression testing for each sprint
If planned correctly QA should be able add on an automation script for each new story and execute upon completion of the developers story. When an estimated story completion falls behind QA can jump to another story and continue on schedule.
SQUASH During the Foundation Stage
During what I refer to as the foundation part of a new project i.e investigation – research – platform design – database schema etc, QA should be doing the following:
- Researching and learning automation tools that will be critical for regression, UI, database, services – browser compatibility etc.
- Begin building the framework for those automation suites
- Plan meetings with the product owner to determine the expected deliverable of the design and coordinate beta testing or quality feedback issues.
- Meeting with the architects of IT, Data and Development to completely understand the entire environment and system
- Designing test strategies – plans – risk assessment – policies and procedures
- Setting up the test – deployment – staging environments- labs
- Setting up a easy to use but greatly detailed bug database
- Setting up the Continuous Integration Build and Release environment
So how does a company who has to get a critical product out the door on an accelerated time frame improve the speed and quality?
SQUASH for Continuous 24hr Delivery
This is merely meant to be a suggestion for those wanting Continuous 24hr turnover on a project under extreme deadlines. I am often hired as a consultant to work on nights and weekends performing QA and Testing on Agile projects which allows the company to develop during their day hours and receive my reports when they arrive at work. This is what I refer to when I state Hiatus – I am working off the regular sprint work hours of the project. This is a useful methodology for a start of a project on a compressed deliverable or one that has fallen behind on a schedule. And is a great stop gap while implementing the method explained above.
This is a draft and will be modified and improved as time allows – and meant to be a rough guideline in response to all of the emails I am receiving on this subject.