Search
  • Mark Duffy

What is wrong with the Waterfall Method of Software Development

The waterfall method, its simple to understand and easy to follow, but it is flawed. In nearly every aspect!

Just like a waterfall, it starts from the top, the customer!


The customer (internal, external, stakeholder, who ever) wants something. So they meet with the product owner

The Product Owner writes up the specification, normally a user story... And by a user story, I mean a word document that starts with .. As A User....

Now the product over has his specification, they invite the developers.

The Development team get to work, before long they have the feature to be tested. They very kindly write out test notes and pass to QA


QA follow the test notes, and all the acceptance criteria pass! It is a good day!

The software is released, it goes to the customer!

JOB DONE!


Perfect!

Except... It is not!



It passed QA, the acceptance criteria were there in black and white, it passed that. Unfortunately the acceptance criteria was written by the developer who wrote the feature. It is like asking a student to fill in a multiple choice and then giving the teacher the answer key!


I would be REALLY bad if QA had failed the acceptance criteria - the student gave the teacher the answer key, and wrote the answer key down wrong - bad.


In fact what is QA's role here? To rubber stamp the developers work? To find issues around the development, but how can QA do that if the only information they have is the specification, that the Developer followed, the testing notes that QA followed.

Does QA even have a clue what the developer was developing?


This is Chinese whispers in a work place. The number of times I seen Developers have meetings\chats with the Product Owner to get more information about a specification, which is fine, but if QA are not involved, how in the hell are they supposed to know what is going on.




4 views

Recent Posts

See All

©2020 by Agile Testing.