What are developers expected to do during testing in the latter half of each Sprint?

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

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

• Agile team missing commitments regularly and complaining about no trust
• Why I'm done with Scrum | Jimmy Bogard's Blog
• My Experience as a QA in Scrum

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.

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.

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

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.

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.