So I have been thinking quite a bit recently about testing in situations where things aren't perfect. I have a 'creative project' potentially in the pipeline to talk about this more but whilst that is still in it's embryonic stage I wanted to shove something out into the world.
Before I continue I wanted to start by saying that I believe that everyone is entitled to their own opinion about what makes a Tester an 'Agile Tester.' With that said, for the purposes of this post, let's all just agree that my definition is what we're working from. Largely because otherwise it gets complicated, and also because I'm right.
I believe that practising 'Agile Testing' means interrogating the solution all the way along its journey. From before the code exists. Probably from before the description of what someone first thought the problem was in fact. In order to do this you want to be part of a strong development team which works collaboratively. I love being part of figuring out what a solution is with a team and testing it all the way from the beginning up to the point where it goes live. (And beyond.) I enjoy exploring how things work and figuring out the nuances that make the software interesting. I'm a big supporter of the idea that a key part of a testers role is giving the team information about how the product works to enable decisions about whether that's what's desired or not.
A while back I worked on a team for a few months where I was testing how a solution integrated into a larger group of products. (Due to the structure and the nature of the project all of the statements I'm about to list were true. I promise you it wasn't realistic to change most of these things.) I hadn't really worked on any of the teams that make any of the products. This included the development team making the product which I was checking for integration. I was not invited to their sprint planning and I was not invited to their retros or standups. I was testing the culmination of how two different teams worth of work fitted into a dozen other pre-existing products, each with their own teams. And I didn't really belong to any of these teams. I didn't have defined stories to test or a clear way of getting things fixed when I found problems. So obviously I had stopped being an 'Agile Tester.'
Except had I? There was a project standup daily with representatives from the business side and some technical leads from some of the products. So that helped propel things forward and I had a voice in that meeting where I would feed back what I had been working on, discuss what I was planning to do next and get my blockers off my chest to see if anyone could help me resolve them.
I was not working to any tickets and that was hard because it required self discipline not to get lost in rabbit holes. But I was constantly exploring new things and investigating what was happening in comparison with what I was expecting to happen. Because of this I was questioning my expectations constantly. In fact, in many occasions we were lacking convincing oracles so I was hunting them out and assessing them for their trustworthiness. This part was frustrating at some times but also had moments when it was very fulfilling. If testing is about learning how things work when no-one knows, boy was I learning about how things worked.
I would meet regularly with the product owner to discuss his priorities and he would steer me in the direction of what he wanted me to learn about. Generally it was "Can you check whether part A works?" But he and I both understood that we didn't really know what 'part A works' meant so a large part of what he was asking me to do was go learn about something and give him information and context so he could assess whether he was happy with what was happening.
If I found issues I didn't have a dedicated development team round me to fix them. What I did do was discuss these with the product owner regularly so we could prioritise the ones that would derail the release schedule and figure out what teams we needed to talk to in order to get things resolved.
Frequently I would then coordinate with other developers and testers in other teams to come up with solutions to problems and help manage them into reality. I would sometimes test the changes in isolation on the system where the fix was being applied or how it integrated with the software I was primarily concerned about.
So this role I was doing was a little frustrating and to begin with I was concerned that I was just being a quality gate at the end before it went out. To a certain extent maybe that was true. And for that part I had become the kind of tester I don't like being.
On the other hand I was working very closely with the product owner. I was constantly exploring new things and I was being pushed to interact with lots of different teams. That project caused me to build relationships with people in a number of different teams within the organisation. These relationships have proven to help me greatly with other things I've worked on since.
But was it Agile Testing? Maybe not. But not all situations are perfect. When I started to embrace what I was doing, particularly the elements of it that felt true to how I think about testing I started to enjoy what I was doing more. It is quite easy to get wrapped up in all the things in your situation which are not good practice and that can lead to thinking that you're not really a modern thinking tester. Obsessing over all the things in your project or company which don't fit your idea of good software development culture can encourage you to compare yourself with people you follow on twitter or blogs you read or speakers you see at conferences who seem to be doing "real testing". Comparing yourself to these people can make you conclude that you're a fraud. It may cause you to get angry at everyone around you and try and solve all the problems at once. Because after all, they are making you betray our core principles of what you believe testing should be.
It's worth remembering that when people tell you a story they provide the evidence to support their narrative and miss out the facts that muddy up the details. Those testers who appear to have ideal companies and fully supportive, testing-enlightened teams are likely to be doing similar things you're doing and making similar compromises you're making, but it doesn't fit the narrative they're telling. So maybe don't judge your reality against other people's stories.
Finally, I'll repeat what I mentioned before. Embrace the parts you enjoy and that you think fit with how you want to work. Sure, try to improve your situation but try being realistic about what you can achieve with the level of power you have and the resources you have available to you. And lastly, don't beat yourselves up if you don't think you're doing perfect Agile testing. I'd bet you that no one is really.
From what I've seen in different roles and through talking to other people and following their blogs, "Agile" means different things to different organisations; sometimes it means different things at different times in the same organisation.
ReplyDelete"Agile" is one tool that you can bring to bear on a project or a problem. Other tools are available, as they say.
And in any case, you were using parts of the Agile Manifesto; just not perhaps the ones you were expecting. You were participating in the daily standup, only at a different level and with different participants to those you'd normally expect. And you were engaging with the product owner in a way you found really helpful. There's that bit in the Agile Manifesto about individuals and interaction before processes and tools; isn't that what you were doing?
In fact, it's worth remembering that the Agile Manifesto applies to the Agile Manifesto! It can, after all, be viewed as a process or tool. Applying Agile too strictly can defeat its objectives.