Testing notes are a set of hints which accompany tickets, and serve as a guide for the developers about the type of risks and issues they need to take into account during implementation.
Testing notes are not a checklist and they’re not set in stone. Their purpose is to provoke critical thinking regarding areas which could be affected and could go wrong with the development of that particular item. They can and should evolve during the development itself, if the scope of the implementation changes.
One can draw inspiration for these
- From previous testing notes,
- From previous issues your project has had,
- And most importantly from knowledge of the product.
This is why it’s important to note that testing notes are not a responsibility of a certain person, but the whole team. Everyone brings in their own knowledge and viewpoint of the project and can contribute toward them in a different way - someone has better understanding of things from a player perspective, someone from a code perspective, etc.
Testing notes should be written latest before the development actually starts, but a suitable time to do this is during planning as usually the whole team is able to contribute at that time. There are always easy ways to start:
- What areas of the code will be affected?
- What other problems have we faced with similar implementations?
- What would you do to try and break this?
The last may lean toward negative testing, but usually that’s what testing notes are about. If a hint focuses on positive confirmation that the implementation works correctly - consider if maybe it makes more sense for that to be under acceptance criteria.