15

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?

Joachim Sauer
  • 11,006
Pete2k
  • 735
  • 7
  • 13
  • 4
    In its literal translation, this means there is no programmer either. There is no business analyst. An apt analogy is that everyone is a survivor, whose job is to do (and learn to do) everything needed to help everyone survive. – rwong Dec 14 '12 at 17:25
  • 3
    No, that's not the literal translation at all. It says there are not dedicated sub-teams, that is all. You can divide your team into sub teams to tackle problems, but those teams should be able to mix and match at the drop of a hat. It says nothing about not having testers. – zzzzBov Dec 14 '12 at 19:18

7 Answers7

25

It means that either:

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

    or:

  2. 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.

Community
  • 1
ChrisF
  • 38,938
  • TDD would be a better approach for startup teams. I have strongly felth that when testers and developers work together in novice teams, testing becomes an issue. What do you say? – Maxood Dec 14 '12 at 16:25
  • 4
    @Maxood: I'd say that TDD most definitely doesn't make manual testing superfluous. If something becomes an issue, you solve it; you don't start avoiding it. – Michael Borgwardt Dec 14 '12 at 16:29
  • @MichaelBorgwardt Very true! But what if you find your tester busy in unit testing which is primarily a developer's job? I feel the former option should only be availed when it comes to code optimizatiion and application scalability, etc. What do you say? – Maxood Dec 14 '12 at 16:44
  • 7
    @Maxood: Testers should, in my opinion, not touch unit tests. They should work on acceptance tests, in cooperation with developers, and have responsibility for the manual/GUI testing. The unit testing is on a level that is only interesting for the developers. The test pyramid (http://blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid) also has responsebilities, Unit-testing=developers, acceptance testing = shared, GUI testing = testers. – martiert Dec 14 '12 at 18:04
12

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.

Oded
  • 53,586
  • 19
  • 167
  • 181
  • 2
    I am a strong advocate for having person A test what person B developed. What does scrum have as advice to avoid the pitfalls of "own code blindness" (where if you are both developer and tester of feature X, you don't exercise the code in all respects because you know how it is coded and assume it must work, or subconsciously avoid the weaker points)? – Marjan Venema Dec 14 '12 at 16:35
  • 1
    @MarjanVenema - What person A wrote can be tested by person B, or the automated tests be written before any code was written. – Oded Dec 14 '12 at 16:39
  • 5
    All developers have a QA blindness that never goes away. What happened in the industry is people went too far with the "QA versus Devs" and created that "throw over the wall" system, and then there's a backlash. Devs and QA succeed and fail as a single team, but QA is a role and a skill that is different than coding. Coders need to dev-test, and unit testing is a part of QA, but it's not the entire QA function. Also, QA roles often involve creation of documentation in places that haven't gotten so "agile" that they've stopped writing technical documentation. – Warren P Dec 15 '12 at 00:28
  • 6
    In my experience it is exactly the separation of roles that allows a tester to look at the software from the point of view of a final user and find much more bugs than a developer would. The resulting product is definitely not "sub-standard". – Giorgio Dec 19 '12 at 16:03
  • 2
    QA and development are two distinct roles with two different skill sets (and salary scales). Excellent QA requires a level of focus and specialization that simply won't happen if someone is doing dual duty as developer and QA. – 17 of 26 Oct 30 '13 at 18:13
  • The problem with (parts of) Scrum is that it comes and is applied (partially) as a reaction to faulty over-extreme applications of other processes. And while Agile says people over processes, people now do the same mistake with scrum, taking it's guidelines meant to avoid the problems of the last tool set used and strictly applying them to mold new fixed processes. – Frank Hopkins Apr 24 '19 at 03:06
  • @MarjanVenema I am not sure if Scrum has defined anything concrete for this. But in our team we solve that using Pull Requests in git. When you wrote a piece of code and want to merge it, another person must review the code and accept it. – Gladen Apr 24 '19 at 10:15
2

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).

geocodezip
  • 382
1

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.

marco-fiset
  • 8,761
  • "The client may also be involved in the testing" - yes, exactly right, otherwise you have a waterfall project where the definition of done is "we have reached the end of the project". That's not agile. – Robin Green Feb 03 '15 at 16:31
1

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.

Matt Gibson
  • 301
1

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.

user334514
  • 51
1

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:

  1. There is a single estimate on a story/bug/task. There is not a dev estimate and test estimate.
  2. The team does not estimate a story and commit to it without the tester present.
  3. If something goes wrong, it is no more the tester's fault than the developer's fault. It is the team's fault.
  4. The team never needs to borrow, request, or ask for, testers.
  5. Testing is part of the definition of done. Untested work is incomplete work.
  6. 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:

  1. Testers have a "QA standup" (yup, I've seen it).
  2. Testers have a separate management structure.
  3. You have a QA lead.
  4. You rely heavily on end-to-end tests.
  5. Tests get written the following sprint.
  6. 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.

Brandon
  • 4,575