Developer is the best person to know/understand the dark corners after any development/enhancement of enterprise software, compared to QA technician.

Developer can assess the depth/breadth of production problems that can arise from such dark corners.

For quality reasons only and not for cost cutting, my new employer does not maintain separate QA team and shifts the responsibility to developer (as better owner) to write, append, automate and validate test cases. So, all new test cases are appended to existing test suite, as part of process.

My employer manufactures network switches with their customised Linux based OS on switch.

At my workplace, the first rule that is followed in regression testing is to avoid regression testing. We avoid regression testing by testing any new testcase written for every feature, on every platform, for every release. If the test fails, then matches the log with database of known failures and points out some fingerprints.


  1. Does a separate QA team add any value in a software development life cycle?

  2. Does it add value for a Quality product delivery, if a QA team is formed that has ethical hacking skills? For software products that run on network

  • 1
    Developers are allowed to give advice on which areas may benefit from more testing or how best to test some functionality to QA in most cases. There's no reason the developer needs to hoard the knowledge of where the "dark corners" are. Commented Mar 17, 2017 at 23:18
  • 1
    @JohnForkosh I think you have a confusion of correlation and causation there (though there's certainly some causation). I've definitely worked with good QA engineers who've had no developer experience. A QA engineer who was formerly a developer is likely not at all cheap. My impression, though, is that many companies view QA as largely a "monkey" job and hire accordingly. Commented Mar 18, 2017 at 0:37
  • 1
    Don't underestimate the value of someone pressing buttons in ways the developer never thought of before the product is shipped to the field. Even if that's all QA did, which they do a lot more, then they are worth it. As a developer, you'll probably make sure the code works as you expect but won't spend a lot of time figuring out how to improperly use the system. You may technically be right that it was operator error that caused the database to become corrupt. But in your customer's eyes it was your software that is broken if it let the operator do the wrong thing.
    – Dunk
    Commented Mar 21, 2017 at 21:10
  • 1
    Possible duplicate of Should a developer also act as a tester?
    – gnat
    Commented Jul 21, 2017 at 9:19
  • 1
    see also: Should QA be part of the development department?
    – gnat
    Commented Jul 21, 2017 at 9:20

6 Answers 6


I would say that it depends on the system being developed and tested.

The developer might have the best understanding of the code, but that doesn't mean they fully understand all the business cases that the code is used for.

For example, consider a web application used by insurance brokers to manage and process policies and claims. There are many many rules and business cases that go into such a system. It's highly unlikely that any one developer will be able to know all of it in great depth. Heck, most business users probably won't know the whole system (although they will have a better business-level understanding of more of it than developers).

In this case, a separate QA team will have received special training on the business flows within the application. Chances are, they might not even be developers, they might be Business Analysts who have transitioned into QA due to their extensive experience. Or they might be developers who are more interested in the non-code-related facets of the system. They won't understand all of the technical details, and they won't need to. They will execute business cases that probably go beyond what the developers know or even need to know. Developer testing (usually done by developers locally on their own workstation, to ensure that their code works at more than just a basic level) and QA testing (done by QA teams to ensure larger sets of business cases are satisfied) are two distinct phases with different kinds of tests and expectations.

What value does this add? You have seasoned, experienced QA testers who have a very good high-level understanding of the system as a whole. They know how to test the system to ensure that all parts are properly covered, based on the changes made by the developer. And it frees up developer time from something that really is a full-time job and requires extensive business training. All of this can lead to fewer bugs making it to production and higher over-all quality, and happier customers (and that's the whole point, isn't it?).

In my experience, the larger/more complex the project is, the greater the value added by having a full QA team. On smaller systems with a single (or small handful of) developer and simpler use cases, the value added is not so great, and in some cases, having a separate QA team could be redundant (and costly) if the testing is simple enough for the developers to manage on their own.

  • Developer don't need to know/remember complete test cases from scratch because it is already part of Test bed(like HP QC). What developer remember for that cycle is his own new test cases gets validated and does not fail already existing test cases. Commented Mar 17, 2017 at 18:17
  • 2
    @overexchange: For unit tests, I agree with you. QA teams usually test at a level beyond unit/integration tests. If your QA team could be easily replaced with good unit & integration tests, then perhaps you don't need a QA team. Commented Mar 17, 2017 at 18:25
  • Level beyond unit/integration tests? Can u help me understand more on this? Commented Mar 17, 2017 at 18:43
  • @overexchange: Unit/integration tests are automated. QA testing involves a real human being working with the application to ensure that it does what it is supposed to do. The tester works with the UI, so they test and give feedback on it. For complex interfaces (again, consider the insurance application example), this usually proves quite valuable. Many business flows could involve 10-20 "screens"/pages - it's easy for a single developer to miss things in this situation, so having another person walk through it can catch bugs and problems. Commented Mar 17, 2017 at 19:05
  • 6
    @FrustratedWithFormsDesigner To emphasize your point, I would add no amount of testing by the developer, automated or otherwise, will help if the developer has misunderstood the requirements. Even worse, if that developer then enshrines that misunderstanding into a test case. Commented Mar 17, 2017 at 23:29

FrustratedWithFormsDesigner brings up one case where separate QA is useful - a complex system.

There is another case where separate QA may not only be useful, but mandatory - regulated environments. There is a notion of independent verification and validation. Independent means that it's done by a person or group of people who did not write the production code. In some environments (I have experience in aerospace and healthcare) and under some conditions, it is mandated that there is some level of independent verification and/or validation. In all of my experiences, the development team is responsible for some level of testing to ensure that garbage isn't turned over to the independent QA testers. In addition, the independent testing may be manual testing, automated testing, or a combination of both.

There's also the question as to what "separate QA" really means. Does it mean embedding QA staff onto each development team or does it mean having a handoff from a development team to a QA team. Independence can be achieved in both models.

  • 1
    Ah, good point about regulated industries! +1 Commented Mar 17, 2017 at 19:10
  • 1
    @overexchange My answer addresses both cases. In some industries and environments, you need a separate person to do QA other than the person doing development. This person can be on a separate team or embedded onto the development team (as long as they don't do development) - both are equally valid.
    – Thomas Owens
    Commented Mar 17, 2017 at 19:18
  • 1
    @overexchange: and if the development of malloc was a regulated industry, you probably would need independent verification (by a QA team that is either within your organization but distinct from the dev team or more likely is external to your organization entirely) of some kind that you coded it correctly, and then once you have this verification, you would able to say "Our malloc passed regulatory verification and can be used for $x, $y, and $z, with use for $a' pending." Commented Mar 17, 2017 at 19:29
  • 3
    @overexchange: Also, you seem to think that all testers don't understand programming concepts. Some of the best testers I've worked with had previously been developers who decided to work more on Business matters and testing (for whatever reason). They understood memory issues and they knew how to read a stack trace when one appeared on the screen. Commented Mar 17, 2017 at 19:34
  • 3
    @overexchange You also seem to be thinking that developers do no testing if there is separate QA. That's false. Developers have a responsibility to turn over working code (as far as they understand working) to QA just as much as they do when they deploy code to production without a separate QA.
    – Thomas Owens
    Commented Mar 17, 2017 at 19:41

I definitely like the points discussed by @FrustratedWithFormsDesigner, but I think it is useful to consider the larger universe of testing types when it comes to a complete software system. I am sure there will be differences of opinion on who should do what -- and I welcome discussion :-) -- but the figure below is a quick sketch representing my experience and opinions.

As you will observer, there is a lot of overlap as to who should test what. Developers should be responsible for delivering to QA a complete and correct product (or feature) by means not just of unit testing, but some measure of the other categories of testing noted. Those that I have marked as "secondary" should be considered by developers, but not as their primary responsibility. That's why you need dedicated QA people, people with expertise in those areas.

The business stakeholders add another level of validation, and though their participation in testing will vary widely from company to company, it is, after all, they who deliver an acceptable or unacceptable product to the customer.

A couple key takeaways from my chart:

  • Unit testing is the sole domain of developers. QA folks with expertise in coding might want to peek at some of the internals but to help them with developing functional and other tests, not for unit testing.

  • QA is responsible for the whole system synergy, already discussed by @FrustratedWithFormsDesigner.

  • Security is everybody's business!

Testing Types by role


Of course you have thoroughly tested yourself before handing over to QA. But the very fact that the developer is the most familiar with the application is the best reason to have someone ELSE test it.

The developer knows what the software is supposed to do, the way in which it is supposed to be used, etc., and it will be exceptional if he or she attempts to use it in the way a naïve user might, thus breaking it in unexpected ways. It will never be a black box to the one with the x-ray vision. Too often the developer is the the one the most removed from the real world use of all persons involved in the project.


QA/Test has two jobs. Verification and Validation.

Verification checks that the code implements a feature correctly ("does the thing right").

Validation asks if we did the right thing. That is typically with respect to a written definition of "the right thing" as in requirements in many regulated domains and policies and regulations in domains like financial institutions.

I have worked in human space flight where we had very clear requirements for an independent QA team to verify and validate against.

I have worked in other industries where the developer is given vague instructions about what to build. In those cases, often QA ends up asking the developer what "the right thing is" and sometimes as a developer, I end up writing test instructions and even the tools and tests themselves. When that is the case, QA does not add much value (sometimes they catch regressions on platforms that the developer did not test on, or "works on my machine type issues" -- I do desktop apps, drivers, etc. where code runs on a myriad of shapes and flavors of end-user-machines.

IMO, to get a good return on an investment in QA, you also need to document, in some way, the requirements that the code must fulfill so your QA team can independently perform verification and validation. Without that, QA is mostly theater.

If the cost of a bad change getting to production is not too high (i.e, a rollback/recovery is easy and effective), and developers can test for themselves in a very production-like environment, then most of the QA team might not be a very good ROI.

I should note though that good exploratory testers almost always a great investment!

As for question 2. I've never worked with a QA team that had trained ethical hackers. I would consider that a separate specialized (and more costly) skill.


No, the developer is most definitely not the best person to find problems.

If there are possible problems due to deep dark corners in the product, then the developer’s job is not to find problems in these corners, but to write code that is correct in the first place. (Unless you misinterpret “test driven design” as “it’s fine to have bug-ridden code as long as there are no unit tests). And if necessary document things that could lead to errors.

The biggest problem is psychology. If a developer finds a bug, it means they didn’t do their job correctly. If QA finds a job, it’s the exact opposite, it means they are doing their job well. Result: Developers don’t want to find bugs and won’t find them, where QA wants to find bugs and therefore finds them. And for developers finding bugs means extra work fixing them, making them less productive. Take two equally good developers; the one who avoids finding bugs will look more productive and get a bonus at the end of the year.

QA will also often have the expertise to set up different environments more or less close to a production environment. And importantly the time to do it because it’s part of their job. (For developers: Good code will work in any environment. QA’s job is to ensure this).

Not the answer you're looking for? Browse other questions tagged or ask your own question.