Meetup #40 – it’s all fun and games until… #SydTest

Last Thursday was the Sydney Tester Meetup #40 at the Vibe Hotel. I arrived late on the scene and the party was already well and truly happening. There were about five or six tables of people playing testing games or passionately debating different issues about testing (e.g. “Product Manager” vs “Dev” – who would be the better tester?). There were a few rounds of dice game and James Bach and Rich Robinson were doing their usual “Mind-Reading” duet (where James and Rich communicate via a protocol known only to them and players have to try and break that protocol). There was a real buzz around the meetup that can only be generated by people who are so passionate about their profession that they make it into a game!

Hope to see you all at the next one.

FULL DISCLOSURE: The author is the current Social Media Champion and Co-organizer for Sydney Tester’s Meetup.

Model of Product Risk: Team-Component History from #OzWST2014 #SydTest

In my last post I introduced the model of product risk and the first component of the model: the Impact of Failure. This post will cover the next component: Team-Component History.

This component initially related to what information I have on the developer, the feature under test and any interaction between the two. In the example used in the previous post, my understanding of the developer was that he was very experienced with the product as a whole and what the business was trying to achieve. The feature, however, had a turbulent history of being very difficult to get right and had already been scrapped and rewritten once before.

With this in mind, the risk profile remained at medium-high. My rationale being that it’s a tricky feature but the experience of the developer working on it would mitigate the risk of the trickiness.

It has been almost three months since I presented these ideas at OzWST and I am still chewing on how to best present this idea to a team. It is a edgy issue that, if presented wrong, could put a tester offside with the rest of the dev and possibly the broader product team. Perhaps this is a conversation the tester could have with the dev team lead while emphasising “the experience of developer A with feature X” as the key factor rather than “the apparent quality consciousness of developer A.” To be clear, it IS the former that I am concerned with in this model.

Angela Baird suggested broadening this idea to “If you place the developers under such scrutiny, why not other team members, like: the testers?” This provided good food for thought. Maybe if an inexperienced tester has stated they are finished testing on a particularly treacherous piece of software, the risk profile may be slightly higher than a more experienced tester had tested that piece of software.

Anne-Marie Charrett, along a similar line also suggested broadening the idea to the designers of the system. Particularly if the feature has had a turbulent history of being scrapped and rewritten.

With this feedback in mind, this component was renamed from “Developer-Component History” to “Team-Component History.” I am still playing around with ideas for how to most delicately tell the story of this component in my current team. Hopefully some of the intelligent folks out there can help me out 🙂

The next blog posts will address the last two components of this product risk model.