The short answer
Hand over automation and regression suites, keep exploratory testing close to people who know the product. Automation is a coding task with a clear specification. Exploratory testing is a judgement task, and the judgement is about your users.
Teams that get this backwards end up with a large suite of tests that pass while the product feels broken.
What hands over well
- Automating an existing manual regression pack
- Building test infrastructure and harnesses
- Performance and load testing against defined targets
- Accessibility checks against a published standard
- Cross-browser and device coverage
- Test data generation, which is fiddly and nobody wants to do it
Each of these has a defined right answer. Someone can do them well without knowing why your customers behave as they do.
What does not
Exploratory testing depends on a sense of what is normal. Someone new will not notice that a total looks wrong, that a workflow skips a step users expect, or that a message uses the wrong term for your domain.
That knowledge builds over months. It is worth keeping inside your team, and worth writing down where you can, because it is also what leaves when a tester moves on.
Automating an existing pack
- Start with the tests that run most often and cost the most manual time.
- Write the expected behaviour down first, because manual packs are usually incomplete.
- Resolve the ambiguities before automating, since a test encodes an interpretation.
- Automate in order of value rather than in the order the pack is written.
- Keep the manual pack running until the automated one is trusted.
Step two frequently surfaces disagreement about what the product should do. That is a useful outcome in itself, and better found now than in an automated test that encodes one person's assumption.
Flaky tests are a real cost
| Symptom | Consequence |
|---|---|
| Tests that fail intermittently | People stop trusting the suite |
| Re-running until green | Failures get hidden |
| Long-running suite | Developers stop waiting for it |
| Tests coupled to markup | Every UI change breaks them |
A suite nobody trusts is worse than no suite, because it costs time and provides false comfort. Agree up front that fixing flakiness is part of the work rather than something to get to later.
Keep the ownership
Test suites decay when nobody owns them. If the augmented engagement ends and the suite becomes nobody's responsibility, it will be disabled within a few months of the first awkward failure.
Name an owner on your team from the start, and have them involved enough to maintain it. The suite is only worth building if someone will keep it alive.