Next, I want to talk about coaching. I mentioned in the previous post that the best way to master something is to learn it well enough that you can effectively explain it to someone else.
Have you ever tried explaining something to a toddler?
You: “Don’t kick the ball in the house”, Toddler: “Why?”, Y: “Because you might break something”, T: “but Why?”, Y:“because you might hit a vase and make it fall down and break”, T: “so?”, Y: “so your mum would be upset if the vase broke”, T: “why?”, Y: “because she likes it”, T: “why”, Y: “I don’t know”, T: “why not” …
You get the point, when you try to explain something, people tend to ask why, which can really stretch your understanding and beliefs. You’ve developed a set of assumptions that the way you do things now is the best way to do it, or that it’s too hard to change. You teach this message to someone else, but they don’t agree, they might say, ‘Why don’t you try writing a program to do that for you?’ … Perhaps you’ll be pleasantly surprised and discover a new solution that works better and say: I hadn’t thought of that, or I don’t know how to do that. Or in other words, that sounds like something I need to change, something new for me to learn. Great!
As you spend time coaching someone, you are being tested each day to deeply understand what you are teaching as you explain it to someone else. It’s a great way to find out if you’ve thought of all the different options or to cement your knowledge.
In a sport’s team, it’s the coach’s job to help show people where they need to improve, and guide them through how to improve. A coach within testing works the same way, pointing out areas for growth, and assisting through the growth. Having someone coach you in testing is quite beneficial for you in helping to identify your weak spots and help you develop a plan to get better. Perhaps the areas of your role that you’ve always stayed clear of will become a little less intimidating, or you are challenged to approach a situation differently. Either way, there are changes for you to make, challenges to take on and new growth to be found.
Here’s some examples where I’ve tried this. The first one is actually the reason I’m presenting this series. I have a mentor, Katrina Clokie, who I was connected with through the SpeakEasy mentoring program who has been mentoring me in how to write a talk to
present at a conference. Just over a year ago, we started connecting via fortnightly skype sessions, discussing what I would need to do in order to speak at a conference. Starting from fine tuning ideas, to learning how to communicate these ideas into an abstract and right through to actually putting the talk together and creating slides. I knew something about these skills previously, but definitely learnt a lot from her guidance.
I learnt how to assess what ideas were worth sharing. I learnt about having a target audience in mind when writing so that the content can be more intentional and actionable. And I learnt about how to communicate my ideas. If you are interested in speaking at conferences, I definitely recommend reaching out to SpeakEasy to get yourself a mentor.
From the viewpoint of being the coach, I’ve found my skills and understanding of writing automated testing solutions have really been challenged when I try to explain my test approaches to my workmates and explain how and why I’ve made the choices I did. Solutions I thought were quite clever and effective or just the only way to do things were challenged as i explained and presented them. I’ve been challenged to investigate whole new technologies and code structures to get a better solution which of course means stepping away from my comfort zone and trying new things which means areas for growth.
I’ve learnt a lot about re-using code, readability of code, maintainability, and much more from the feedback of others as I’ve tried to coach them in the way I’ve written my automated solutions.
The other main source of learning I’ve had from others coaching me is actually indirect coaching through attending conferences, going on training courses and reading blogs. These are all great ways to indirectly have other people coach you as they share their knowledge to a group. There are hundreds of testing blogs, several testing conferences and training courses that are worth going to and provide great opportunities to learn. Which of course, you already know because that’s why you are reading this blog! Keep using these opportunities all around you.
I’ve also experienced this side for learning as the coach as I’ve shared some of my learnings on this blog and had hundreds of people from all over the world read my posts to learn from me. It’s amazing how many people from so many countries want to learn about testing. Communicating my ideas well is certainly an area requiring constant improvement for me.
So the take home challenge for this section is probably pretty easy to guess. Find someone you can coach in a skill you are familiar with so they can challenge you and push you to really master it. And going the other way, find someone who can coach you to teach you new skills, whether someone in your company or perhaps in a local meetup, or if needed even indirectly via the internet. Having someone to coach you means they can teach you new skills that they have and challenge you to grow in different areas.
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.
The reason you need to read this blog series
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.
The areas I’ll be addressing
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.
Reputation and relationships
What it means
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!