Last week, I replied to a tweet (see below). I try to keep my comments to the allowable characters to make a point without making it a full discussion. I’d rather have those in person, which is what happened. Paul Seaman (from Australia and @beaglesays on twitter) took me up on my offer to chat and we ended up having a great discussion about tasks and columns on a story board among many other things. I learned a little, and he took away some ideas that he wants to try with his team – a win-win in my books.
Our chat started with the idea of using testing tasks rather than a lot of columns on your story board or in whatever tool you use. My personal preference is a physical story board, but I recognize that is not always possible.
In our conversation, Paul shared that their five initial columns were “To do, in dev, walk thru, in test, done”. Because it felt like phases rather than flow, they removed the ‘walk thru’ and ‘in test’ columns so were left with three. I know many teams that use those three columns or some version of them “to do, in dev, done”. What you call them doesn’t really matter as long as — ‘in dev’ means more than coding.
I like the simplicity of three columns, but I also think having the work called out in tasks is important (unless the stories are very small). One problem I often see in teams, is there may be many tasks for coding but only one for testing. The testing task will say something like “Test this story”. When teams do that, it hides all the work that really goes on in testing the story.
What is preferable to me, is to make the work visible. By having individual tasks such as ‘Create test data’ or ‘Create exploratory test charters’, we enable the rest of the team to help with the testing activities. Anyone can then pick up one of the testing tasks – it is not limited to the tester.
Paul’s team hasn’t created tasks before the start of an iteration, they create them as they start developing the stories (if at all). It has seemed to work well for them, but he liked the idea of making the testing tasks visible. His team does a lot of small experiments to continually improve so this was one idea he wants to bring back to his team.
As an aside, my columns (or states) of choice are “To do”, “In progress or doing”, “To review”, and “Done”. Most (if not all) tasks are not testable, but they are reviewable, so having a column for reviewing makes sense. For example, ‘Creating automated tests’ is a good thing to review with someone before you check the test into your version control or give them to the programmer.
In our conversation, Paul mentioned that their stories can vary from ½ day to almost 2 weeks. I started to talk about how I coach teams to break the stories up early – in story readiness workshops before the iteration starts. That was when Paul said – “That is what’s happening with our stories. The programmers are asking to do it earlier now”. That made me realize that sometimes, it is best to let some ideas emerge organically, especially when a team has the culture of continuously experimenting. They feel safe enough to try new things.
The next part of our conversation was about getting people to pair. Paul was having a hard time selling the idea of pairing, so I shared some of my positive experiences. Sometimes the soft sell works best. Don’t call it pairing … use different terms, and when you have success, call it out.
Our conversation weaved in and out, talked a bit about things like formats of tests such as ‘Given/ When/Then’; what was good, what was bad. I loved that Paul’s team is working with people on the autistic spectrum. Diversity is a great way to get new ideas into a team.
Our final bit of the conversation turned a bit to something more personal – how we saw testing in our lives. We both experienced spouses who tell us to stop … just stop testing all the time. I’ve often said I can’t help it, it is who I am. But, I like Paul’s way of expressing it – “Testing is a way of thinking, it is a lifestyle”.
So, the next time you have a conversation on twitter, think about taking it off line to get a better interaction, and maybe even make a new friend.
5 comments on “Do You Need a Test Column?…. Let’s Talk.”
It not only hides the complexity of testing – it also causes us to start thinking on how and what to test only after the feature already landed on our desk,
Meaning we had no time to learn it, prepare test guidelines, review them….
I may even put in a task that says “brainstorm’ testing ideas if the story is complicated. I find when I include the whole team (or at using the three amigos) before coding starts, we have a much better understanding of what to build.
I like defining what is the desired behavior is when creating the story. There’s a lot of testing there when done well. I’ve seen many “requirements bugs” get squashed during BDD Three Amigos discussions. I like doing this with Matt Wynne’s Example Mapping, and doing it before the story is brought onto the story board.
Then, the programming part isn’t done until that desired behavior is demonstrated. Since we know what this behavior is, I find it helpful to automate the checking part. I’m accustomed to well-executing teams sharing work with the tester during development, and getting feedback there.
When I see a “To Review” column, it makes me think of review by a Product Owner and/or actual users. I suppose that might be a good place for a code review, also, including the test automation code.
I think the review column could be used for lots of things. For example, I have used it to review my exploratory test notes with others. Or, if my task was to create ET charters, reviewing those with another person.
I completely agree with defining the behaviour when creating the story, and using concrete examples to help explain. The story board is about what is being implemented, and often (if not always), there are boundary tests (for example) which do not come out in the early conversations.
Great insight as usual Janet.