Imagine being assigned responsible for helping all projects and products in your organization being started on a good foot in testing. There's enough of them that you just can't imagine being there for all of them to teach them the necessary skills. You've seen a good few being lost on testing, miss out on availability of test environments and data, and projects being delayed. You want to help, give some sort of a guideline.
The usual answer to this is creating a template of some sort, to guide people through important considerations through documenting their thinking. When they document their thinking, others have a chance of saying what is missing.
If it sounds so lucrative, why is it that these plans often fail? People don't fill in the template - finding little value in it. People fill in the template - the testing done does not match the plan; people don't read the text. And you really can't create skill of thoughtful thinking over a template.
Yesterday at #frogsconf (Friends of Good Software), one of the conversations was on the test plans and templates we create. As I saw others examples and showed mine, I hated every single document that I had written. The documents are not the conversation that precedes good work. The documents create a shallow bind between the reader and the document, and true co-ownership would require ensemble writing of the document so that it's ours, not mine. And instead of the many words, we'd be better off with filtering the core words out that will lead our efforts.
My strategy for test automation nowadays distills into one sentence: if we don't change anything, nothing changes for better.
The less words we write, the more likely we are to get people to read them, hear them, internalize them and use them to guide their work.
To create a plan, a better approach might be a visual whiteboard with as few sections to fill as possible. Allow them to find their words and concepts to explain how they will do the work.
I shared an example from the course I have been creating, an example I have experienced to direct students into better testing the application. The problem is, I needed to do the work of testing the entire application to be able to write that document, and that is not what we can expect with projects.
I wrote a test strategy for eprimer - a little test practice target. The thing is, I could write it after I had tested it. I had plenty of ideas before, but only the end result after testing is worth a document. Plans tend to be premature. pic.twitter.com/RrZxgbaqtr
— Maaret Pyhäjärvi (@maaretp) September 4, 2021
I have a few plans I need to do next week, so now is my time to think what will those plans look like.
