3

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?

6
  • 1
    The very nature of the "but would like to hear some opinions" means that the question is opinion based. These are questions that are subjective and are not a good fit for the Stack Exchange format. (Please read the help: on topic and help: avoid asking to get a better idea of what types of questions work best on Programmers.StackExchange.)
    – user40980
    Commented Oct 14, 2013 at 2:59
  • 1
    I can't say it's a good question, but I think "opinion based" thing was very easy fix. Have you done any reading or research about agile? Lots of good stuff out there that would definitely give you answer to this question and more. In short, yes. Agile is specifically intended to have QA involved much earlier and QA is part of the deliver team that interprets business requirements. They don't simply twirl their thumbs until developers deliver working code based on their own interpretation.
    – DXM
    Commented Oct 14, 2013 at 3:09
  • 5
    is agile actually geared towards reducing this 'waste' Your bias is showing :) You presuppose that QA and testing is a wasteful activity as a given in your question.
    – maple_shaft ♦
    Commented Oct 14, 2013 at 11:03
  • 1
    @akila, I understand that you are frustrated by testers reporting defects which are incorrect, but are they all incorrect? Even if only 10% are valid defects, those are mistakes you made and failed to identify yourself. I agree with what others have said, that you need to think more about your contributions to the problem.
    – Brandon
    Commented Oct 15, 2013 at 0:07
  • @everyone - thanks for your thoughts - and developers do introduce bugs - guess the very nature of changing something will cause this to happen - the only area was trying to look at was how to get testers involved early - we have this huge division between development and testing teams
    – akila
    Commented Oct 17, 2013 at 2:01

2 Answers 2

Reset to default
4

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.

7
  • 1
    Like I just wrote to DocBrown. It is a huge misconception that QA isn't involved in developing a product until after it is done in waterfall. They are supposed to be involved from the beginning, reviewing every work product to ensure it meets standards and make sure the product being designed is testable.
    – Dunk
    Commented Oct 14, 2013 at 15:52
  • QA is defect prevention. Testing is Defect Detection <Fullstop>. Many developers think QA is Testing and presume to the talk about QA when all they know about is Testing. The Agile evangelists conveniently use this naivety to claim that Agile brings QA in earlier. Successful Waterfall houses have QA and Test as separate teams and understand the difference in the tasks performed, and have done for decades. (Note: I am not discussing pros and cons of Waterfall vs Agile, that a different topic.)
    – mattnz
    Commented Oct 14, 2013 at 22:38
  • @mattnz: I tried to rephrase the last sentence to hopefully make my point a bit more clear. The OP seemed to use "QA" interchangeably with "testing" so I was trying to use similar language.
    – Bryan Oakley
    Commented Oct 14, 2013 at 23:22
  • 1
    I think you missed the point. In Waterfall QA is involved early. If QA are not involved early, its not QA, is something else - probably Testing who have dressed up, put on some lipstick and got a hair do and called themselves QA....
    – mattnz
    Commented Oct 15, 2013 at 0:39
  • 1
    @mattnz: perhaps I missed the point, our you're missing mine. My point is, if you don't involve QA until the end of the waterfall process (which lots of companies do, in my experience), then you aren't doing QA, you're doing defect detection. Many companies mistakenly call it QA.
    – Bryan Oakley
    Commented Oct 15, 2013 at 1:05
6

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.

8
  • 2
    I disagree, Agile vs. Waterfall does matter. "Waterfall" is a model implying no communication with testers before a certain project stage.
    – Doc Brown
    Commented Oct 14, 2013 at 6:47
  • 4
    @DocBrown: Although in waterfall there is no direct communication between the developers and the testers, there should be interaction between the testers and the requirements engineers. Where else are the testers getting their input for the testcases than from the requirements. If either the testers or the developers find a problem with a requirement, it must be communicated to the other team. If not, the organization has a communication problem, regardless of their development methods.
    – Bart van Ingen Schenau
    Commented Oct 14, 2013 at 7:26
  • 3
    Following on from Bart's comment - if you have really good communication between your different teams, particularly between the requirements, development and testing teams, your project is far more likely to be a success regardless of methodology. It's almost as though a larger group of smart people collaborating is more effective than smaller groups of smart people operating in conflict with each other.
    – glenatron
    Commented Oct 14, 2013 at 10:51
  • 1
    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) You must be fortunate to never have worked with a terrible software development team. Most of the time troublesome testers that cause a lot of grief for developers are the result of poor requirements gathering and analysis by the analysts. Often the developers are powerless to change this situation and have to imply many requirements at the demands for progress by anxiety ridden PM's.
    – maple_shaft ♦
    Commented Oct 14, 2013 at 11:08
  • 1
    @DocBrown:I don't know where you have worked waterfall but everywhere I have worked waterfall, QA is involved from the get-go. They review EVERY work product not just completed code. They are involved in every meeting involving requirements.
    – Dunk
    Commented Oct 14, 2013 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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