How QA engineers could affect product quality? Part 2: Scrum and planning.

This is the second 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 first part we discussed difference between testing, QC and QA.

There is no such thing as universal best practices or silver bullets. So, to be concrete, we need first to define some context important for further discussion. In our case this context is development process. I have chosen Scrum as the most popular Agile methodology, but the same principles could be adopted for any iterative development approach. I hope everybody is familiar with Scrum, really hope after so active push from Agile community to use it everywhere during last 10 years. It seems most of you know it or at least think you know it.


To be on the same page I will spend 2 minutes describing Scrum basics very shortly. We have PO who is responsible for Product Backlog management, including refinement and prioritization. We have also Scrum team, ideally self-organized, motivated and cross-functional (in ideal world at least). Development is organized in short iterations called Sprints. During Spring Planning PO presents highest priority features and the team decides what could be taken into Sprint Backlog (scope of the Sprint team thinks is possible to deliver at the end of the Sprint). Team decomposes requirements in development tasks and start working on them. All team members gather daily to sync their efforts, discuss progress, risks and potential issues. At the end of the Sprint team has potentially shippable product increment with all features from Spring Backlog. It is demonstrated to the Product Owner at Sprint Review meeting, where PO accepts done work and discusses raised issues with the team. Then team organizes Sprint Retrospective meeting to inspect current process and find room for improvements. That is it! You see how simple Scrum is from this description and how complex it may be sometimes in the real world. 😉

Scrum

So, let’s return to our main topic. What is the first place where QA engineer could focus their efforts to build quality in? Of course, Sprint Planning! True Scrum practitioners can stop me here and say: “What about Grooming? It happens before Spring Planning, so we could affect quality even earlier in development cycle!”. I completely agree with them, but at the same time Grooming format is more lightweight in comparison to detailed planning, so my advices from this section cover Grooming as well.

This is our first stop. Before describing QA engineer goals (don’t forget we are talking about the role, not dedicated person) and concrete activities on this meeting, let’s remind yourself whom we invite there. We definitely have PO, who is focused on business value and represents real business stakeholders. We have technical team, that is experienced in technologies and focused on technical decisions. You see, they are from completely different worlds. And here most problems start to appear. The most important task for QA engineer role here is to work as a glue between PO and the team, making them get to common vision and understanding on all discussed functionality.

Scrum Planning

First of all, QA engineer bring testability and risks questions on the table. How are we going to test this functionality? Do we need additional data to be gathered? How could we demonstrate implemented features on Sprint Review meeting? How will PO accept them? What visible risks do we have? Probably, we depend on something outside of our control or there are still some blank areas or open questions.

The second topic is scope clarification. QA engineer must make sure everybody understand what and how we are going to build as a team. Here such artefacts as whiteboard with markers or paper could be very helpful for most cases. Draw prototypes, discuss them in details, write common notes and comments during discussion, then make a photo and share it with the team attaching to requirements or specific tasks.

The next important topic is external integrations. Are external systems ready for integration? Do they have test accounts that could be used for demo and testing activities? Could we implement or use some stub/fake implementation of external API to simplify development? Do we know availability SLA of these systems? The list of questions in this area is really unlimited. External integration usually makes system distributed and significantly increases system complexity causing more complex approaches in other development areas as well.

Test planning is also an essential activity. It defines how our overall testing strategy will be applied to specific functionality implementation, what kinds of testing efforts do we need and when they will be applied, who will be responsible for them. Without such planning it is very easy to end up having famous ice cream anti-pattern instead of test pyramid. Right balance of automated tests at different levels should be discussed and what remains in manual testing area.

Scrum doesn’t prescribe in what specific order tasks are implemented inside Sprint, but Scrum is based on both incremental and iterative principles. Building stuff incrementally inside Sprint significantly reduces risks and allows distributing testing in time. So it is important to build internal delivery schedule, focusing first on both high priority and risky from quality perspective User Stories. Very frequent example from teams, where such discussion is missed on planning meeting: User Story is delivered 1 day before Sprint end date, but at least 2 days are needed for full testing of this User Story. In addition, internal delivery schedule adds more transparency and simplifies team progress understanding.

Developers frequently tend to forget bad things happened in the past. This is natural people behavior to forget bad things. So they have optimistic view on their estimates, don’t take into account historical perspective. QA engineer should remind about issues and defects in the same or similar component returning them to reality.

And, finally, non-functional requirements. They are like Schrodinger’s cat because they exist, but at the same time nobody take them into account. Usually they are stored somewhere in KB and in the best case formalized enough instead of such generic statements like “our website must be quick enough” or “all communications must be secured”. If you don’t take non-functional requirements into account, it works like a time bomb with predictable disaster at the end. Who is responsible for this reminder? PO actually described them long time ago and believes we will always take them into account. Team is not always aware of them or just forgot about them because they bring only constraints to their technical solutions. That is why QA engineer as neutral role works the best for this purpose.

In the next part we will cover other stages of Scrum and role of QA engineer on these stages. Stay tuned!

Обсуждение (0)

Leave a Reply

Your email address will not be published. Required fields are marked *