QA Testing vs Dev Testing | BrowserStack (2024)

With all the conversations around shift-left testing, DevOps and other approaches that shift some of the testing obligations to developers, a legitimate question keeps coming up these days: do we need QA teams anymore?

It’s better to see the question another way: Should testing be done by a dedicated QA (Quality Assurance) team, or should testing become more intrinsic to the development process?

Let’s answer that question in this article by comparing Dev Testing with QA Testing. But first, the obvious questions.

What is QA Testing?

Generally, QA Testing is what we think of when we hear the term “software testing”. It is Quality Assurance – assuring that the quality of a soft application is high and filtering out all instances of low quality and/or disrupted functioning (bugs).

• Most software testing approaches, especially in real-world implementation, involve the dedicated work of a separate team of highly trained testers.
• They constantly run the code through manual and automated tests to find bugs and report them to developers.
• Think of the most annoying bug you’ve encountered when using a site or an app. QA Testing is the reason they don’t show up more often.

QA testing teams work closely with developers to deliver feedback on code quality and its alignment(or lack thereof) with customer expectations. They are also responsible for evolving test suites to keep up with application changes and technology and even help with documentation for customer support and training.

What is Dev Testing?

In Dev Testing, developers take on a larger share of the testing. At the very least, they should perform unit testing on their code before pushing them to the code repo. The idea is to phase out of complete dependence on overworked QA testers by running preliminary tests in the early stages.

• Early testing is a significant element of systems like DevOps and approaches like Shift Left.
• When devs run all of their code through several tests as soon as they script; they ensure that bugs are detected and neutralized before the code even hits advanced build stages.
• This is especially important to minimize release issues, defects, and downtime.

Of course, devs cannot and are not expected to do all the testing. They scan and verify the code they create themselves, the one they are familiar with.

Why Devs Start Running Tests: The Changing Role of QA

Older, pre-2001 software testing usually did not involve much engineering expertise. Testers manually put the software through common user journeys, and for the most part, the focus was on getting the software’s core functions working.

You’ll see in the Waterfall SDLC, where all testing is saved until the end of development. In it, activities are confined to their respective stage – all coding is done simultaneously, and so is all testing. It’s like a waterfall in which workflows are from one layer to another.

In 2001, the Agile Manifesto was released, and the role of a tester in DevOps was reoriented into an integrated function – testing now occurs from the earliest possible stage of development, and consistently throughout the SDLC.

This is why you terms like “quality assurance DevOps”, “QA DevOps engineer”, “QA to DevOps,” and “QA vs DevOps” pop up on Google search. Not only do testers create and run test suites across the CI/CD funnel; but developers also do their share of testing. QA teams are also required to have more technical expertise, as automated testing is almost mandatory for any comprehensive software development workflow.

Moreover, QA teams also have a greater hand in designing tests, so they are included in brainstorming conversations from the beginning. They gain a closer understanding of the target product, and approach testing from a more informed POV. Naturally, they is expected to have more than passable knowledge about the entire development landscape.

Of course, if QAs now need more understanding of development, can developers test code? Is Dev Testing enough?

Let’s explore the advantages of Dev Testing and QA Testing.

Pros of Dev Testing

• Developers have a deeper and more contextual understanding of their code, since they wrote it. They’re the best people to decide what tests can effectively scan through said code and reveal bugs within the shortest possible duration.
• It’s easier to put code through unit tests by building the testing modules directly into said code while it’s being written. By the time the code enters the DevOps pipeline, it is already verified by a set of tests (but requires more verification, of course). Once it moves through the entire funnel, it will have been tested against most user scenarios.
• Since tests are distributed at different junctures across the funnel, they check the app at multiple stages. For example, the code is verified by unit tests before commits, by integration tests after it is built, and so on. This is more paced and effective than saving all tests for the end. By that point, minor bugs could become inextricably entangled with the codebase and become infinitely more difficult to fix.
• By taking on some testing activities, developers save themselves the excessive work requires to fix post-development or post-production bugs. It is ALWAYS more difficult, and time-consuming, and expensive to fix bugs that show up in the latter stages of the SDLC.

