This is the last 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 third part we discussed QA engineer role involvement in Daily Scrum and User Stories acceptance.

Almost all work from Sprint Backlog is done and team would like to prepare potentially shippable product increment. It is too late to build quality in, but again we have time to fix it at least for client visibility. One of essential activities at this stage is regression testing to make sure existing functionality works as expected.

First of all, I really hate this phase with it’s stupid name and in my projects I always try to reduce or avoid it completely. Just imagine, we worked almost 2 weeks and now want to “stabilize” what we have in hands. It seems we are producting crap and our development process is like a big continuously working garbage producing machine. But life is not always ideal and this phase is present on many projects. 🙁

QA engineer still could continue to be smart affecting visible quality like on previous stage.

Regression testing activities should be distributed across all team members. It is completely OK to involve developers, business analytics, PO or even external people to make regression testing more effective. At the same time regression testing should be strictly prioritized to focus on important parts first.

Impact analysis could help here in some cases to find areas affected with higher probability than others. But believe me, even developers usually can’t predict for sure what will be affected by their code changes.

Manual efforts should be synchronized with automated testing as much as possible. There is no need to duplicate efforts and run the same scenarios automatically and manually. Focus more on end-to-end business scenarios and areas not covered with test automation.

And again effective communication of found issues. At this stage it is even more critical because nobody have time for reading long bug description in bug tracker. Use live chats or face to face communication to make feedback cycle as short as possible. Defect should be added to bug tracker only if it is clear that we don’t have time to fix it and will not even try.

The last but one of the most important points where we could affect quality is Sprint Retrospective. Team has chance to analyze last Sprint results, including quality achievements, and find together room for improvements. This is mandatory and very valuable part of the development process.

QA engineers here should focus whole team on quality issues and initiate useful discussions.

So, for every quality issue root cause analysis is initiated. I mean true root cause analysis, not blaming game or finger pointing. Root causes like “John failed this task because he is bad developer!” are useless and will not help us to improve situation with quality or prevent such kind of issues in the future. One small tip to introduce such practice to the team as a regular activity: make mandatory ‘root cause’ field in defect tracking tool and forbid to close blocker or critical defects without filled root cause analysis section.

Issues should be discussed in active format with whole team participation, not in dictating form by single person. All significant problems related to quality must be listed and shared across all retrospective attendees before the meeting.

QA engineer should always challenge current approaches by asking questions like: “What else we could do to improve situation with quality?”. This is never ending learning curve based on factual information from previous discussions and root cause analysis.

And finally QA engineer updates important artefacts used on previous stages for risks management and impact analysis adjusting them with latest Sprint results: heat map, test/code coverage, test data management.

QA engineers must be part of the team, because it is almost impossible to build quality in if you are not involved at all stages of development process. Quality is a shared responsibility of the whole team and can’t be just improved from outside or delegated to separate person in the team like QA engineer. From all discussed activities you probably already understood, that this role is definitely not for junior level. And this is just a role, not particular person, it may be taken by experienced developer, DM, QA Lead or somebody else, who understands development process very well and cares about quality.

QA engineers must continuously focus on quality and possible ways to improve it from Sprint to Sprint. Then not only customer and end users would be happy with high quality product but at the same time development process would become more predictable and easier to manage.

Hope this was interesting and useful journey for you. For those of you, who think all these advices are trivial and obvious, please start applying them in your team and share with other projects in your company. We could change the world together! 😉