So I’ve been doing a lot of exercises and reading around leadership – not to become a team lead or change roles or whatever, but because I want to be a good advisor, mentor and advocate for quality in my company.
I started with The Leadership Journey by Jim Holmes, mainly because he offered TestBash-goers a free copy and I enjoyed his talk. You can buy it here, and I’d recommend it for what my word is worth. It’s all practical advice which I think anyone moving into leadership would find useful and enlightening. I’ve also started reading Slack by Tom DeMarco, and plan on moving on to Peopleware by the same author next. Oh, and I want to work through this hefty reading list from The Club – What 3 testing books would you recommend to a tester? But there’s only so many hours in the week for reading, and I am still battling my way through the Wheel of Time series as well.
Anyway! One of the actions/realisations that came from this was that if I want to do more leading then I need to do more leading. I’ve had a lot of responsibility, don’t get me wrong. I am the gatekeeper of releases, the person who clicks the Deploy button after balancing the risks against client pressures. I have pushed for testability the entire time I’ve been a tester – if it can’t be demonstrated to be working, then I assume it’s not until it can. xD The problem with being the keeper of releases and the one true source of quality, is that you become the person who gets asked to make all the decisions about those things.
I often feel like people who know more than me are asking me to make decisions based on a quarter of the information they have, in the moment. During mini-refinement sessions I’m asked if I have anything to add to tickets I’ve never seen before while under a time restriction. In the meantime, I’m also thinking about the tickets I’m already testing, the ones that are ready for release and what regression testing or bug fixing needs doing before that can happen, as well as how I need to move forwards with automation, and encouraging the team to take a quality-first mentality with the tickets that are upcoming – and trying to get my learning objectives complete (hahahah…), and actions from being in the diversity and inclusivity group trying to sort out the company from that standpoint.
I have felt overwhelmed almost daily, and it led to low productivity at times because I was being thrown about in this cyclone of changing activities and just couldn’t get my feet back on the ground. There were too many things to think about, too many decisions to make and not enough time or knowledge to deliberate on any of them. I felt that I was failing on all fronts because I couldn’t give my all to any of them.
Getting the Team Involved
After speaking to the team lead, we decided that I should facilitate a workshop with the team to come up with ideas for what we need to do next to improve the quality of our product. The purpose was to get everyone in the team onboard by creating a team vision and open up the decision making process to everyone.
One of the actions that came from the previous retro was that our meeting invites never had agendas attached, so people were always coming in blind and being asked questions they hadn’t had time to think about beforehand – like me in the mini-refinements. So I set an agenda with a couple of ideas and questions, and set reminders in one of the slack channels for the day before and the morning of the meeting.
You know I love me some Miro for remote meetings. I’m a very visual based person when it comes to learning and sharing information, so it’s just the perfect tool for everything I ever want to do. I also have a tendency to use garish Saitama colours because he’s the best hero…
I made a frame on the team Miro board, using the typical Saitama yellow, red and white. Although these colours are rather alarming, your typical everything-is-on-fire yellow and red alert, I chose them because they are calming for me, and they remind me that I can stay in control and overcome the obstacle of trying to let everyone be heard while navigating the group towards a concensus on a topic I care about. I will defeat this meeting in one punch!
What a beauty, am I right?
The first part is an open suggestions box – what should we be working on re testing and general quality things? Tool suggestions, areas we should be covering more. The format is based loosely on the idea of a lean coffee, where a bunch of ideas are suggested and described briefly, and then everyone votes on the issues we want to talk about more. To ensure that we kept within the one hour time limit, I then created a section for the top three ideas. Not the top five if some get similar vote counts, not the top ten because we just can’t not talk about them all… The top three, end of. I can be pretty harsh, I guess. I was also pretty heartless in cutting discussions that were getting out of hand, going too far into implementation details for things we hadn’t decided whether we wanted to do or not yet.
Here are the ideas brought up by the team after five minutes. We grouped them up into categories of similar items:
Top left was behaviour related things, top right API testing, bottom right tasks around the Visual Regression Tests, bottom left was mock data for test and dev. Then there’s some misc ones, eg a centralised testing tool and feature flagging.
We went through each, just having a short conversation to describe what was meant by each of these so that everyone was on the same page, and we had three votes each lean-coffee style. Obviously using our faces as voting tokens.
One of the questions I had in mind when coming into the meeting was whether or not it would be worth taking the visual regression tests I implemented before, and remake them to be cross-browser. The current tests run in Puppeteer, which uses headless Chrome. Most of our manual testing occurs on Mac Chrome as well.
The problem with that is that we don’t actually serve all that many ads on the Mac OS – only 700k ad views from the last 7 days, compared to just under 8million for Android phones, 5million for iOS or 4.5million for desktop Windows (including 5 views on Windows95, somehow…) The bulk of our testing happens on devices fewer than 5% of the people who see our ads actually use. That’s not to say we don’t test other devices at all, because I do so regularly as part of both testing new components/configs, and as part of my usual regression activities. But outside of those times, I never see our ads on other devices or browsers in my day to day activities.
We didn’t have this exact information at the time, since this data comes from me querying our analytics database since the meeting, to decide which browsers and devices we should test with. I downloaded the query results as a csv file, then used Rawgraphs to create the graphical representation. I’m not a cool data scientist person, so no special cool charts for you, just a barely legible donut with atrocious colour choices.
Despite not knowing the exact numbers, we all knew most of our ad views come from mobile devices so almost everyone voted for cross-browser VRTs. The other most voted for issues were mock data and API testing. It was pretty concentrated around those three issues, making it easy to decide which three should move across, luckily. Well, we cheated a bit on the last one, but you know…
After deciding on the top three avenues we wanted to go down as a team, we spent a few minutes making some actions and notes around them. I think I could have done more at this point to keep the discussions tight and people engaged, as it seemed like minds had started to wander by the end of the meeting. Hence the post-it simply stating “Do the thing”.
See the entire ending board below. You can see we did add a few actions above the frame that we thought were quick wins that didn’t need much planning, or things that we are doing anyway without any further action required:
We’ve been trying to implement Behaviour Driven Development as part of a new UI we’re making, so two of the three are related to that. The third relates to mock data somewhat, but is easier to muck about with.
For a first try at this type of workshop meeting thing, I think it was a success. The feedback was good, although it’s hard to know if people are just being quiet about their criticism to protect feelings and my self-worth.
This should be the last post about a meeting, because who wants to read that, but I think it was really important for two reasons – it’s the start of me trying to facilitate more discussion between test and dev in a more structured way than I have been before, and it’s simply a good discussion to have with the team. It was really useful finding out what everyone thought should be our next steps, both to help directly with decisions I was stuck on, and to bring new ideas to the table that I had been blind to.
I’ve since been working on integrating cross-browser visual regression tests. I don’t think they’re quite there yet, and I’ve tried out multiple open-source packages to help. I hope my next post will be about the process of finding the right one for us.
Undeveloped Bruce 