The quality in Quality Assurance: What does a good approach look like?

Curated by: Sergio A. Martínez

And as bugs were some of the most notorious problems of this game, it also presents the opportunity to talk about a very important part of software development, which can make or break a product: Quality Assurance. What does a good implementation of QA look like? What does it aim to find, and what are the best ways to go about it? And more importantly, what makes a good QA process?

1. Quantity of over quality (assurance)

An anonymous source within Quantic Labs, one of the firms in charge of QA in Cyberpunk 2077, told journalists about a “bug quota” imposed by management on their testers. With the requirement of reporting at least 10 bugs per day, the logic seemed to make sense: encourage your testers to be as thorough as possible, and thus ensure the final product will have the highest quality. However, if you are familiar with how the QA process works, you are already wincing because you know where this is going.

Quality Assurance is an important part of software development that, by ensuring that code is well-tested and meets standards, helps to improve the efficiency of a development team, and several good practices can help to ensure a successful quality process. Quotas can have the precise opposite effect, slowing down development by flooding developers with meaningless reports. Which, should be said, is no fault of the tester; after all, what is the result if they fail to meet them?

“I’ve worked in QA since 2011, been a Team Lead for the last three years, and bug quotas are a bad system which achieves absolutely nothing good”, explains one of the comments in the aforementioned article. “First, your testers enter a load of unproductive bugs, because they will divide one issue up into as many possible JIRA entries as they possibly can. And on top of that, they don’t have time to properly investigate the more complicated issues that they find — you get a lot more crash bugs with horribly elaborate reproduction steps because testers can’t afford to spend two hours nailing down exactly what triggers them.”

So with measures like these, the management of a project can unintendedly encourage bad QA, as it makes it more about the number of bugs found and less about their importance. So instead of quotas, a better method could be to ensure that everyone knows the priorities of the project, and have a clear definition of what constitutes a bug or issue (to let developers know when they need to fix something). Understand that QA is an important part of the development cycle from beginning to end, and enough time to do proper research and testing on bugs and issues is crucial in the planning of any successful project. Speaking of which…

2. Not a step, but an ongoing process

One of the biggest myths about QA testing is that it’s a one-time event that happens at the end of development. This simply isn’t true. Even if many people think it’s just a matter of catching bugs before a product is released, QA testing is an essential part of the software development process, and it should be treated as an ongoing collaboration between developers and testers.

This means regularly testing code and providing feedback to developers throughout the software development lifecycle; after all, effective QA testing is about making sure that a software application meets the requirements of the end-user. This means ensuring that the app is easy to use, bug-free, and performs well under real-world conditions, and QA testers play a vital role in ensuring that these standards are reached by working closely with developers throughout the whole project.

“Companies that realize the importance of Quality Assurance encourage employees to look at every part of the software development process as a “product” that has its consumer”, is a good explanation given by this blog from the QA firm Syndicode. “Defects are possible at each stage, so it’s important to ensure all participants adhere to the quality standards.”

After all, QA testing needs to be a collaboration between developers and testers, but it can also be heavy on time and resources. One way to improve efficiency and reduce costs is to ensure that a team, by working together, can quickly identify and fix errors, saving time and money in the long run. 

3. Good communication between the QA team and developers is everything.

In any line of work, good communication is essential to collaboration, and this is especially true in the field of QA Testing, where clear and concise communication can mean the difference between a successful project and a costly mistake. 

This means setting expectations, outlining the scope of the project, and establishing a clear process for reporting bugs and feedback. Without good communication, it can be difficult to get everyone on the same page, leading to frustration and delays. By taking the time to establish good communication early on, you can save yourself a lot of headaches down the road. 

Also, this is where the advantages of a different approach in collaboration can shine, like the option of working with a Nearshore organization to find the QA talent your project needs. There are many benefits to this, like the increased diversity you get when expanding your scope (important to get as many fresh perspectives as you can when solving a particularly thorny bug), as well as efficiency and communication. With Nearshore proximity, it gets easier to build strong working relationships with other team members, whose cultural closeness makes work smoother in general, while also being flexible and scalable, making it a good option for businesses of all sizes. This way, teams can work more closely together to identify and resolve issues more quickly. 

The result is that, with a Nearshore QA department, collaborative testing can also help to improve communication and build trust between team members; when everyone is on the same page, it leads to better quality software and a better user experience.

QA: More than meets the eye

The case of Cyberpunk 2077 we mentioned at the beginning is a great example of a QA process done wrong, and thankfully, any future product development can learn from it and understand how to approach an area of IT that sometimes doesn’t seem as valued as it should. The main thing is that proper QA is critical for success, and having a good approach towards it is the first step to guaranteeing a useful product that meets the expectations, and preferences, of a user base.

The Key Takeaways

• QA is a critical part of software development, and any successful product has a strong quality process in place.
• However, it’s very easy to choose the wrong approach to QA, compromising the functionality and success of any application, no matter how good it is.
• Collaboration, communication, and a proper system that encourages looking for big issues during development are crucial, keeping everyone on the same page and with the same goals.
• And when it comes to remote collaboration, a Nearshore partner is the best choice to bring the best QA talent to your team, as the close cultural fit and ability to communicate are invaluable to ensure a quality application.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies to help you reach new heights. We have been developing since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – we’ll be happy to help you achieve your business goals.