Is separate QA team, redundant in development life cycle?

Question

Background:

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) but 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/validate test cases. So, all new test cases are append to existing test suite, as part of process.

My employer, manufacture 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.

---

Question:

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

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

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

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.