16

When you are using the Scrum framework, a Sprint cycle involves development and QA. At the end of the Sprint the tasks worked upon and tested are showcased and released.

Typically, for a team of 3 to 4 developers there would be 1 QA resource. What are the developers expected to do when QA is happening? Since the number of developers is much higher than the number of QA testers, bug fixes get done very quick and developers are left with nothing to do towards the end of the Sprint.

What is expected of the developers during this QA testing while following Scrum?

22

TL; DR

Your question embeds some false assumptions about the linear nature of testing within an agile process. A mature agile team with cross-functional skill sets treats development and testing as intertwined activities rather than as sequential ones.

You should strive to integrate development and testing so that they are not fundamentally separate work streams. Failing that, you must formally accept the risks and process deficits associated with the currently implemented workflow.

QA Must be Embedded, Not a Separate Process Track

Typically for a team of 3 to 4 developers, there would be 1 QA resource. What are the developers expected to do when QA is happening. Since the number of developers is much more than the QA, bug fixes get done very quick and developers are left with nothing to do towards the end of the sprint.

You are not doing Scrum, you are doing waterfall. Activities should be cross-functional, and leverage a multifaceted team approach to all tasks.

As one example, testers and developers should be working in lockstep throughout a Sprint. Testers should be involved early and often, helping the developers design testable features by working on test criteria from the beginning before a single line of code is written, and helping to ensure that tests are written first.

The QA folks should be running continuous integration every single day, so that there's a tight (and ideally immediate) feedback loop between development and testing. By working with the developers, rather than being treated as a separate follow-on activity, QA becomes an intrinsic part of the design and development cycles rather than an externality.

Developers and QA Should Partner for Testing

What are the developers expected to do when QA is happening. Since the number of developers is much more than the QA, bug fixes get done very quick and developers are left with nothing to do towards the end of the sprint.

Just as testers are expected to be involved with the developers from day one, developers are expected to work with QA during testing tasks. Rather than tossing code over the wall to testers, developers and testers should work together on the testing process so that bugs are fixed as they are discovered.

Imagine a pair-programming scenario where a tester and a developer work together on a test suite. Instead of a developer dumping a wall of code on the tester and then waiting for results, the two might work together on tests and refactorings. For example:

  1. QA: The X widget failed the embiggening test.
  2. DEV: Oops. Okay, I'll refactor the embiggener class while you test the end-user insult generator.
  3. QA: Will do. Oh, look, the insult generator passed!
  4. DEV: Great! While you were working on that, I widened the embiggener. Try it again.
  5. QA: It's embiggening properly now. Let's move on to the next set of specs together!

When All Else Fails, Shine a Light on Dysfunctional Process

If for some reason your team can't or won't cooperatively swarm over test-related activities, then the process must make that cost visible to the team. If developers and QA insist on playing volleyball with tasks by tossing things back and forth over a net instead of integrating to perform the work together, then you simply make that (potentially dysfunctional) process fully visible.

Do testers really have nothing to do during the first phase of a Sprint? No, but if that's your process then you acknowledge that having testers idling on the team for half a Sprint is one of the costs of doing business. Likewise, if developers really have nothing at all to contribute to the testing process in the latter half of a Sprint, then you explicitly acknowledge that your developers are getting paid to hang out on Facebook for 50% of the time, and can accept that as a cost of doing business within your chosen process.

Healthy teams treat all members as cross-functional resources, with value to add during each step of the process. Even if you choose not to fully integrate testing as a first-class activity within your Sprints, testers and developers can take turns assisting each other on current tasks. For example, during development a tester can work collaboratively to design test fixtures while the developer is writing the feature; then during testing, the developer might run code coverage analysis or work on converting test results into documentation while the tester runs the tests.

If the team can't or won't work cooperatively in this way, then the organization can simply accept the fact that some roles within the team will be idle at certain points in the process. While not ideal, it might be politically necessary to simply acknowledge that 50% of your roles will be idle at any given time, and that this is an acceptable cost of doing business within your current development process. While I personally consider this a sub-optimal option, it is still better than falling prey to the 100% utilization fallacy that tries to keep everyone looking busy even when doing so is wasteful and generates no value...and sometimes may even actively reduce productivity.

  • 1
    Makes sense @codegnome, what you're suggesting is that a QA and Dev each continue to each follow their roles (which can each have a strength over the other) but to collaborate in a more effective manner straight from the start of the sprint to the end? – John Oct 4 '15 at 11:11
  • @Tivep That's exactly right. It's okay to have slack time in a Sprint--in fact, sufficient slack is essential for agility--but too much slack is usually a sign that the team needs to do more collaboration, pairing, or swarming. – Todd A. Jacobs Oct 4 '15 at 16:42
6

