Being QA is hard, really really hard. There is so much that we do as a QA, but sometimes even we don’t know what and how much we do to keep the entire engine of the software development process going. The QA team members are involved in the maintaining regression suite and current sprint work while working on the stories of future sprints. QA is the only role engaged from the beginning to end of the software development process. If the above statement is not true for your team, you should apply some changes, and maybe this blog can help.
QA team cover the past, hold our present accountable while still working on future sprints. Having said that there are a million flavors of agile and they all do things little differently. If QA’s on your team is not involved in all the process, you should work on empowering them and engage them earlier in the process.
No matter what flavor of Agile you follow, at some point Devs, QA and BA should get together and agree on the story. Ideally, the team agrees on the scope of the story before it is marked “ready for dev”. Each team member is on the same page. The wireframes are designed and delivered to the team and acceptance criteria’s are defined. The questions are researched and answered by the product team.
Though the responsibility of high-quality stories falls on the entire team , QA’s prime responsibility here is to identify defects at this stage of the story. The first opportunity for a QA ( & team) to shift quality left.
- Defect identified in grooming is the cheapest to fix; the implementation of the story is not started.
- When developers know what their story tested against, chances of defect showing up is less.
- It proves the concept of “Prevention is better than detection”.
Test Cases – Future Sprint Stories
There are many forms of implementing/defining test cases scenarios for future sprint stories. Some QA team spend time in grooming session and talk about scenarios but not necessarily implement them but others do make a point of defining test scenarios, identifying test data and need of test harness before the story is marked ready for dev. This is the perfect example of shifting quality left. When test scenarios and test data are available to the development team, they are more likely to test them and chances of defect showing up is low, very low.
In a fast-paced development environment, it is hard to slow down and implement processes that shift quality left. If you can sell your management the benefit of slowing things down to speed it up and implement these processes. You will have the glory of high-quality product which you can ship… continuously.
Current Sprint Testing
The very visible responsibility of a QA team. At any given point QA team members are actively working on current user stories. The goal is to fail fast, fail early and fail often. Vetting requirements and discovering what isn’t working as per specification comes from the collaborative goal of product, development, and QA. No matter what kind of product or tech stack you are working on one should automate tests. With modern tech stack and modern development practices, there is no excuse to not automate your tests.
In my work experience, QA is always involved in some capacity in the Sprint Demo. I have also worked where QA’s demo the story. If they are not demoing, QA team members are responsible for test data or implementing test harness. At some places, the Sprint demo is done casually but some team demo’s to clients or Sales, Sprint demo is a big deal and a considerable amount of effort.
By definition, regression testing is the process of executing tests to make sure that features implemented in the past work along with the new feature being implemented. It does not matter if your regression is manual or automated. You still have to modify them as per the latest feature changes, implement and maintain them according to new feature implementation. In most of the projects, regression is 60-70% of the total effort of any QA team. A well-executed regression test is key to continuous delivery.
Sprint sign off
Yes, I have already mentioned current sprint testing and regression testing, and yes they are part of your sprint sign off. It needs to be discussed because there is so much too and fro between QA’s and team. Sprint sign off depends a lot on the nature of the project. If your team deploys at the end of every sprint, Sprint sign off is a serious affair. Team (sometimes product) decides on defects they can live with and the one that requires fixing before deployment — this process involves communication, approval, last minute code changes and re-testing. The entire team works on this, but the QA team is leading the effort.
There are other things QA team is involved with as well: release testing, User acceptance testing, environment sign off. They are not every sprint responsibilities but they are in addition to sprint responsibilities.
Is there anything else that you would like to add to QA’s day to day responsibilities.