Often a user story, PBI or whatever can include a number of alternate paths, scanerios or examples. The team has ideally listed them during backlog refinement and 3As.
When a diligent software engineer picks up the item, they can write their automatic acceptance tests and also provide manual testing as well, listing the testing in changes changeset notes.
So when an engineer, whatever their job title, picks up testing of the work, do they perform acceptance testing? Is there value in this?
In an ideal world, this can be considered busy work that we can skip. We should be able to trust our code when it is committed and instead focus our efforts on testing that is more valuable like exploratory testing to find defects or learn about the feature and its quirks or nuances. We can focus on performance, scalability and more complex testing.
But this requires us to trust our code. Something that historically isn’t the case… hence why we have testing! (and bugs)
So what can we do to remove the need for mindlessly going through a truth table, long list of ACs or a wad of scenarios? I don’t know and this is what I hope to learn. However I do have a few ideas of things to explore:
- Code coverage analysis for automated tests with our available build tooling to discover if this can give a (genuinely) useful metric at a day to day level.
- Automated test coverage within code reviews to discover if someone who doesn’t develop the code can identify what is adequately covered by automated testing.
- Pair programming with a developer and tester to discover if this helps both improve coverage and visibility of coverage. Perhaps writing automated tests.