Are there any researches that prove that agile testing is better than waterfall?

Hey guys! We are doing agile testing where all crafts are supposed to test. However, got a question from someone in leadership. Why should other crafts do testing when we are not expecting QA to write code or draw? Also they assume it’s cheaper to just hire bunch of QAs instead of waist developer’s time on testing. Are there any researches that prove that doing agile testing is more profitable than doing testing after development?

Thank you!


In my opinion, there are several reasons why everyone should be involved in testing - mainly because different roles can contribute to testing in different ways - the developer is the most technical and can contribute to automation better than others, business-oriented roles, like BAs or POs, can help with acceptance testing as they are usually the ones who have the most contact with the customer and have the best domain knowledge.

A lot of companies hire entry-level testers so the developers can only focus on coding and developing new features, this approach is problematic as it leads to situations where testing become a blocking activity (bottleneck) in the development process, regressions are done manually - which takes up a lot of time, testing is not done thoroughly as there are always deadlines looming over the horizon. And as the problematic snowball keeps rolling, and getting bigger and bigger, because testing was shallow and rushed we end up with bugs in production. Which end up costing the business way more than it would have to do things “the right way” early on in the SDLC.

The advantage of Agile is (or should be) is its flexibility, having a product that satisfies the customer is the most important thing, meaning that there isn’t much time for overly detailed documentation and formalities in general. In modern times, if a business can’t react fast enough to changing market trends, the competition will topple them. That being said, Waterfall would be better than Agile in cases where we have predictable requirements which are not changing.

The biggest problem with Agile is that it’s not used as it was initially intended, it should be flexible and what we often see in the real world is just a shallow husk - where people only stick to the Agile ceremonies and still do things in stick and inflexible manner - and we end up using Waterfall with Sprints.

All in all, things are not black and white, sometimes Agile is better, other times Waterfall is better.
Here is an interesting article on the pros and cons of each.


The trouble with any question, is that it can only ever be fully answered in “the context of the questioner”. A person asking “How do I fly a plane?” needs a totally different answer if they are sitting in the airport lounge versus if they are sitting in a Cessna at 1000 feet next to a comatose pilot. It’s not possible to “prove” anything, it is however possible to talk someone who has never flown a plane, down to the ground safely so long as we know their exact location and can guide them to a tower, the the weather is poor, all bets are off. I think you may be looking at a poor weather situation @elena.bazina . So lets play bingo, choose any one of the 4 below.

  1. To be blunt, “Agile” is merely “Waterfall, but just lots of smaller ones” that start every 10 days and burn the developers out quicker. So lets drop the entire “Agile” label, because “agile” small-‘a’ really means to keep your eyes on the mission but get there as fast as humanly possible by doing experiments that teach us about the best route to follow.
  2. Most testers know that 82.73% of all research projects prove, their original hypothesis.
  3. Why test early? Well testing is all about uncovering “truths”, the sooner we do that the better. “agile” is pretty much about the same thing, finding out about progress hurdles early. Developers always test their code, but my experience is that very few developers integration-test. Waterfall often delays that kind of testing activity, and depending on whether the Cessna is on the ground at the time or in the air, that makes a big difference.
  4. “Just hire testers” , well you can subcontract your testing out, that’s far far cheaper than hiring but will get you into other kinds of problems. You will miss out on the fact that good testers, test 3 things. They test the product, they test the people, and they test the environment. All 3 things are important to the success of a product, why would you wait until the code has been written before you check for issues in the way people built it or find issues with the way the product will get deployed?

Sorry I’ve not answered your question, but rather given a few elevator pitches, but my good friend @mirza had already beat me to giving a good answer.


Brilliant! You nailed it! I really liked the analogy with airplane part!


Not sure what you mean by “draw”, but anyway: why not?


Working waterfall isn’t always bad. I think people tend to say ‘ow you work waterfall and not agile’ is rough. Waterfall can be good, people hype agile just way to much. They try agile and most of them fail without knowing.

Some companies should work waterfall and they are better off doing so. I know a few companies who do so and it works fine and everybody’s happy. It’s more then just profit, it’s about customer happiness but also employee happiness.

So don’t think waterfall is always bad… :smiley:


I feel there may be some misconceptions on your context:

Everyone will always test. Testing is part of building.

If increasing the number of testing specialists are cheaper than having developers focus more time on testing, then one should have more testing specialists. There is no one-answer-for-all, it depends on the business.

I suggest the talk Testing is Testing - Agile is Context, by Michael Bolton to clarify some concepts for the people who are specialised in testing. (slides here)


Lets jump back a little bit, this is what I saw.

So originally we had developers and they did all the testing themselves, they had full responsibility for quality, it was fast and efficient.

Products got more complex, larger, more integrations with other systems and being human, the developers let a few things through the gaps. The industry often led by big financials overreacted a little bit and brought in separate test teams to test at the end.

So here in effect it was waterfall. We had things like PMI running how projects were run but that training did not really talk about testing at all, but a lot of new test training came out based on the PMI command and control model. In my view bad testing practices came out of this, over emphasis on planning and test cases, QA police mentality, limited collaboration and a bias towards tickboxing written requirement specifications.

Byproduct was also developers started taking less responsibility for quality, blame game and a lot of other nonsense alongside potentially poor testing itself.

Testing generally testing in any context but the above often gives waterfall testing a bad slightly unfair wrap. You can do good testing in waterfall just as well as agile.

Those testing problems with waterfall were just a small part of an adjustment of the testing model to adapt to agile development practices.

The original fast and efficient view of developers doing test activities was re-embraced, alongside high levels of collaboration and team ownership of quality, but rather than revert fully back to original model it also embraced complimenting the team with small numbers of professional testers. This model can also be applied to waterfall practices.

The comparison of agile versus waterfall testing is flawed but there is some thinking bias behind it.

With regards to developers doing test activities that was/is a fundamental part of their role from a product efficiency perspective. From my perspective I expect them to cover the known risks and the basic verification side of things allowing my testing to look more into the unknown.


Before comparing both the methodologies- Agile And waterfall, let’s consider some of the stats.

Based on a poll by, fewer than one in five professionals said their organization uses the waterfall methodology. 81% said the organization uses the agile methodology instead.

Research done by HP stated that 54% of agile users say their largest motivator for using agile over a waterfall is that it enhances collaboration and teamwork.

The waterfall model is more about a process, where one can see progress “flowing” through different phases. It is a sequential form of model which goes from requirement analysis, design, implementation, testing, and production to maintenance. However, when agile is the base of development, it tends to deliver visibility adaptability, Accountability and value at the beginning of the process thereby lowering the risks during the project.

1 Like

True story. You said if so well :clap:t3: