Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
3  
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
1  
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
add comment

5 Answers

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.

share|improve this answer
    
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
2  
@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
3  
@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 (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
add comment

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.

share|improve this answer
    
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
3  
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 0:28
3  
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
    
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
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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 likelyhood that the mindsets will conflict and the coder will preform 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 have 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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.