They could be doing a number of things. What they should be doing depends on your organization's Scrum/XP maturity but here are some common items:

  • QA work - yes devs can QA, whether thats writing new automated tests, upping existing test coverage or reducing test complexity, doing manual testing, or performance/load testing, devs can and should QA. The entire team owns the quality of the product. Especially disciplined devs will use TDD, so that most of the testing is done before the story goes to QA. Scrum teams with 0 QA resources are quite common.

  • Tech Debt/Refactoring/Defect Fixing

  • Spikes for bigger functional stories coming in the next sprint

  • Learning new skills both soft and technical. End of a sprint is a great time (like any other) for continuous improvement to occur. Have a dev that thinks it's not his job to test. Pair him up with a QA resource during the second half of the sprint.

  • Grooming the backlog/working with PO to elicit technical considerations.

  • Learning to write and groom stories/tasks that are small so that not all testing occurs in the second half of the iteration.

  • Improving tooling or processes around continuous integration.

Take-away, if your dev's are idle during the second half of your iteration while QA does testing, you've got some opportunities to reap the benefits of true scrum/XP practices instead of living the mini-waterfall scrum.

  • Thanks for that. There are some neat points there @WBW, however, TDD would be part of the Dev activity and not a post dev activity during QA. Also Unit Tests and the tests driven by a QA would be extremely different. The fact that dedicated QAs don't sympathise with the programming difficulties allows for them to take on the role of a User. Devs who are very good have an emotional bonding with the code and are seldom able to become pseudo-users. These two (QA and Dev) can't always be the same person, in fact, that decision would depend on the nature of the project. – John Oct 2 '15 at 16:45
  • Correct, traditional TDD happens before development. There is a softer form of TDD which is to have QA and developers work together before coding to define the test cases (these are usually more detailed versions of AC that get into edge cases as well). Does wonders for getting devs and QA's to start collaborating more. Also makes for fewer defects in the long run as developers start to appreciate not just the code, but the business behind it. I'd challenge your assumptions around QA's that don't sympathise and programmers that are only good because they are emotionally bonded to the code. – WBW Oct 2 '15 at 17:01
  • Give yourself permission to build a true cross-functional team of T shaped individuals and you will be rewarded with a higher quality product and often hyperproductive teams that can do 300-400% more than what the traditional specialist mini-waterfall scrum teams can achieve. – WBW Oct 2 '15 at 17:04
  • I'll try and add the soft TDD element. Regarding cross-functional team, Like I mentioned in another comment, That would depend on what the QA would like to grow into. If he / she is looking to grow towards being a Business Analyst, there would be more resilience to in-depth programing, which is completely fair. I need to keep growth desires in mind and can't force a QA or even a UX designer to become a full fledged developer. Each role has something unique to offer. Besides, this would be a recruitment nightmare too. – John Oct 2 '15 at 17:16
  • Awesome answer @WBW. Fully support this. I was just giving this coaching talk to a senior dev on a team yesterday. – Joel Bancroft-Connors Oct 3 '15 at 16:44
3

"Typically for a team of 3 to 4 developers, there would be 1 QA resource"

That's your problem there. There are three roles in Scrum, Product Owner, Scrum Master and Development Team Member. Your Development team is meant to be a multifunctional team working towards the same goals. It's fine to have people with different skills (in QA, in development), but if you have team members who only can do very specific things (such as testers who can only manual test) that is a problem you need to fix. Test automation is a useful common ground between Devs and Testers.

  • 2
    QA as a function requires far less technical knowledge even if they do automation. When QAs test they are an extension of the end users. They are more closely in connect with the end users. The developers know stuff from a algorithmic perspective. Having Devs and QAs merge into the same set of people is not going to help. – John Oct 2 '15 at 15:20
  • 2
    @Tivep I'm asking for T-shaped people. Having a QA expert for test scenarios, test suits is fine. Your devs probably should be talking to clients anyway. I don't see how having a capable team working together at all times would decrease velocity. – Nathan Cooper Oct 2 '15 at 15:32
  • 1
    @Tivep I would prefer it if your attitude was: "I'm going to encourage and train my team to be better". Scrum has made a shortcoming in a team apparent, but it's up to you how you act on that. – Nathan Cooper Oct 2 '15 at 15:44
  • 2
    @Tivep: Nobody is saying that everyone should be interchangeable/equally good at everything. The ideal team member is an expert in one or two areas, and can pick up simple/grunt work in the other areas as the need arises (as if they were very junior). If there is no dev work to pick up, a developer should be willing/prepared to assist the QA expert in testing the product, for example by executing predefined testcases. It might take longer to work outside your area of expertise, but that shouldn't be a bottleneck for doing it. – Bart van Ingen Schenau Oct 4 '15 at 19:09
  • 1
    "They are technically capable. But will not be able to constantly interface with the client as they need to constantly be coding too." @Tivep beware the 100% utilization fallacy. Also be aware that the majority of programming is not banging away at a keyboard. It's understanding a problem. Velocity is a vector. It doesn't matter how fast you go if it's in the wrong direction. Don't forget that "Weeks of coding can save an hour of planning." s/planning/talking to your user – RubberDuck Sep 17 '17 at 14:40
3

It sounds like you are not really practising scrum but 'timeboxed waterfall'. With this approach each sprint is it's own mini waterfall project, with dev up front and testing at the end. As you have identified this results in wasted time as testers have little to do at the start of the sprint and devs have little to do at the end of the sprint.

