QA Strategy: Things a Developer Can Work on During the End of the Sprint

Motivation

I call this QA Strategy because sometimes QA has to fight the battle of preventing development from "getting ahead" or as I'd call it, "violating core agile principles."  One place I worked, everyone seemed ok with having sprint planning on the Friday at the end of the sprint, even if QA was still working on current sprint... a battle I lost.  The devs were apparently not creative enough to come up with things they could do to help the team/project/company that didn't involve writing application code.  Not that it made me bitter or anything.

Ideas

Roughly in the order of what I'd request if I was the QA manager

1. Testing
1. ...other devs' code of course
2. Helping QA do their testing
3. Helping with automation (but not preventing QA from learning/doing automation)
2. Prepping your demo (if devs do demos)
3. Documentation
1. Code comments
2. Documenting features on the wiki
3. Organizing / maintaining the wiki
4. Writing unit tests
1. Should be done in-sprint prior to giving to QA, but sometimes this doesn't happen
2. Backfilling unit tests for old code
3. Fixing old broken unit tests (let's be real)
5. Writing in-house tools
1. Integrations to things like Jira, cloud tools, analytics tools, etc.
2. CI/CD tools
3. (Test) data creation tools...
6. Knowledge sharing
1. Silo busting with other developers
2. Training other groups in the organization (account managers, support center staff, sales team)
3. Learning from other groups in the organization (account managers, support center staff, sales team)
4. Mentoring junior devs
5. Mentoring people from other groups in the org who want to be devs
7. Learning new skills
8. Simple refactoring