I've run my fair share of sessions where we test together something. My favorite test targets recently have been DarkFunction Editor (making 2D sprite animations), Freemind (mindmapping) and ApprovalTests (golden master test library) but there's a thing that is common to all these three. When I introduce them to my groups for testing, they're static. They don't change while we test. They are not early versions with the first of user stories implemented, to grow much later. They are final releases (until next one comes along).
In projects that I work with, I test a lot of things that are not yet the final releases. And it's almost like a different ballgame to find the right time to give feedback on things. In my experiences, early testing has been crucial for allowing for time to understand what we're building to guide that also from a testing perspective. As we learn in layers, the testers too need time to peel a layer at a time to be deep by time of final rounds. But it has also been crucial to fix issues before they become widely spread assumptions that can't be questioned without the whole brick structure falling down on us.
Some years ago, a session I was running was playing with this dynamic. I gave a group of testers the scope of product backlog (stories) for 1st increment and asked them to plan their test ideas. Usually very little came out. I gave then the 2nd increment with very similar results. Then I fast-forwarded 10 sprints to a close to ready game, and I got a long list of things to consider. The point of the session was to show that thinking in the ready state is easier, but having done that, you can categorize then your ideas to figure out how early you could run tests on some of these.
I think it is time for me to experiment with three different new sessions.
In projects that I work with, I test a lot of things that are not yet the final releases. And it's almost like a different ballgame to find the right time to give feedback on things. In my experiences, early testing has been crucial for allowing for time to understand what we're building to guide that also from a testing perspective. As we learn in layers, the testers too need time to peel a layer at a time to be deep by time of final rounds. But it has also been crucial to fix issues before they become widely spread assumptions that can't be questioned without the whole brick structure falling down on us.
Some years ago, a session I was running was playing with this dynamic. I gave a group of testers the scope of product backlog (stories) for 1st increment and asked them to plan their test ideas. Usually very little came out. I gave then the 2nd increment with very similar results. Then I fast-forwarded 10 sprints to a close to ready game, and I got a long list of things to consider. The point of the session was to show that thinking in the ready state is easier, but having done that, you can categorize then your ideas to figure out how early you could run tests on some of these.
I think it is time for me to experiment with three different new sessions.
- Incremental test planning/design - bring back and improved version of something I have not paid attention to for years.
- Incremental exploratory testing - figure out a way of running a course where the test target is not static but grows incrementally
- Test idea creativity - while executing and generating ideas now come for me intertwined (curse of knowledge), looking around me I realize that the creativity part of it could use more focus.
