Why is a quality assurance tester needed in a software development team?

Integrating QA into the development process

Agile has become the most common development process in every single organization, and it has been used to deliver values to their customers on a short cycle basis. Agile requires fast feedback in testing, and automation is the best practice to receive the results quickly. One of the most common best practices of Agile testing is to build the Test Pyramid, which focuses on building automation tests from the code level (unit tests), service level (API or integration tests), and a few tests from the UI levels (E2E). Exploratory testing is on top of the pyramid and is often used to find the issues from edge cases that different levels of automated tests have not covered.

Most tests are automated from the illustration above, and manual testing is minimal. The role of testers seems to be limited because most of the tests will be written by developers and executed by machines. Therefore, some companies adopt the best practices stated above and cut out the dedicated testers in their development team.

Based on what we have discussed so far, the QA/tester role seems unnecessary. So can developers take over the QA/tester role? Before we answer this question in the next section, let's analyze the different approaches in developer-based testing compared to QA-based testing.

Difference between developer testing vs. QA testing

Developer-based testing

Tests are written mainly from the code level, including:

• Unit tests: Tests are designed to test every method/class in the code. Tests are executed very fast and are easy to debug if failed.
• Component tests: Verify that each component is rendered correctly.
• Integration tests: Tests are designed to test the integration between modules or external services (APIs, database).
• E2E: In some companies, developers are also required to write E2E tests at the UI level.

Developers profoundly understand how each function, API, or component works. Also, with excellent technical skills, they can automate all the tests and get feedback quickly after executing tests. Nevertheless, they do not fully understand the entire system. Especially in a complex product, each developer will focus only on specific areas or some features.

Not all developers would write sufficient and suitable tests to ensure that their code will not break in the future. Because of the pressure of the competitors, many companies want to ship their product very quickly to the market without thinking about the future when the code base becomes complicated. Therefore, these companies usually ignore or have minimal testing coverage at the code level because writing these tests will take time and need to be maintained later. They mistakenly believe that it will slow down the development process and decrease product shipping speed in the short term.

On the other hand, some tech giants like Google or Facebook don't have QA roles. Their software engineers also test their implementation. They have thousands of top talents, so they have a ton of time and resources to produce the highest quality features. They also have a well-established process to ensure that all the code committed will be reviewed and tested thoroughly.

QA-based testing

Tests are mainly designed and performed from users’ perspectives:

• Test cases and test plans generated by QAs are usually used as sources for training and customer support. These are also good references for the development team to understand the application's functionality.
• QAs perform testing to optimize software quality by reporting bugs to developers confidently. They also take full responsibility for bugs' lifetime until bugs never occur again.
• Testers have strong product knowledge of how the whole system works and know the dependencies between functions. This unique view helps them think of the usage of the application in different directions and create multiple test scenarios.
• QAs usually do not compromise with any defects and don't accept that issues are fixed unless they retest and have proof. They are willing to try and not afraid to fail. With unreproducible bugs, replicating them can be unsuccessful the first time, but that means QAs will tackle it again with additional creativity.
• Testing can be tedious, but the repetitive nature is not boring for testers as long as they know how to think creatively and use their imagination to put themselves in the shoes of a user.

What if the world had no QA?

The trend of integrating QA with the development process rather than keeping them as a separate team to find and fix defects later is somehow triggering the question: Is QA dying? Do QAs become redundant? Will developers take over QA tasks?

To answer this question, let's dive into a scenario when an organization does not have a dedicated team of QA testers. Imagine that everyone involved in software delivery will need to put in extra effort to fill in the gaps. Besides producing new code and writing tests at code level, developers and IT experts will need to spend time for QA-based testing. It is possible. However, the story does not end like this if we think about the big picture when the product will grow at scale.

To ensure customers receive quality products, organizations need to build a solid QA operation. With that in mind, these activities should be performed regularly:

• Requirement Analysis: To clarify requirements by asking questions that ensure requirements are testable, identifying dependencies that have not been mentioned in the requirements.
• Test Planning: To create a testing strategy/plan to ensure features are tested and released on time with quality.
• Test Design: To create test cases to cover all possible scenarios, prepare test data and test environments.
• Test Execution: To execute tests on different phases, find and report defects, retest until bugs are fixed completely, follow up bug life cycle, and document test results. They also need to perform regression testing, the most time-consuming QA activity, to ensure that existing features are not broken. Additionally, they need to write E2E automated test scripts to save time on regression execution and debug failed tests.
• Test Report: Create a report to show the quality status and confirm the quality of the product.
• Test closure & maintenance: Clean up and maintenance the tests if any.

Yes, these responsibilities usually fall under QA. Not having people specialized in QA testing will mean all these tasks will be left behind.

When it comes to products that humans will use, no organization can release a product without manual testing.

When it comes to products that humans will use, no organization can release a product without manual testing. For instance, a computer is made and tested using an excellent automation process. Still, when it is in users' hands, many scenarios will introduce issues that automation can not find. Having no QA means lacking the human input to use the product as a user. QA people are the ones who possess a distinct skillset and are the first users who fortunately have an opportunity to use the product when it is released internally. While testing the new features from the user's perspective, besides detecting more bugs, they will raise concerns to improve the UX before launching the product to end-users.

Having no QA means lacking the human input to use the product as a user.

Why it's important to keep QA alive

Having QA people in the development team will be a challenge when more organizations adopt the current trend of shifting quality responsibility to developers. Having said that, that trend does not eliminate the QA role in the Agile team. Indeed, QAs always have their value to shine. To keep the QA role from becoming redundant, here are some key points we should keep in mind.

• QAs will work best within the development teams to productively coordinate and give feedback based on their insight about the application. To ensure the product is put into users' hands with high quality, QAs should iterate themselves that they are the user's representative to experience the product firstly with an uncompromising testing mindset.
• Lacking the human factor is usually causing pure code-based testing that generally fails. QA testers provide a human-eye input to discover bugs in an interesting way that is often a surprise. Keeping your brain always fresh is hard when testing the application day in and day out. But don't let yourself become biased when it comes to any strange behaviors or any issue you think is minimal. Remember that a minor issue can cause a significant business problem.
• Developers also can test their code to find defects. Still, QAs can discover issues via various user flows and examine the product under the combination of functionalities that can be missed by developer-based code testing. Constantly update your product knowledge and become a "master user" to experience the product with joy and focus.
• Many companies adopt Shift Left testing in which QAs can contribute more to the development process. QAs can utilize their product knowledge to get involved in the design phase, give inputs to shape the feature, and create test cases when the design is finalized for coding. There are many opportunities for QAs to provide contributions, so the QA role will no longer stay in the right but move to the left.

QAs can discover issues via various user flows and examine the product under the combination of functionalities that can be missed by developer-based code testing.

Conclusion

Moving away from having QAs is popular now, and it makes QAs worried about their future when testers are no longer needed. But the value of having QA people in the development team will never disappear. To build a robust development process, we need to understand both the advantages and disadvantages of developer-based and QA-based testing. We also need to balance these approaches by having developers do testing at the code level and have QAs tackle bugs under the user's journey.