Imagine that you're a tester in an agile stand up meeting with your development team. You have all gathered around your visual management board, each person is sharing an update and it's your turn to speak.
"Yesterday I tested story 19574 and didn't find any bugs." you say, moving that story to Done.
"Today I'm just going to test story 19572." you continue, moving that story to Doing.
"There's nothing blocking me at the moment, so that's it." you finish.
Now consider whether, based on the information you've just provided, anyone in your development team actually understands what you've done and what you're planning to do.
If you were to ask them, they might say that you're testing. You are the tester. You just told them you were testing. They're not stupid.
But what exactly does that mean? Have you been confirming acceptance criteria are met? Have you been investigating how this story handles error scenarios? Have you tested from the perspective of each of the business user personas? Have you tried some simple penetration tests to determine whether this story has covered the basics of security?
We can make testing more visible through the use of visual planning. Illustrating our thinking through visual test models or visual test ideas is a great way to engage our team in conversations about testing. But we can also make our testing more visible by being transparent in our stand ups.
Start making a conscious effort to be more specific. Take the opportunity in your stand up to verbally create an image in someones mind of the activities that you're undertaking. While you may not have time to tell the whole story, you can certainly share the blurb rather than the title alone.
Without this detail there's a good chance that what you do is a little bit of a mystery to your team. And if they don't really understand what you're doing, then it may be difficult for them to identify opportunities to collaborate with you or help to anticipate problems that could prevent you from completing a testing task.
Making testing visible is not just about changing the documents you produce. Take the time to prepare for your stand up so that you can briefly explain what you are actually doing. I'm sure that you are not "just testing".
Nice point raised. As more people start working in teams with actual agile communication methods like the stand-up, mumbling will not cut it.ReplyDelete
Developers in our scrums know not to be vague about what bug areas they are in when on a bugs-blits. They also know that Bug IDs are meaningless in the scrum but not in a triage meeting. Precision is good and might sounds all official and comfortable, but being descriptive and using the scrum to trigger these mind pictures is a skill that will take quite a few scrums to perfect. Agile should not be comfortable, if it is we are doing it wrong.
I'll have to do this tomorrow in the scrum :-)
I like being specific. I also like being afforded an opportunity to express to others in the team about what I'm doing. However, I often find the PM closes me down saying "we don't have time" or "we can take this offline" mid-sentence. All the PM seems to care about is which ticket is in done. :-(ReplyDelete
Steven, I am pretty sure that your PM is the one wearing the chicken hat in the scrum. Remember that the chicken is a contributor but the pig is committed. #baconandeggsReplyDelete
Great post!! It's like you've been watching our standups :/ReplyDelete
I'm sharing this with my team and issuing them a challenge to step up and make testing more visible to our colleagues.
Another great article by Katrina! I haven't been doing Standups for long-2 years - and i've made 2 conclusions: 1. Standups, when there is a Kanban board, are irrelevant. They just reiterate what's on the board and they move on.ReplyDelete
2. When someone speaks with vagueness, I know they either don't understand the problem at hand, or they're behind.
I don't understand the point of standups in their current format as Agile promotes constant communication between testers, devs and BAs. I know of teams who do weekly standups and this seems to work very well.
I agree on what you say. I feel the same too. We do more that what we say in the standup. We sometimes say highlevel we have a issue when we do this and this and the development pair is looking at it. What else can we say? We have checked the acceptance criteria so now we are exploring different combinations? We are at step 5 on the diagram on the whiteboard testing the possibilities? I would love to do that. But is that what you imply? Thanks!ReplyDelete
From a testers point of view, I find myself doing exactly what Katrina has said. I'm even more vage by just saying going Spring X Testing, I don't go into the detail of what tickets I've tested. I'll be looking to implement some of the points raised in this blog in the coming days. Thanks KatrinaReplyDelete