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 be able to cover most of the scenarios that a regular user will encounter instead of just focusing on individual requirements.

QA as a Mindset, Not a Role

Introduction

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, I start working with 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 information is 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 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 cover the what, how, and why it is essential to change how we think and 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, and 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

With 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.

This objective 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 consider what 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. Many gaps, edge cases, missing action flows, business logic, and scenarios will be covered in that case. 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 plan 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

Conclusion

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 qa@wizeline.com.