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.
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⌠
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 trustradius.com, 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.
True story. You said if so well 