Well this is a very big complicated question. An arguable & debatable topic. As one can assume all the time, if not, most of the times, QA gets the blame for what they can not do. CODE WELL. If something goes wrong its always the QA who gets the blame for it. Well reason is simple, every project that goes live must have been tested by QA and if it doesn't work well, QA gets the blame saying why you didn't catch it in the first place? whether its a developer's fault not to code to fit to the requirements, or QA has no time to test it, or whatever. It doesn't really matter. At time when managers turn back to Development team, you would also listen to few complaints to do with the coordination between QA & Development. Because QA didn't work well with us, we can not finish the project - umnn.. It doesn't sound so nice. All these things are unprofessional.
I think team should be made aware of what all tasks that QA should do, what're they responsible for and what should they deliver etc Same way for development as well.
| Phase | QA responsibilities should include |
|---|---|
| Sprint Planning | There's only 1 thing QA can do. Be Vocal. Suggest the scrum master that with the current team capacity we can only do x number of stories. Look at a bigger picture of every story that's being planned for this sprint. Ensure most if not, all stories are testable. Plan resources for the amount of stories. Take in only what you can deliver. Its better to keep the velocity taking a moderate spike then a sudden spike that results in losing the quality - Warn about this fact. |
| Kick-off Meeting | Think of whom to assign a story to. If possible, rotate the people from 1 functional area to other for every 3 - 4 sprints. This allows testers to have a bigger picture of business arena that is required. |
| Implementation | Write tests as soon as the sprint starts. May be you use QC to write tests. Print these tests off. Sit with the developer & the product owner/ Business Analyst and agree with the developer to pass these tests by writing unit/ integration tests before handing over to QA for test. Business Analyst/ Product Owner is required in this meet to make sure your tests are a comprehensive list of acceptance tests. Once step-1 is done, Dev is ready to code to pass the acceptance tests. QA is ready to start automating the tests. use proper tools to automate. Well there's loads of other issues that you might encounter if you want to automate in an agile environment that should be a separate discussion altogether |
| QA Testing | This might start on the 1st day or 2nd day or any day during the sprint because we work in an agile environment, there's no separate time schedule rather once development is done QA will be done on that particular piece of work. When you QA this other pieces of functionality might still be under development. Responsibility of tester when code dropped in to is to test it from a system perspective, raise defects. Catch: Every time you raise a defect analyse why this issue was not caught in the unit/ integration tests that dev created? Ensure this is included in Dev tests if its not already done so! |
Well after all this is done, QA will sign off on individual features.