Instead the team should be working to ensure everyone is as fully employed as possible (note, not 100% utilised see comments below). During the daily standups and at sprint planning your team should try to work out how they can deliver something to the testers immediately, and then iterate on that during the sprint so the testers can be testing the functionality in parts as it is delivered.

A common part of the standup might be for a tester to say they have nothing to work on later that day. Perhaps a dev then offers to fix a couple bugs they know then can close that morning rather than starting something bigger. That then fills a gap for the tester while another dev is finishing off a piece of work for them to start testing on tomorrow. No one is busting a gut, but you've got a higher throughput of work.

  • I understand. But when a sprint is 2 weeks it becomes very hard to have testable tasks that are 2 days long. For QAs to be testing from the first few days itself, the individual tasks would need to be as small as 2 days. This is not practical though :( – John Oct 2 '15 at 15:24
  • This answer is a variation on the 100% utilization fallacy. The goal should never be to "ensure everyone is as fully employed as possible." That's a particularly rancid project smell, and usually a sign of a deeply-flawed agile implementation. – Todd A. Jacobs Oct 4 '15 at 16:46
  • 1
    @CodeGnome I disagree, kinda. I decided not to get into the concept of < 100% utilisation being the ideal as it would have confused the answer to the question being asked. That is why I said "as fully employed as possible" rather than just "100% employed". I'll edit the answer to make sure no one misunderstands me. I would say though that this whole answer isn't a variation on that fallacy. If your sprints are mini waterfalls you are not fully using the teams time. Trying to fix it by delivering more work early doesn't mean you've fallen foul of this fallacy – Robin Oct 5 '15 at 13:17
  • 2
    @Tivep The last company I worked at did 2 week sprints and managed to deliver testable chunks on the first or second day of the sprint pretty much every time. Your situation may be different but I'd give it some really good thought as to how you might make this possible. Is there really no small part of that larger enhancement which can be delivered into test before the rest? A lot of companies do this every day, before deciding it is impossible do give it some thought. – Robin Oct 5 '15 at 13:22
  • I've had similar experience. Most cards should fall in the 1-3 day range. – RubberDuck Sep 17 '17 at 14:42
-1

The developer can work on improving both the process and the team via several actions required for the end of the sprint, such as:

  • Analysis of actual vs expected velocity to improve trust
  • Categorization of the root causes of defects to avoid repeat mistakes
  • Preparation of a list of items for the retrospective to improve collaboration
  • Codifying manual testing into automated scripts to improve efficiency

References

  • 1
    unfortunately, all of these can happen only after the QA is done. QA is integral for having these discussions. It wouldn't make sense to leave them out. – John Sep 14 '17 at 7:42
  • @Tivep As far as the last one, that is done on production code that QA has already verified, so they can be left out. – Paul Sweatte Sep 14 '17 at 13:44
-2

It is a bit unusual setup you have there, but what developers can do is to start preparing for the next sprint, sort out technical challenges with the new user stories, or do refactoring on the existing code base.

Second option, the "Scrum Book" would suggest that the developers shall do testing as well (cross functional team idiom), of course one developer cannot test what he/she implemented.

Third option, you may want to think about having two sprints parallel but shifted. One for QA, and one for development. The QA would start half cycle later than the development. With this setup you'll have developers and QA working without being idle for a long time. Just make sure that you have capacity in each sprint for bug fixes, otherwise the quality of the code will decrease.

Fourth option, you may hire another QA to speed up testing.

  • 1
    It depends on your setup. One says that the should be, others say they can have their own sprint. It is a clique, but Agile is about figuring out what is good for you. If you have troubles with QA+Dev in a Sprint, try out something else, and discuss the results on a retrospective. – Zsolt Oct 2 '15 at 10:22
  • 1
    No. Not this The scrum guide is only 16 pages an explicitly rules out both splitting up teams based on speciality ("No exceptions") and working on things outside the sprint. If you feel that Scrum is wrong, and are suggesting something different please be more explcit. – Nathan Cooper Oct 2 '15 at 14:08
  • 3
    A cross-functional team doesn't mean each person on the team has to wear every hat. It just means that the team as a whole contains all the essential skills and functions needed to complete each feature. – Todd A. Jacobs Oct 4 '15 at 16:43
  • 2
    @Tivep Scrum doesn't prevent you from having dedicated resources on a team. However, what it does say is that the entire team is responsible for all deliverables. In other words, "Joe" might be your QA subject matter expert, but the whole team is responsible for ensuring that testing is done for every story. No one is allowed to say "Oh, that's Joe's job, because he's the QA guy." Having said that, having dedicated roles rather than cross-trained staff on the team pretty much ensures that you will have queueing issues and resource constraints, so you either need to... – Todd A. Jacobs Oct 4 '15 at 19:47
  • 1
    ...accept the reduced productivity, or cross-train your team members so that everyone can pitch in where needed, even if they aren't the SME for that knowledge domain. – Todd A. Jacobs Oct 4 '15 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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