Why does the Scrum guide say no testers?

I have been reading the Scrum Guide from scrum.org and it says:

Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

In its literal translation this means that there are no testers which is confusing. How can they be suggesting this?

It means that either:

Testers are integrated into the development team – building tools to help developers test as well as testing.

or:
The team practices Test Driven Development – i.e. They write automated tests that exercise the system.

Either of these means that there is no need for a separate testing team.

In its literal translation this means that there are no testers which is confusing… How can they be suggesting this?

Yes, this is exactly what they suggest. In other words – the developers are the testers and the testers are the developers.

The idea is to foster code ownership and quality.

This does not mean that code is not tested, but that the people involved in writing it are the ones involved in testing it – there is no separation of responsibilities.

The problem this approach is trying to address is the all too common separation between the developers and testers, where developers will write code and “throw it over the wall” to the other team and it then goes back and forth, delaying the project and producing sub-standard software.

The fundamental part to this is that the coder’s responsibility is to create code that works and fills the requirement. This requires a particular mindset – “The code that I am writing does what it is supposed to do.”

To mix the responsibilities of the coder means that the coder is now required to enter other mindsets for other activities, however, as a coder, it is difficult to impossible for one to completely divorce one’s self from that mindset.

The tester’s responsibility is to find bugs and places where the functionality diverts from the required functionality. This required the mindset of “The code is broken and I will find out how.”

Likewise, a business analyst is trying to identify the requirements that the customer is actually asking for. This requires another mindset of “the application doesn’t work this way, but it should.”

For a coder to work in any of those other capacities, there is a reasonable likelihood that the mindsets will conflict and the coder will perform sub-par:

Coder/QA – “The code works perfectly, and I have already coded to
handle every possible way I can think of that might break it.”
Coder/BA – “The code should work the way that I want it to and these
would be neat things to add to it that the customer didn’t think of.

This is not to say that every coder is susceptible to these problems (I have meet some very gifted coder/QA types… though not for code that they wrote).

This extends up to the development team as well. Mixing the responsibilities and associated mindsets of those responsibilities for a development team compromises the final product (the code).

It says there is not sub-team dedicated to testing. That does not mean there are no tests done whatsoever. It only means that team members will do their own testing, and often test other people’s code/features. I’m not that familiar with the scrum methodology, but I will go on a limb and say that the client may also be involved in the testing.

I think this partly means you are expected to write tests for your own code so that you know it works (if not, you haven’t really finished it) and partly that you may well be expected to be a tester for other people’s code sometimes.

Rather than allowing people to offload the software quality job onto someone else and ignore it, this forces everyone to think about the code they are writing from a quality perspective all the time, so it’s a good idea.

This statement is basically trying to avoid siloed working. One part of the solution to this are practices like
– Test Driven Development
– Pair Programming
– Pull Requests
– Test automation
and the likes which all make testing an intrinsic part of the development process rather than something that is done in isolation either on the side or ‘after’.

In addition, there is very limited talk about roles in the Scrum Guide. In fact, they talk about the Development Team. What they mean is that you want a strong cross-functional team. This means that dependent on what your projects need, you need a range of skills, such as UX, BA, QA/Tester, Ops, Coder, etc etc but whether this is one or many individuals covering these, doesn’t really matter.

The teams I work with certainly have QA as a role, as we have DevOps people. But they are all also Devs, just with specialisation in these areas. The trick really is to not fall into silos and work in isolation.

It doesn’t necessarily mean there are no testers. It may be the case that a Scrum team has dedicated testers or it may not.

To me, what this statement about Scrum means is that you should be thinking about the entire delivery pipeline as a single team. Being part of the same team suggests a few things:

There is a single estimate on a story/bug/task. There is not a dev estimate and test estimate.
The team does not estimate a story and commit to it without the tester present.
If something goes wrong, it is no more the tester’s fault than the developer’s fault. It is the team’s fault.
The team never needs to borrow, request, or ask for, testers.
Testing is part of the definition of done. Untested work is incomplete work.
Developers should be considering testability as they design their code.

If they are working together a single team, then the team succeeds together and fails together. I’ve been on a very successful Scrum team which had several testers. Testers were present during all standups, grooming sessions, planning, etc. If it wasn’t clear how to test a story, the team would not commit to it. We always spoke with our testers when estimating.

Potential signs you may not really treat testers as part of the delivery team, even if you think you do:

Testers have a “QA standup” (yup, I’ve seen it).
Testers have a separate management structure.
You have a QA lead.
You rely heavily on end-to-end tests.
Tests get written the following sprint.
Most testing occurs on the last day of the sprint.

These are subjective and not necessarily wrong. They are red flags though, in my opinion.

All this said, it is entirely possible to have a Scrum team without anybody who has a designated role of tester. That can work well too. Especially if you automate testing. TDD helps too.

Filed under: softwareengineering - @ 13:10

Thẻ: scrum

Thiết kế website giá rẻ

Danh mục

Why does the Scrum guide say no testers?