Over a million developers have joined DZone.

Why You Need to Stop Relying on Developers to Perform Testing

DZone's Guide to

Why You Need to Stop Relying on Developers to Perform Testing

Some companies think you can save the cost of a software tester by leaving it to the developers. See why this is devastating to the development lifecycle.

· DevOps Zone ·
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

As companies decipher why testing matters based on the cost of a bug or a customer pointing out their mistakes, teams that produce and deploy software applications ultimately come to terms with the fact the testing should never be skipped.

However, some people think they can get the job done without paying the price - the price of a software tester, that is. While testing might seem simple at first glance, there are countless factors that go into effectively evaluating an application.

Organizations that rely on developers to do the job will quickly run into roadblocks that prevent on-time delivery and impact customer satisfaction. Here are a few reasons why your software team needs testers:

Testing Is a Specialized Skill Set

Developing and testing are two different jobs with two different skill sets. Just like a doctor shouldn't try to do a nurses job and vice versa, building an application and having an understanding of the techniques to properly test and provide feedback for that application are two different things. While it a developer could maybe perform a high-level test of the application, a tester is truly needed to take a deeper dive and handle more complicated procedures that go beyond a basic click-through.

Testing Takes Time

Testing is not a quick one-and-done. In fact, most testers find that they don't have enough hours in the week to get to everything they wanted to test. A big reason behind this is that it's virtually impossible to test everything - there are limitless possibilities and there will always be some part of the application that's going to go under the radar, no matter how much time and effort is spent on it. This means that if your developers are doing the testing, they will either be skipping a lot of tests that they need to run due to time split between their responsibilities, or they'll be doing an acceptable amount of testing that will keep them from doing their main job. Let your developers develop and your testers test so you can stay on track for frequent integrations, fast delivery, and quality software.

Knowing How to Code ≠ Knowing How to Automate

Learning a programming language is the first step to getting started with automated testing, so it might seem natural to have developers learn to automate and perform checks because they already know how to code. However, you'll find instead that the execution doesn't go as smoothly as expected. There's a lot to learn when it comes to automation, and coding is just a very small part of that. You need to know when to automate, how to write comprehensive scripts, how to approach challenges with automation tools, how to manage test cases, and much more. This comes back to the idea that testing takes time and a special skill set - it's more likely you'll find your developers are frustrated and falling behind than making any strides in automation.

Reporting and Documentation Are Important

A test that's run but isn't reported or documented is only so helpful in the long run. Even if your developer is willing to run through their own part of the application, it doesn't mean they're making scripts that are maintainable and reusable. And it definitely doesn't mean they're going through different parts of the application from other developers to conjure effective integration and end-to-end testing strategy. If all your developers are testing their own code, all you're going to end up with is fragmented information that probably won't do much good catching bugs anyway.

You Need to Be in the Right Mindset

If you're testing your own code, you're not really accounting for new scenarios. That's to say that if someone writes a feature, they're only going to test for the use cases they already considered in development. Having a tester come in brings a fresh set of eyes to look at the feature in new ways that the developer may not have thought of. It's like having someone edit a paper for you - oftentimes they'll find mistakes or make suggestions that you missed no matter how many times you read it yourself. A tester brings this same value to the table by not only finding errors that were missed but also providing insight.

Having your developers test their own code is a poor use of time, money, and skills. While you may be tempted to resort to using your developers to quickly test a new integration before release, it's important to understand that there's a good chance you won't get the results you want.

Hiring for testings and bringing in a team that is specifically trained to inspect software quality and focused on finding and reporting bugs will not only improve time to market but also increase the capacity of your developers and improve the software you release. Don't skimp on testers the same way you know not to skip testing.

This article was first published on the CrossBrowserTesting blog.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

devops ,test automation ,qa ,software testing

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}