What is QA 2.0? If you’ve heard of and understand Web 2.0, then you’ll definitely know what QA 2.0 aims to achieve.

Web 2.0 is about interaction and sharing, whereas QA 2.0 focuses more on the core aspects of “relationships” and “communication.”

Since there’s a 2.0, what is 1.0? It’s actually the traditional testing methodology. I need to work to test more accurately, test more extensively, and test faster. However, what QA 2.0 aims to address are the issues that traditional methodologies can’t solve. It deals with problems that neither technological advancement nor efficiency improvements can resolve, namely how interpersonal and organizational relationships affect software testing and software development efficiency.

In future articles, we will use short stories to guide everyone in thinking about software testing.

Story:

Fabian has been a software testing engineer for a year now. He’s always had a nagging question in his mind. One day, he decided to visit a bookstore specializing in information technology, hoping to find a technique that could address his burning question: Why does it always seem impossible to complete testing?

Fabian’s company is large, with over 20 people in the testing team, including many experienced experts employing various software testing techniques. However, they always seem to run out of time for testing, often choosing to release versions without proper testing, leading to numerous customer complaints and grievances.

Standing before a shelf filled with software testing books, Fabian felt overwhelmed. Opting for a brute-force approach, he began flipping through each book one by one. Hours passed, and he encountered numerous testing techniques—from defining quality to applying AI in software testing—many of which his company had implemented. Yet, he felt the answer to his question wasn’t as straightforward as a lack of technical expertise.

Do you know the answer to his problem?

Guidance:

Engineers in the technology industry often have a natural tendency to solve problems with technology because it’s within their control. What they tend to ignore, because it’s less controllable, are the human elements—areas like sociology, psychology, and economics. After all, in the binary world of computers, it’s either 0 or 1, true or false. But work is made up of human relationships, complex entities often oversimplified into singular metrics like manpower, duration, and resources, while forgetting the variability of human nature.

Experience:

I once attended an interview at a company with nearly 1,000 employees. As it was for a senior management position, the interview was conducted by a high-level manager (M) and the CTO (T). During the interview, M asked: “How would you increase the efficiency of the testing team and reduce turnover?” This question was right in the alley of Soc-Psy testing, so I began explaining my approach:

“I would understand each testing engineer’s thoughts on the current workflow, the obstacles encountered in teamwork, and make fundamental improvements in communication, process, and system to address the inefficiencies in software testing…”

Before I could finish, M interrupted:

“No, no, no. I want to know how you would reduce our three-day testing to one day, or make the engineers test cases faster and more.”

This is a classic example of result-oriented thinking, equating beautified numbers with efficiency. I disagreed:

“There are many ways to meet these metrics, but chasing numbers alone can disappoint quality-focused testers, and won’t solve the turnover issue…” But M interrupted me again.

“Solving turnover is easy, I have a quick and powerful solution,” he claimed confidently.

“I just set a strict 9 AM to 6 PM working schedule, and nobody will leave,” he said. The room fell silent for 10 seconds before T asked another question, ending the farce.

Don’t ask about my expression then; it was probably the most impolite I’ve ever been.

Identifying the Problem:

Agile and Scrum are popular in the tech industry, driving efficiency with fast-paced project timelines. From a business perspective, rapid iterations adapt quickly to market changes. However, many companies misuse these methodologies, pressuring team members to produce more in less time. This often leads to choosing the quickest solution rather than the most suitable one, setting goals focused merely on time reduction. M, the interviewer, fell into this metrics trap, even simplifying turnover analysis to an absurd solution.

Solution:

When facing a problem, it’s common to directly seek a solution that makes it disappear, neglecting the myriad reasons, limitations, and compromises behind it. The goal of this topic is to encourage a calm analysis of the real reasons behind persistent issues, especially in frequent, annoying problems. Why is testing never complete? Is it always due to low testing efficiency? Are these the real problems? Commonly, issues arise from:

• Inappropriate project scheduling without considering testing time.
• Volatility in product design, despite Agile’s embrace of change.
• Development team’s quality, often failing to meet project deadlines.
• Lack of prioritization in test items, leading to late discovery of critical issues.
• Excessive ‘meteor’ tasks in projects.
• Too much time spent on communication and understanding each other.
• Lack of effective communication, preferring messaging over face-to-face discussions.

Consider your software development team and reply below with the possible root causes in your team.