In the era of AI, a common narrative echoes: “AI will replace you.” This sentiment can be intimidating, especially as AI demonstrates its capabilities in drawing, coding, suggesting marketing strategies, and much more. However, today I want to shed light on the evolving role of the QA engineer and share recommendations on how to overcome AI-driven fears by becoming indispensable to your company. The secret? Adopting a business – oriented mindset.
The Current Perception of QA
When discussing QA engineers, their role is often placed squarely in the technical domain. This is true, whether you’re a manual tester, an automation engineer, or a generalist. However, this framing limits how QA professionals think – not just in terms of daily tasks but in their overall approach. The QA mindset often focuses on details, analysis, quality, and metrics centered around tasks and features. We follow KPIs for test coverage, focusing on the percentage of code, functionality, or requirements covered by test cases. We monitor defect leakage percentage – the average time taken to identify a defect after it occurs. We calculate the total cost of ensuring quality, including prevention, appraisal, and failure costs. We also track the percentage of defects identified and fixed during the QA phase compared to the total defects found later. And, of course, we strive to reduce the number of new defects introduced into previously functioning features after updates or fixes.
To achieve these KPIs, we use automation tools, test analysis practices, and various technical methodologies. Essentially, we wear a “QA hat.” But do all these metrics show our impact on business? Do they demonstrate our importance not only in technical fields? No. And if we remain confined to this technical role, it will become increasingly challenging to prove our irreplaceability in the face of countless no-code AI solutions who can do our work.
The Path to Survival: Business Thinking.
To thrive and add greater value in the coming years, QA engineers must adopt business thinking. What is Business Thinking? Business thinking is a mindset and methodology that emphasizes understanding, analyzing, and solving problems in alignment with a company’s strategic objectives. It focuses on value creation, efficiency, and achieving goals while considering customer needs, market dynamics, and organizational resources. Simply put, it’s about prioritizing what drives revenue, focusing on what or who generates revenue for your business. And in almost all companies, it’s the customer! Someone who uses your company’s product, someone for whom we ensure quality, and someone for whom we automate all our processes to enable faster delivery.
Key Components of Business Thinking for QA Engineers
Customer-Centric Focus
Putting the customer at the center of decision-making is paramount. This means identifying customer pain points, preferences, and expectations. As a QA engineer, you have unparalleled insight into your domain, know customer’s problems and can anticipate customer behavior because you work with the application daily.
How to implement this approach in your work routine: When creating test cases, think beyond technical testing techniques. Think about how the customers might use it. What is the value of this feature to them? What are the common use cases and purposes for using this part of the functionality? These questions will help guide your end-to-end testing priorities and identify which scenarios to perform and automate for maximum impact.
Strategic Thinking
Strategic thinking involves aligning your actions with the company’s long-term goals, vision and mission. This includes understanding the organization’s OKRs or company goals.
How to implement this approach in your work routine:
-
Identify company OKRs or goals. OKRs, or “objectives and key results,” are a goal-setting methodology that helps establish measurable goals. While most companies set goals, only 16% of knowledge workers report that their company is effective at setting and communicating them. If you’re unsure about your company’s OKRs, ask your manager or a product manager. This information is typically accessible to employees because your work over the next quarter or two will likely focus on achieving these goals. Knowing these goals ensures your work aligns with the broader strategy.
-
Understand Your Contribution to achieving company goals: Even though most companies set goals, research has shown that only 26% of employees clearly understand how their individual work contributes to company goals. As I mentioned earlier, as QA engineers, we typically operate at the task and feature levels, wearing a technical hat. However, every task and feature, no matter how small, aligns with certain KPIs that contribute to achieving the company’s OKRs or overall goals. Even if your task is something as simple as “adding a disclaimer to a popup,” it can still support a company goal. For instance, adding a disclaimer to a popup may support the goal of “delighting customers” by ensuring clarity and trustworthiness.
-
Present Results of your work through a Business Lens. You need to frame your work in terms of its business value. Let me give you an example from my experience. We needed to switch from one library to another for generating PDF documents due to a potential regulatory breach. It was a completely technical task, and as a QA, my job was to verify the transition by performing smoke tests. Does “I performed smoke tests on the new PDF generation library,” sound like something meaningful to the business? No. But if I rephrase it as “I ensured the resolution of a regulatory breach in PDF generation” it demonstrates the impact of my work on the company’s objectives and brings a clear business value. By the way, regularly practicing this approach has another benefit: it makes completing your performance evaluation forms or updating your CV much easier. This is because you’ll focus not just on listing responsibilities but on emphasizing your impact.
Problem-Solving and Critical Thinking
QA engineers excel at identifying issues, but applying critical thinking through a business lens elevates this skill. As a QA Engineer, you already possess these skills. However, applying critical thinking through a business lens elevates these skills.
Here’s how to implement this approach in your routine:
- Use root cause analysis or the 5 Whys technique to identify problems. For example, as a QA, I received an average of 15 bugs per sprint from CS. After the third sprint, I started thinking about what we were doing wrong in our part of the application that was causing constant customer complaints. As a result, using several types of analysis, I identified the root cause. However, the problem wasn’t a quick fix; it was due to logical changes that required significant refactoring. If I had left it as is, the issue would likely have stayed in the backlog, perhaps indefinitely.
- Use critical thinking to Calculate Business Value:. The one thing no one can’t argue with when making decisions is numbers. In business, these are often referred to as KPIs. You need to find and calculate KPIs for your problem to make it relevant to the business. This might involve calculating saved time, reduced costs, or improved customer satisfaction. The easiest KPI for QA to measure is time. If we stick with my previous example, I’ve calculated how much time each sprint the developers and QA were spending to fix related bugs. In parallel, I asked the developers for a rough estimation of the refactoring effort. In the end, I learned that if we refactor now, we would free up 1/3 of the developers’ capacity over the next three sprints. I then presented this to the product and business managers, who agreed to greenlight the project.
Collaboration and Communication
QA engineers should collaborate not only with R&D teams but also with customer support, product management, marketing, operations, etc. Expanding communication channels allows you to identify shared goals and contribute more broadly. Don’t be afraid to think outside the box – it’s a new reality for QA specialists to demonstrate their value in the upcoming future.
Let me give you an example of how this can be implemented in practice. I noticed that each bug reported by customer support took half a day of a developer’s time just to collect the necessary details. Not to investigate, but merely to gather the information needed to start the investigation. The problem was in how bugs were described in the customer support department. For me as a QA, the solution was clear: implement a standardized bug report structure with the following details: steps to reproduce, expected result, and actual result. But without business value, no one will support this change. So, first, I calculated two different KPIs—one for the customer support department and one for R&D. Why both? Because each department needs to see how they will benefit and how it will contribute to achieving the company’s goals. As a result, customer support would be able to respond 25% faster to customers according to the current SLA for problem-solving and investigation. RnD would be able to receive additional devs capacity for new tasks, and users would be more satisfied with the speed at which their issues are resolved. Presenting these results highlights how a simple change supports the company’s broader objective of “delighting customers.”
The Value of Business Thinking in QA
Incorporating business thinking into your daily work not only helps you compete with AI but also positions you as a valuable, strategic contributor. By aligning your efforts with company goals, focusing on customer needs, and presenting your work through a business lens, you transition from being a technical resource to a business enabler. QA is no longer just about finding bugs; it’s about driving success.
