The Power of Systems Thinking in Quality Testing (QA) Engineering

Hello, my name is Elena Rukavichnikova, I am Head of QA and teacher of the “Software Functional Testing” course at IT Academy. For over 7 years I have been immersed in the world of testing, taking part in more than 20 exciting projects.

Once I spoke at a conference with this topic and decided to share it with you.

Regardless of how much has already been said on this topic, each of us has a unique experience and perspective that can make a valuable contribution to the overall dialogue.

In the early years, I had a fairly rapid career growth and in this article I want to share with you one of the key approaches that contributed to my rapid career advancement. Being myself at the start and going through this experience, I can confidently confirm its effectiveness and usefulness.

Sometimes we can easily get caught up in the day-to-day tasks of software quality assurance. However, if we limit our thinking to assigned responsibilities, we risk missing the bigger picture and understanding of how our work impacts the entire project.

If you do not see where your project is going, what is important to the user, what is important to the customer, it will be difficult for you to suggest any improvements for the project. This is where systems thinking comes into play.

systems thinking is the ability to see beyond individual tasks and understand how they fit into the overall context of the project. It is about recognizing the interrelationships of various components and stakeholders and how they affect the success of the software.

Let’s look at a few scenarios to illustrate the importance of systems thinking in quality testing engineering.

Example #1

Feature test planning

Imagine that you are tasked with testing a new feature for a massive project. The traditional approach might involve focusing only on the function itself and creating test cases specific to its functionality. Although necessary, the systems thinker goes further.

It looks at the larger system in which the feature functions. It explores interdependencies between a feature and other components, such as integrations with existing modules or potential impact on user experience. In this way, the systems thinker can identify additional test cases that provide comprehensive coverage and identification of possible problems related to the relationships in the system.

Example #2

Bug fix prioritization

As a quality test engineer, you encounter a lot of bug reports from users or stakeholders. The traditional approach might involve treating each error as a separate incident and fixing them individually. However, the systems thinker approaches this differently.

He understands that errors are often the result of hidden system problems rather than isolated incidents. Instead of just fixing the reported bugs, it goes deeper to identify the root causes. This may include an analysis of the interaction of different modules or an examination of potential problems in requirements or communication. By addressing these root causes, it not only fixes the reported errors, but also prevents similar problems from occurring in the future.

Example #3

Cooperation with development and support teams

In a typical project, QA engineers work closely with development and support teams. Traditional thinking can prioritize a smooth transition and individual team performance. However, the systems thinker understands the value of collaboration and its impact on the overall quality of software.

He actively seeks to understand the goals and problems of other teams and is aware of how his work relates to these goals. By facilitating strong communication and collaboration, a systems thinker can identify potential bottlenecks, streamline processes, and ultimately improve the efficiency of the entire development life cycle.

Systems thinking in QA engineering goes beyond performing only immediate duties. It involves taking a holistic view of the project, understanding the relationships between the various components, and being aware of the overall goals and objectives of the stakeholders.

In more detail about determining the root causes of the problem (root cause analysis), there is a fairly simple, albeit at first glance, technique “5 why”. This technique was developed by the founder of Toyota, Sakichi Toyoda, to solve production problems.

The basic principle of the method is to consistently ask five “why” questions to uncover the root causes of the problem. Let’s look at some real examples to better understand its application in the context of manual testing.

Example #1:

Problem: Recurring defects after fixing.

1. Why? developer does not test fixes

You can stop here and tell the developer to test fixes and work faster. But what if we go further:

2. Why? the developer does not have enough time to test

3. Why? many tasks in the sprint to fix bugs

4. Why? features are delivered poorly described from here functionality with bugs

5. Why? business analysts did not waste time describing field validation, considering it an obvious task, but did not take into account that the developer is still Junior.

Example #2:

Problem: Lots of duplicate bugs.

1. Why? third-party testers do not check for existing bugs

You can stop here and point out the need to search for bugs by keywords before publishing them. But what if we go further:

2. Why? testers are not aware that this feature has already been tested

3. Why? the board did not mark the passage of the feature by another tester

4. Why? management decided to play it safe and features are tested twice by different teams

Hence the duplicates and double work. Further clarification of the reasons passes into the competence of managers.

Example #3:

Problem: Missed a bug.

1. Why? there was no time for a complete regression

You can stop here and solve the issue with overtime. But what if we go further:

2. Why? included a new feature during the sprint

3. Why? it turned out that the client wanted differently

4. Why? not involved at earlier stages when agreeing on how the functionality will be implemented

Here, you may have noticed two problems: insufficient testing and the inclusion of features in the current sprint. However, the root cause solves both of these problems.

As you can see, developing systems thinking skills can bring significant benefits to your job as a QA engineer. You will be able to suggest more effective improvements, identify potential risks, and contribute to the overall success of the project. By looking beyond your responsibilities and understanding the overall system, you will become a valuable tester that will affect your career progression.

So the next time you work on a project, remember to think beyond your responsibilities. Adopt systems thinking and discover new opportunities to improve software quality and project success.

If you are interested in this topic, I will write a sequel about problem analysis techniques.