Moving towards Modern Testing Practices: Easy Steps for Improving Your QA Processes.
When I joined Scoro more than five years ago, the development processes were quite primitive:
- Product managers prepared tasks in isolation.
- Developers worked on their tasks in isolation.
- QA engineers tested the tasks in isolation.
A very simple process that is likely still used today in some software development companies. This process states very clearly that quality is the responsibility of the QA engineers because they do all the testing to verify whether the developer has managed to meet all the requirements.
Now, five years later, we can say we have come a long way. We are constantly improving our QA processes, with a clear long-term goal to operate by the seven principles of modern testing.
This article will describe the biggest steps we have taken so far to move towards achieving that goal, so you could use them as a guide in your company as well.
To understand the full context of this article, it’s important to mention that we are using the Missions Framework at Scoro. Thankfully our amazing VP of Engineering wrote an article about it recently.
Pair review sessions
One of the first things we needed to improve was the lack of collaboration between the QA and the developers. We can’t build quality software in isolation. Our solution to that were pair review sessions. These sessions are our own accidental take on the 3 Amigo Principle (as we didn’t know anything about it before someone brought it up years later. Oops!)
The process is very simple. When a developer finishes building something, they will contact the dedicated QA and plan a suitable time for a pair review session. Once the session has begun, the developer will demo what was built and how. This gives the developer a chance to get instant feedback on their work. At the same time, the QA gets the opportunity to see how exactly something was built and share their testing perspective.
During that session, the main job of the QA is to ask questions. For example, “What happens if I do X?”, “What is the worst case scenario when X doesn’t work?”, “What automated checks do we already have on this feature?”, etc.
Overall this has improved the teamwork between developers and QA, introduced the culture of faster feedback and encouraged developers to take a bigger responsibility for the software quality.
Mob testing sessions
When we first started doing mob testing sessions, we followed all the rules and guidelines to a tee. Over the years we have modified them a bit to better suit our needs, but the main goal has stayed the same — to get all the involved team members together to go over the new piece of software we have been building.
With sessions like that, we have the chance to put together multiple different perspectives. Product manager(s), QA(s), developer(s), designer(s) and, on some occasions, external and/or internal stakeholders as well.
These sessions give us the opportunity to:
- Share knowledge!
- Ask questions and get answers straight away.
- Share and listen to everyone’s thoughts and ideas about the new feature.
- Get everybody on the same page.
- Quickly share and fix bugs without the need to report the bug with all the “how to reproduce this” steps written down.
- Verify if the software works and actually solves the problem the clients have.
- Make sure the user experience is easy, intuitive and makes sense.
Over time the mob testing sessions have become part of our unconscious practice and often we don’t limit ourselves to one session — instead we have multiple ones at different stages of a mission.
Quality blueprint
In Scoro, we plan our testing efforts for missions with something that we call “quality blueprints”. It’s something that combines a test plan and a test strategy.
Quality blueprint can be described as follows:
- A dynamic documentation that changes in the span of a mission.
- A collaborative document. Everyone who participates in the mission takes part in editing and updating it.
- It defines the main goal of the mission and describes how can we make sure, with testing, whether we have reached that goal.
- It lists out different types of testing needs that should be covered — be it very vague ones (e.g. security testing) or more specific to the product (e.g. other related features that need checking).
- Depending on the mission, it contains test scenarios, test cases, user stories or just keywords — it’s very dynamic!
The main idea behind creating and using the quality blueprint is to arrive at a clear and common understanding of what it is we are trying to achieve with this new feature as well as define what is the end goal and what are the priorities when it comes to testing it.
When creating the quality blueprint, we try to take into account those two practices:
“Every minute you spend in planning saves 10 minutes in execution”
(Brian Tracy)
vs
A minute spent on writing down a documentation that no one will probably ever read is a minute wasted not finding a critical bug
This means that we plan as little as possible and as much as needed. For example, we don’t want to write down that someone once inserted the phrase “test123” into an input field in 2022 and then it worked. But we do want to note down that we tested all possible error-handling scenarios and they are fine, but no one has yet checked if there are any security vulnerabilities.
After all, investing some time into planning out your testing efforts by creating a quality blueprint encourages better collaboration. We can share the blueprint with all the relevant parties and everyone from the mission crew can easily contribute to testing.
Conclusion
Now, five years later, the processes between our developers and QA engineers have improved tremendously. The practices mentioned in this article cover only the most significant improvements. As a result of all these efforts:
- Our processes now support better teamwork and collaboration among everyone related to the development processes.
- We actually take the time to think about our customers and their actual problems with the whole team (instead of leaving this part only to the product manager and designer).
- QA doesn’t check if developers met their written-down requirements; they rather focus on the big picture and more specific types of testing needs.
- Developers are taking more responsibility for the quality of the features they build.
All of this, slowly but surely, helps to establish more modern testing principles over time. If you would also like to change the way QA is currently being done in your company, these are just a few first easy steps to take.
If you want to be part of the change of modernizing our QA practises, check out our open positions at https://www.scoro.com/careers/
PS! If you’re wondering about the sheep pictures, their only goal is to raise the cute factor of this article.
