Is QA or testing a lot of overhead or not utilized properly?

Question

From my experiences in software development (Eg. Waterfall ) I see it that most of the times it is the development team that sweats it out with the BA folk to get requirement clarity. The development folks then slog it out to meet deliverable deadlines.

Where is the QA - they might be free - but will only hitch onto the bandwagon after the code is delivered.

Then starts a slew of communication regarding what is a defect and what is a requirement change / clarity needed. From QA perspective - log a defect / bug / issue - and then its the development team responsibility to go figure it out.

Clearly this is problematic and affects my opinion of the role and value that QA brings to the table in the Waterfall model.

The question is if Agile is actually geared towards reducing this 'waste' by getting testing involved early in the development so that issues get eliminated at the start? If so then what aspects of Agile help solve some of the above problems I have experienced?

Answer 1

Yes, agile is in part "geared towards reducing this 'waste' - getting testing involved early in the development so that issues get eliminated at the start?"

The role of QA should be one where they are equal collaborators with developers and the business side of software development. They are the advocate for the customer, the one who looks at the software from the user's perspective to make sure it matches their definition of quality.

When you tack on QA activities to the end of a development cycle, it's too late for them to have a significant impact on the product. At the end of the cycle, the best they can do is identify existing bugs. When you move them earlier in the cycle, they can be instrumental in preventing bugs. That is the true value that QA can bring to the table, because a bug found in design or early in development is considerably cheaper to fix than one found at the end of the development cycle.

The difference between QA's role when they are included only at the end of a waterfall cycle vs agile or any other methodology that involves QA early in the cycle is one of defect detection versus detect prevention.

Answer 2

Testing is to QA what and Ambulance is to Healthcare. The idea is to focus on what can be done within the latter so the former is not needed. QA should be as busy at the start of the process as anyone, if not busier. The sooner they get involved in establishing how and how much quality will be achieved, the less testing will be needed, and the few issues will come from testing.

Agile is not a silver bullet to slay those problematic, pesky little testers with. Learn to show some respect, or anything you do is doomed to fail. Arguably the only reason testing is bothering you is that you did not do your job. By not doing you job, you have made a lot more work for them. If you think you have grounds to complain about testers finding defects, think long and hard what part you played in that little problem, and how much work you have created for them. (Rant Over)

So how to fix it - Agile, Waterfall whatever does not matter - just talk to each other. If you are unclear on requirements, make sure you ask the BA and the testers. Ask the testers how they expect to test each feature. Ask the testers for access to their test plans, and ensure your software passes the plans. Don't throw you product over a fence, hand it over in a well wrapped package. If anyone is unclear on any of this, go back to the BA till you know what is needed and how each team will achieve the outcome.