QA Team – Is a Separate QA Team Redundant in Development Life Cycle?

engineeringhackingqasoftwaretesting

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

Best Answer

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.

Related Topic