This is the third article in the QA articles serie based on my conference talk about true QA process implemetation and how QA engineers could improve quality of your product. In the second part we discussed Scrum process and QA engineer role involvement on planning phase.

OK, Sprint is planned and successfully started. The second point where QA engineers could affect quality is Daily Scrum.

First of all, QA engineer reminds the whole team on a daily basis about their common commitments and discussed risks during Sprint Planning. Many developers are too optimistic regarding their progress and chances to finish everything in time, so they completely forget about risks and concrete due dates.

Early results review or preliminary demo is also important factor to improve quality. There is no need to wait until everything is done for User Story to provide valuable feedback. Feedback cycle should be as short as possible. QA engineer could do early results review on developer’s machine, on shared or local environment. The goal is to review current state as soon as possible to find visible issues early and save time on rework. It is even possible to organize such reviews at several stages to build “feedback onion” instead of “big bang feedback” when all work is finished.

Of course, on the daily basis found issues and defects must be communicated, so the whole team is aware of current quality status and problematic areas.

And the last, but very important activity, is helping developers with tests and test data. Not all developers are good at test design practices, as a result their unit and integration tests are far from ideal. QA engineer should spend time on education in this area to spread knowledge in the team and improve quality of developer level tests, reducing probability of defects at this level. And it is very important to use meaningful data for all tests instead of just garbage values without any context. Then it is much easier to link test scenarios at different levels and understand what test really means from business perspective.

After some time first stories become READY and passed to internal acceptance. This is our third point, where QA engineers could affect quality. But most of development work on User Story was already done and quality from this point of view will remain as is, we could just run QC procedures and report issues. But from another point of view, Sprint is not finished yet, and we have time to improve quality visible to the client. This should be our main focus starting from this stage.

So starting from this stage QA engineer should be really smart. QC procedures and testing activities should be organized in such a way, that real issues reported ASAP to developers without wastes and rework. Some examples on this topic:

• start testing from the most risky areas instead of just following test cases;
• use quick direct communication with developer instead of bug tracker system, Sprint is not finished, so found issues could be handled as unfinished work instead of defects;
• practice pair testing with developer to avoid miscommunication and providing maximal control when defect really happens;
• adopt ideas and practices from Exploratory Testing to save time on repeated steps in several test cases;
• use “record and play” tools to create repeatable scenarios instead of manual description of steps to reproduce.

User Story may be passed on internal acceptance several times after fixes applied, so it is important to reduce manual work as much as possible to remain effective. This is good driver behind test automation movement with clear motivation and benefits in terms of time saving.

In the next part we will cover “stabilization” phase, retrospective and make some summary of QA engineer role. Stay tuned!