Pros of QA Testing

• Developers cannot be expected to slow down and look for every bug while ALSO writing the code for an application. They do not have the time and capacity. It cannot be on them to write application code AND design numerous tests (manual and automated) to verify said code. They need the help of a dedicated, trained QA team.
• Testers must become familiar entire application system by getting a broader knowledge of the application’s regression history than devs. While they may seem bothersome to devs, they keep them and the code honest. The role of a tester in DevOps is to have a bird’s eye view, unlike developers who are usually confined to testing their own code; they get a narrower view of the entire codebase. Naturally, QAs can ferret out bugs during the integration of different modules, something developers cannot.
• The developer’s mentality (as it should be) is to make their code work. QAs are trained to look for reasons why the code will not work. These mindsets are opposed to each other, and most humans cannot shift back and forth between mentalities and goals in a single project. QAs are willing to push software to find out what doesn’t work, and devs work to make software stable and unbreakable. Naturally, QAs are the ones most suited to testing activities.
• Once again, QAs are trained to think from the perspective of end-users, which is an essential element (in fact, it is the starting point) of all testing.
• Testers will also be willing and likely to perform niche or non-obvious user activities to check how an application responds to uncommon situations. They’re also usually more willing to believe that not finding bugs doesn’t mean there aren’t any – the absence of evidence is not evidence of absence.
  
  If QA testing doesn’t find bugs within the first test suite, it puts the software through another and continues until the bugs do show. This persistence is one of the most significant advantages of QA testing.

QA Testing vs. Dev Testing

Why the Real Solution is a Balanced Approach

There can be no clear winner between QA Testing and Dev Testing because no DevOps model can succeed with just one form of software verification.

What’s required is a blender cohesion of both – transition from separate QA and Dev teams to collaborative testing by both. This approach is often labeled the Quality Engineering(QE) model.

The solution is to integrate testing into development, remove hard distinctions between devs & testers, and make heavy but targeted used to automation tools. In the real world, the approach involves devs running most of their tests, backed up by a QA team providing frameworks, guidance, and final checks.

• QA teams build specialized automated test cases to verify developer-driven code.
• If time and resources allow, devs could write these tests with input and review from QA folks.
• Devs have to write unit tests at least, which speed up the deployment of specific modules.
• It’s on the QA testers to create a series of integration and regression tests to ensure that code from different devs works well together and that new code does not break already functional elements.
• In QE, QA engineers should ultimately aim to gain the expertise of developers and vice versa.
• By understanding more of each others’ role, both parties are able to work on improving the quality of the entire SDLC and deliver better software in lesser time.
• In other words, if you’re shifting left, shift more to the left. By integrating QA throughout the SDLC, you get more tests, fewer bugs, and faster releases.

The Role of Real Devices in Testing

You can build the most sophisticated testing scripts, execute them to fruition and watch over them like a hawk….but none of the results will be reliable if you’re confining tests to emulators/simulators. At some point, ideally as soon as you have a MVP, tests should be switched to real user conditions i.e. real browsers and devices.

In case you’re not willing to spend thousands of dollars acquiring the thousands of devices (installed with different OS versions and browsers) required for comprehensive testing, try the BrowserStack real device cloud.

Along with 3000+ real browsers and devices, here are a few other features you get with access to BrowserStack’s real device cloud:

• A diverse set of debugging tools, including Screenshots, Video Recording, Video-Log Sync, Text Logs, Network Logs, Appium Logs, Device Logs, and App Profiling.
  
• In-built support for responsive testing, network throttling, geolocation testing, and natural gestures, all on real devices.
• Support for accessibility testing to ensure app access for differently abled users.
• Robust foundations for parallel testing that can speed up tests by 10X and empower faster time-to-market without any compromise on app quality.

Try BrowserStack