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