Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.
How do I as a tester deliver customer value? And what can I do to increase that? Today’s challenge is no small topic to tackle. Sometimes it can feel like the work that we do day to day is disconnected from our customers. Sure, we are always trying to think of them when testing and tie our work and issues found back to them, but at the end of the day (in our company at least) we don’t have direct access to them. So how do we go about delivering customer value?
Well, what do our customers want? They want software that helps them solve the problems that are trying to solve and that creates value for them. To over simplify it, what our customers want is working software. As a tester there are many things that I can do to add value into that process. I can explore the software to find out things that might threaten it’s value proposition to our customers. I can also consider how to help get the software out the door more quickly – after all our customers aren’t interested in potential features, they want working software. I can also work on establishing better team dynamics and practices that help us get more efficient at producing valuable features. I can learn about what our customers actually do with out software. I can do many, many different things that can all add value for our customers.
Let’s take this out of the theoretical realm though. How can I specifically in the particular context I am in right now increase my value add?
One of the projects I am involved in is a longer term ‘replacement’ project and when looking at something that has probably a year or more of development work before getting released there are a lot of challenges. One of the ways I can really add value to the project is in helping the team to more quickly produce working software. What I mean by working here isn’t something we would ship to customers, but something we can share with other testers and managers. Something that will let us better establish where we are at as a team and where we need to go.
I am convinced that by having this we will be able to (a) figure out what the minimum shippable feature set is more quickly, (b) improve our ability to understand how close we are to that (c) keep the code health better due to improved feedback along the way and (d) ultimately complete the project to an adequate level more quickly. To take this down to the brass tacks level, working with my team on getting a build pipeline in place is actually one of the best ways for me to add customer value in my current context. The line from my actions to the customer is long and wiggly, but when you’re a tester you need to think of the big picture. These kinds of things matter for our customers.
offbeattesting 