I presented this talk at the Association for Software Testing conference, CAST2016, in Vancouver, Canada in August 2016. This version is slightly updated for an online audience.
Change.org is the World’s largest petition website where people submit something they want to change, then gather the support of thousands of other people and as a result, quite often are able to see that change happen. Just this month in August, a petition to create a wheelchair friendly beach on the Gold Coast has been approved, last year a petition led to the bodies of soldiers killed in the Vietnam War be returned home to Australia from overseas and late last year another petition led to the removal of the Heart Foundation Tick on our food products after claims it was falsely labelling unhealthy food as healthy. Last year, in Canada, a petition led to the government accepting in 10,000 Syrian refugees.
These people saw something they wanted to change, and by doing something about it, were able to make the change happen. That’s what I want to talk about in this blog series, creating the change you want, in your work life by sharing my experience in creating changes in my work life.
I’ve been working as a software tester for 7 years at a place called Campaign Monitor. My job involves a mixture of writing automated solutions and testing and plenty of other miscellaneous bits and pieces as I imagine a lot of you would say about your work. I love problem solving which is something I get to do a lot of in my job and I love helping my team create awesome products through testing. You can find me on twitter at @pete_bartlett.
As I mentioned, I’ve been at my company for 7 years and as I look around my company, it seems I am an unusual case in sticking around in the same job for so long, particularly when not in a managerial role. And this seems to be the same at other companies too.
This graph of my company shows the number of years people in the Engineering department have worked at the company. A large proportion are under 3 years. Most people start to get bored or feel they aren’t learning any more after 1-2 years and feel they have to move on to something else. Perhaps you feel the same way in your current role, or have felt that in previous roles?
It doesn’t have to be that way! Why not create the change you want to see in the position you are in, and start growing again now? You know how painful it can be changing jobs. Searching through all the job adds, updating your resume, preparing for interviews and then once you find somewhere, you spend the first few weeks or months learning about the context of your new position. Several months go by and you probably haven’t really learnt anything new or had any growth, you’re just adapting to being in a new place. You can avoid all this and use the position you’re already in to create change and start to grow again.
I hope that this blog series inspires you how to do that.
In particular, over this blog series, we are going to look at influencing change using your reputation and relationships, challenging yourself through coaching and reflecting on the work you are doing and wish to be doing.
First, let’s start with reputation and relationships. In your workplace, I want you to think about a complex part of the product you work with, and then think about who you would go to if you had a question about it… Why did you pick that person? I can say pretty confidently you picked that person either because of their reputation or your relationship with them. Perhaps they have been with the company a long time and have shown time after time that they know what they’re talking about, so you trust them to be able to answer your question. Or, perhaps, they are someone you have a good relationship with, and that’s why you trust them to answer your question.
This trust goes beyond just bringing your questions to them, if they had a new idea for a different way to approach the problem you were facing, you would trust them and try it out right? That’s the benefit of having a good reputation and relationships right? When you hang around in a company for a while, you will start to build reputation and relationships, and you will start to become the person others come to and listen to. You can use this to your advantage. Use it to get others on board when you find new areas for growth and new challenges to take on, and it’s more likely that change will be acted upon.
Perhaps you want to learn a new programming language or learn about security testing or performance testing. If you can figure out the change you want to make, then the influence you have built up in the company will mean people are more likely to listen and agree to try it out.
Let me tell you some examples where I’ve done this.
Rewind 3 years at my company and as the 1 QA member in my product team, this is how our testing process looked. At a very simple level, the developers in the team would pick up a task, work on it until they thought it was finished and then i would test it. If I gave it the all clear, it went out to production, if not, it would go back to the developers to fix. Probably a scenario most of you know well.
So, I tested every task that our team worked on before it went out live to customers. This created a bottleneck in the testing stage of the product lifecycle, particularly if I was away. There was also a lot of back and forth with tasks as I found bugs and sent them back to the developers, then they sent them back to me to re-test, then i found something else and so on. We were creating great things, but it was inefficient, so I wanted to change this.
The first step was identifying this to the team, that we needed to do better, they trusted my opinion due to my reputation and relationships with those in the team, and they agreed to try my suggestions out and make it better together.
First change, I suggest we start doing test reviews. Before a developer commits their code and finish with it, I’ll come to their computer and get them to show me it working, I’ll ask questions, do some quick, happy-path testing with some simple variations to catch any immediate blockers and then they can commit it. Then if necessary I would do a more thorough test if needed on the committed code, knowing that I’ve already caught anything obvious, so it’s a much higher chance of not getting sent back to the developers. It’s a nicer way to work as well, the developers would feel annoyed if they had let a simple bug slip through that they should’ve picked up and there’s a sense of pride inherent with showing off the work you did, which gives me a nice way to commend the developers work as well.
This change took a little bit of time for the team to adjust to, as you would expect with any meaningful change. But we stuck it out and overall the reception to the change was great, it stopped a lot of the back and forth with bugs and so people were happy.
Second change, I say to the team, let’s add acceptance criteria to the tasks before you start work on them so you know exactly what you are trying to achieve and how to confirm it works yourself, without me needing to be involved. We use acceptance criteria as a simple checklist of things to test against as the developers were working to guide the way they verify their work and help them catch any issues while they are writing the code, rather than after.
Here’s a simple example of what I mean. The task being worked on might be a page for receiving credit card payments. So in the acceptance criteria, I could say, make sure you check for validation on the credit card input fields and make sure you have appropriate confirmation messaging for a successful payment. There’s definitely other areas that could be tested but those two points should inspire the developer to think through enough of the primary test cases to use for verifying their work without having to spell out every scenario for them.
Again, this was received really well, people had experienced the pain of me catching something at the test review they hadn’t thought of, and while this was still much better than me finding it hours or days later, it was still at the point where they thought they were done and ready to move on and they wanted to find these issues earlier. So knowing these things I would be looking for up front really helped.
So, not only is our team becoming more efficient, but I’ve been challenged to critically analyse product demo’s to catch issues as the developers were showing me their work, and improve in communicating clearly, as I helped provide acceptance criteria to the team for the tasks they were working on.
The other problem we were seeing was that I was a bottleneck as the only tester, so the third change was to shift that by allowing everyone in the team to help out with testing. Now, when a task was ready for testing, anyone in the team could pick it up and test it, to make sure it can work as expected and I no longer needed to have a hand in every task we worked on. Great! Of course this requires training in showing the developers how to test, what sort of things I look for, and still working with them up front to create acceptance criteria for the tasks. But it’s definitely a worthwhile investment.
With the whole team being involved in testing, tasks were getting finished quicker and getting into the hands of customers quicker which is a win for everyone. This change would take the most convincing to get the team on board and takes the longest to properly implement. We are doing well in this area now within my team after trying it for a few months, but there’s still improvements to be made. Some developers are strong believers in the “I code, you test” approach, but to the credit of my team, they were happy to give it a try, and call out for help when they needed it.
Through these changes, there was more learning for me, this time in teaching testing itself, and I find, the best way to get better at something or to master it is to know it well enough that you can effectively explain it to someone else. This is what is happening when you teach someone about testing, which I’ll touch on more in the next section.
My response to the scenario I found myself in was I changed my environment, I learnt new skills and I improved my existing skills by using my reputation and relationship within the team to create the change I wanted.
My challenge to you to take home with you for this section is to find an aspect of your job that you want to change, then, use your reputation and relationships to convince others that it’s a good change to make and guide them through it if needed, working through any hurdles that come along the way. You’ll soon find yourself with a new challenge, and new ways to grow, without the hassle of finding a new job.
This is part 1 of 3, Stay tuned for part 2 coming soon!