19

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?

Improve this question
1
  • The process described sounds more like a waterfall approach. Every sprint has a sprint goal, and until that goal is attained, work cannot stop. So the agile process comprises a cross-functional team, working iteratively which involves testing and fixing until the goal is attained and the definition of done is established.
    – Judith
    Aug 12, 2020 at 13:27

7 Answers 7

Reset to default
29

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.

Improve this answer
2
  • 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, 2015 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, 2015 at 16:42
8

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.

Improve this answer
5
  • 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, 2015 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, 2015 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, 2015 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, 2015 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, 2015 at 16:44
4

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

Improve this answer
10
  • 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, 2015 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, 2015 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, 2015 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, 2015 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, 2017 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.

Improve this answer
5
  • 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, 2015 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, 2015 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, 2015 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, 2015 at 13:22
  • I've had similar experience. Most cards should fall in the 1-3 day range.
    – RubberDuck
    Sep 17, 2017 at 14:42
-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.

Improve this answer
11
  • 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, 2015 at 10:22
  • 2
    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, 2015 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, 2015 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, 2015 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, 2015 at 19:48
-2

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

Improve this answer
2
  • 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, 2017 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, 2017 at 13:44
-2

I am a developer.

Let me tell you, what you are doing wrong...

Nothing! This is how scrum is designed, and no system is perfect. No wonder you're reading my answer right now because it's a universal scrum issue.

Here is what you shouldn't do:

  1. Don't hire more QA!
  2. Don't ask developers to test, despite code must be tested during development and during PR reviews.
  3. Don't ask developers to help someone else with their stories, no they don't need help unless it was properly communicated.
  4. No, developers should not be "pair testing" like some answers suggested "working together" on testing. QA members are testing my code. They will provide me with bugs to fix when they're done, and I will fix it, and it goes on. THERE IS NOTHING I CAN OR SHOULD DO while they are testing my code but WAIT ON THEM!! Which takes us back to where we started with the question.

Here is what I found to work best:

  1. Developers should work ahead on their items from the next sprint.
  2. It's sad that I suggest to make oneself available for collaboration, because this should be the case during the sprint since day one.
  3. Work on tasks that you don't get to work on during the daily grind to get things completed in time.
  4. In a previous company, this time was spent in training.
  5. Have smaller stories that end in different stages of sprint so you don't create QA bottle neck if most code is tested near the end of sprint.

Really, #1 (WORK AHEAD) is what served me best, because #2, #3 and #4 should be done throughout the sprint, not only when code is being tested by QA!!!

Also, #5 goes without saying.

So, yeah... Work ahead!

When I finish my stories in the current sprint, I ask which story I should start on from the following sprint.

I start on a story from the following sprint, and because I started early before the sprint starts, I finish my next sprint stories (although not all at once), shortly after the next sprint begins, mid-next-sprint, or a few days before it ends (not one or two days before sprint review).

This gives QA plenty of time to test my code, and I have enough time to respond to their feedback. Also, working ahead provides testing tasks for QA throughout the sprint, not only at the last couple of days! This makes QA work load balanced, and not all towards the end of sprint.

Again, the answer is to WORK AHEAD!

This will ensure deployment of features throughout the sprint cycle, which will balance testing load throughout the sprint!

Here is a good article I wrote on my experience with the topic: I solved Agile testing bottleneck problem!

https://medium.com/@salibsamer/i-solved-scrum-sprint-end-testing-bottleneck-problem-bfd6222284a1

Improve this answer
4
  • Who ever gave this a -1, I really like to learn why you think my simple practical solution isn't up to your agile standards lol
    – Samer
    Aug 2, 2020 at 18:55
  • thanks for the answer. Just to be clear, it wasn't me who gave the -1. But I can guess the reason. The idea is to have the answer on this page, and to not have to go to another link to read it up. So it would help to summarize the content in the answer and for the detailed version on can always navigate to the articles.
    – John
    Aug 11, 2020 at 17:34
  • Makes sense. I really thought I was providing a simple straight forward answer. Thank you. I updated my answer.
    – Samer
    Aug 12, 2020 at 5:20
  • Man! I got a second -1... Updating my answer again! Yeah, it's personal that someone actually listen to what I have learned from experience to avoid unnecessary agile stress resulting from ignorance of scrum rules.
    – Samer
    Aug 16, 2020 at 2:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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