As a quality assurance (QA) engineer, the most common issue I have faced when entering a new project is not clarifying the business logic. Most of the time, what I start working with is only the acceptance criteria created or written by technically skilled people, which leads to assumptions that translate into missed implementations and gaps in functionality. All of these issues eventually result in rework for the whole team.
In a new project, even when there is information missing, it is not well accepted to go to the product owner multiple times to clarify the requirements, especially since it is assumed that all of the requirements are ready to be developed in most cases.
We can avoid this problem and many others by having a QA mindset. We, as QAs, tend to think about multiple and weird scenarios, edge cases, and many more things as soon as we know the business logic. That’s why it is essential to let go of the emotion of starting a new project, which is challenging. If this emotion is familiar to you, let me save you some time, headaches, frustration, and stress by sharing what I have learned from that situation.
We will be covering the what, how, and why it is essential to change the way we think and the way we start a new project. These practices are mostly related to agile processes, but anyone in any project can achieve them.
What is QA, and Why Does it Matter?
Sometimes, the development process tends to focus on getting more things done and not on doing a thorough validation, sacrificing quality practices.
In most cases, QA is responsible for the quality of the product and is called upon to write test cases, automation scripts, test plans or establish the rules of what needs to be done before delivering. Still, the truth is that QA is not perfect. (It can sometimes be, but this is not common.) QA might miss some edge cases and other scenarios, so it is crucial to change how projects see QA. In short, we need to change the way we do quality assurance, and we can do this by having a QA mindset.
We usually think of QA only as a role, and as a matter of fact, QA is a role, but it can be more than just that. Why can’t we all have a QA mindset, where the entire team acts as a whole? QA as a mindset is a way of thinking, and QA should not be seen as separate or independent from the development process; we all should be QAs.
How to Start Thinking as a QA Engineer
When you have a QA mindset, the development process becomes easier from start to finish. By adopting this mindset and taking a big-picture view of the project, your team will cover most of the scenarios that a regular user will encounter instead of just focusing on individual requirements.
This can be achieved by providing QA mentorship or advice before a project begins. By mentoring, I mean teaching the team to detach themselves from their original role mindset, which can be project management, UX/UI, development, SRE, DevOps, etc.
The objective of this is to break the paradigm of developers only focusing on development, and QA engineers only on testing, especially since developers tend to focus more on technical solutions rather than user experience. We want to get team members involved in QA and think about what type of testing is required to deliver products better.
In short, QA should start when the idea first comes up. Suppose we can enable every role in the project to have a QA mindset. In that case, many of the gaps, edge cases, missing action flows, missed business logic, and missing scenarios will be covered. There are not going to be many surprises when the project starts. We can translate this into not spending or wasting time addressing missing pieces that weren’t considered when the project was born.
Best Practices for Spreading the QA Mindset
- The team needs to work together on adopting this mindset, even when a QA engineer is not assigned to the project
- QA engineers should be ambassadors promoting the QA mindset, teaching their colleagues that tests are not only implemented at the code level but also need to be checked through passive testing.
- The best-case scenario is to have a QA engineer from the beginning of a project since they can a.) help you learn how to adopt the mindset and b.) give you a more accurate idea of the edge cases that can be missed
If the whole team has a QA mindset, it is possible to start thinking ahead on identifying edge cases, weird scenarios, gaps in features, missing business logic, and avoiding many bugs, defects, and missed implementations. As the saying goes, “Quality is not an act; it is a habit.”
For more on this topic, check out the article “How to deliver quality assurance at speed.” If you need help trying to start changing your team’s mindset or want to share some ideas, drop our QA practice an email at email@example.com.