Building a Tester Community of Practice

I know, I know. It's been a while since my last blog post. But it's going to be a good one, promise, I've been saving up for it.

Last time we talked a little bit about the trouble we'd been having with our QA practice, as in, there wasn't one. We were missing the halcion days of having a Practice lead who did everything for us. In short, we were feeling sorry for ourselves.

Over the past 4 weeks, we've been trying something new and although it doesn't solve all the issues we raised during our marathon QA Retro-flective, it has gone a long way to making us feel like a community again.

It started with a Community of Practice for a Community of Practice (INCEPTION!).

You see, part of the problem with how we were doing things was this old idea of supporting each other. Now, we all like to support each other, but we were expecting that to extend to spending time every 2 weeks potentially doing something that was of zero interest to you. That's a hard ask for someone who's busy trying to get team work done. No one minded spending the time, they minded spending it doing something that wasn't for them.

Enter the Community of Practice.

We decided that no matter how we did it in the old way, someone was missing out. That wasn't necessarily the problem though, the problem was expectations. Expecting 30 testers to show up and getting 5 is disheartening. But what if you knew that it was going to be 5? And you were all passionate about your topic and ready to get talking? Or doing? That's a different feeling right?

You see, a community is based around a participation model.

1. At the center you have your core members, they're the ones actively involved with the doing. They're organising talks and meetings, workshops, whatever is needed.
2. Then you have the active members, these are your regulars, always willing and wanting to attend.
3. Next are the occasionals, they drop in and out depending on a wide range of factors including interest.
4. Then you have the peripherals, they're not really interested in participating but may pop in to see how it's going.

It's important to note that people move in and out of circles as time goes by. A Core member may need time off and turn into a active member. A Peripheral may become more engaged and move into the occasional. The point of a CoP is that everything is fine, anything goes as long as people are interested.

So our mini CoP group got together and discuss all of the above and how we would get others involved in this idea, what would failure look like? What would success look like? What did we want people to take away.
We arrived at the idea of a 4 week trial, every Friday we would put two hours aside to be used as people wanted. Three weeks were to be spent with trialing the actual community and the 4th would be for a review (at the pub) to discuss if we wanted to keep going.
We would keep a trello board and anyone would add ideas they wanted to talk about that week. Everyone would vote for topics they wanted to see and one person would act as champion of that topic and basically just organise everyone in that group. Without a champion, no matter how many people vote, a topic wouldn't go a head. A champion didn't need to organise a talk or slides or anything, they could just be a facilitator if they wanted. Talks lasted as long as the groups liked. The idea was that if something needed 5 minutes, that's what it would get. Other conversations may need the full 2 hours.

One topic only had 2 people, they went off and had a great time talking about it. Another had 13 people. The point was that everyone was going where they saw value.

I'm not going to lie, I was pretty surprised by the response we got to this. It went really well. People loved it. We quickly saw the core and active members emerge and even the makings of an occassional. It was pretty awesome to watch people just put themselves forwards to be champions (that was honestly the biggest fear, we'd made a rule that those of us in the mini CoP wouldn't act as champions during the trial period).

We've now had our pub review and the consensus is a resounding "Keep Going!" So we're already setup to keep going next year after the break.

It's been wonderful to watch my fellow testers just pull themselves back together, and all it needed was a few people to get an idea going. It's been a tough year for us, but things are really starting to look up, and I'm glad we got to finish on such a high note.

Happy Holidays nerds!


P.S. I hope you've all gone to see Rogue One already. If you haven't, go, go now. Stop reading and go. Star Wars is more important.

Shaking your Agile self to a better testing community.

Well, it's been a shaky few days here (quite literally) not to mention the flooding and gale force winds that apparently come along with an earthquake now-a-days. But we're on the up and up again!

<3

Our testers have just done something super agile together in the past few weeks. We've all been feeling a bit down after some big structural changes that have left us without the single point of leadership that we're used to. After months of this, we decided to get together and work something out once and for all, do we actually need a named lead? Or were we relying on them for things we can do ourselves?

Agile to the rescue!

In a fit of inspiration (*cough* and with the help of one of our Agile coaches), we decided it was time to have a QA Retro to actually talk about how we're all feeling and what we want the future to look like.

We used post-it's to write our points down beforehand, then one by one we put them up on the board, then silently grouped them into topic areas.

One of the things that really struck us is that we all had some very similar concerns about how things were going. With that done, we moved to the lean coffee format and timed a discussion on each topic group. Now came the fun bit. We talked, and I mean really talked, with a no interruptions rule and a mindfulness on if you were contributing perhaps a bit too much (so that other's get a chance to talk too).  Most importantly, this wasn't about solutions, solutions were forbidden.

We worked a lot of stuff out, the most important though, was that we could be doing a lot of things that we had been relying on a QA lead for. Our sense of community and learning, career progression, internal and external tester perceptions, all these were things that we could tackle ourselves. In fact, these were things that in hindsight it seems strange to rely on someone else for. No one can make you have a community, no one can make you learn. These are things we need to push for ourselves.

We did see that we definitely needed someone to represent testers and testing at higher levels, but that person didn't need to be a "lead", just someone with our interests at heart.

We all left our retro feeling a mixture of hopefulness, optimism and apprehension. It's an easy kind of thing to forget about, well, doing anything about. But all you really need is a few really passionate people to push these things forwards. Luckily we have those passionate people who are willing to take the time to put some ideas together.

Agile can be used for so much more than just pod level things, and never be afraid to just get everyone in a room to talk through things. We forget that we're not alone when things are feeling a bit down, it's so easy to just retreat into yourself and your own work, never realising that there are many others who are feeling the same way and that together, you can really make some changes.

Have a great week nerds!
Helena<3

Why you need to market testing and yourself.

I remember the very first time I found out that testers weren't always seen as the valuable people that I always thought them to be. As someone who started in support, testers were my buddies. They would help me find problems, and put them to developers who would fix them for us and our customers. I spent a lot of time talking and interacting with testers, which is probably a big part of why I ended up here.

But alas, the rose-coloured glasses had to be slapped off my face at some point. It was maybe four months into my new testing career that I read the fatal words. On Facebook no less, ouch. A developer friend of mine started what no doubt was an innocent and wide-eyed-fun thread about the worst things in development. "Javascript!" went one, poor Javascript. "The customers!" went another, har har, they're always getting in the way, those crazy customers.

Then it happened, "F&$*%ing testers!" went the next. My heart started beating faster and I just stared at my screen. "Why?" I thought. "What have I ever done to you?", my mind made it very personal, very quickly. It didn't matter to me that maybe this guy had just come across a tester who may have been a bit of a douche, he'd just put us all in the same sweary basket. There's no way this dev takes his tester or the work they do seriously. I wrote a detailed, long response reprimanding this developer, which I stared at for about 5 minutes, then deleted. I find that sort of thing cathartic, I don't actually need to post things to get them off my chest.

But this kind of anger is something that no doubt a lot of us have to deal with. The perception that testers are there to literally ruin your day. For those of us who don't experience out-right hostility, what we deal with is a little more insidious. We deal with apathy and a general lack of understanding of what we do. The two things kind of go hand in hand.

I work in a great team, full of great people, who care about the quality of their work. I asked them a little while ago, just at a stand up, what they thought I did. Everyone stared around a bit, looked a bit awkward, then one hazarded a guess of "You...test...things?." Huh. I guess she was sort of right, but I've always thought I was doing my job wrong if I was spending more than maybe 15% of my time physically testing something. What did they think I did with the rest of my time? Did they think I was just sitting there shopping online? Well, to be honest, yes, but I have 3 screens and I'm great at switching my focus between them.

After my little pop-quiz though, I started to ask around. I know my team is pretty up there when it comes to what I'm going to call "enlightened individuals". For some of the other testers, it was even worse. Not only did no one know what they did beyond the physical act of testing, but a lot told me that they weren't even expected to do anymore. Instead of Agile, they were working in mini-waterfall, and the cracks showed. More roll-backs than you'd think was alright and testers who felt dismissed, under-appreciated and just generally sad. Not only does this lead to poor software, it leads to retention problems. You can lose some great people because of a lack of care.

So something needed to change, we needed to start marketing ourselves. We need not just our teams to care about quality and testing, we needed our CEO, our managers, everyone, to get involved. And it's started with something that Kate Falanga of the previously ironically named Huge Inc (it's not ironic anymore, they really are huge), gave us a head start with when she took us through her "Teaching testing to non-testers" workshop.

Getting everyone involved in what testing really is means that they start to understand, and with understanding comes care and enthusiasm. Re-engage your testers by re-engaging everyone with testing. You need to market who we are and what we do, or else we remain that other thing that's always raining on everyone's parade.


P.S - Did anyone watch BlizzCon? Oh my nerd, the recreation of D1 in D3 may be my favourite thing this year. It may not be a Warcraft 4, but it'll tide me over ^_^

On automation and learning the hard way

I promised we’d talk about automation, and don’t worry, we’ll get into some of the nitty gritty stuff soon enough, but this is mostly the second half of my origin story. That’s right, in my head I’m basically a superhero, I’m also dressed as Harley Quinn as I write this, so be prepared for some comic references.

Automation was pretty damn new when I started testing a few years ago, in fact, our framework had only been in existence for around 6 months and all the people (all 6 of them) working on it were previously manual testers who’d been doing some Pluralsight courses on C# and Selenium. This was the big change time, manual testing was out, and we really needed to get up to speed on this automation business. Regression was taking around 2 weeks and anyone can see that that’s just not sustainable. At least, not when you’re releasing every 3 weeks. So we all went hard out.

While at the beginning, as we talked about last time, I had no real clue what to do with the manual side of testing, the automation side came to me quite easily. I may not have coded before (well, except for a Fairy website that I setup using html on geocities when I was about 13), but I was technical, coding made sense. We were still learning how to put it all together in a way that worked for automated testing (and by that I mean learning the hard way that you can’t code everything), but we were getting good at it. At least that’s what we thought at the time.

If anyone here has ever coded before, in any language, you already know what I learned. That looking back at code that you wrote 3 months ago, that you were really proud of at the time, is a pretty humbling experience. “Ouch” was the most often heard thing in my head whenever I needed to go back and fix something.

There are two main lessons I’ve learned about automated testing over my testing time (ha! "my testing time" - just call me old man Helena).

The first is that when you focus either entirely on automation or entirely on manual, you’ll fail. There is a time and place for both, there must be balance to the force (I know, I know. It’s not a comic reference, but meh, this is my blog and I’ll do what I want!). We dropped all focus on manual testing when we moved to automation, and we lost something important because of it, we lost the humanity in our testing. Equally, we wouldn’t be where we are now (using a Continuous Integration release process) without all the effort we put into automation. It was hard at the time, and it’s painful to look back on, but we needed to do what we did. We’re aware now though, and we’re redressing the balance. That’s all you can hope for.

The second big lesson was that automation isn’t a second class coding citizen. It’s not the Marvel Squadron Supreme to the DC Justice League (got one!). Automation is coding, it’s proper, normal coding, the same theories and standards apply as usual. One of our biggest challenges was getting Developer help with our automation. We should have asked for it sooner, we should have pushed for it sooner. For every dev that said to me“Oh, I don’t know how automation works” was one who said “It’s just normal code, here, let me show you.” We’d been learning from online courses, they had years of experience. Eventually that experience became our savior, our Framework is in pretty good nick all things considered. Nowadays we even have dev college graduates do a Testing rotation, where they do both automation and manual testing. It took time to get to this mindset though.

So that’s the high level overview of my origin story. I may not be an actual superhero (or to be more honest, a super villain) but everyone deserves an origin ^_^

Happy Halloween little nerds!
Helena <3

Le Gasp! Our first blog - On beginnings and passion

When thinking of where, when or how to even start a blog, I ended up exactly where countless famous books have started. In the beginning...

I was tech support. I liked it too. I enjoyed working out what was going wrong somewhere and helping someone get it working again. It was great when it was great, and it was hell when it was bad. A few years ago I asked to move to QA. Now, being tech support I vaguely understood what QA (or Testers) did, and it seemed appealing. Just find the stuff I was finding anyway right? But before the customer? I know what you're all thinking now. WRONG. But actually, I was kind of right. When they let me move over to QA, no one really knew what to tell me. I was given bugs to check in Jira and I checked that those bugs had been fixed, then I handed the Jira back with a yay or nay. No one told me to do otherwise, and honestly, I'm not sure anyone else was doing anything different. Well, there were a few super experts who got asked their opinion on everything, but mostly everyone seemed to check bugs, and automation.

Oh man, automation was new and I was suppose to teach myself C# (I did) and learn automation (I did that too), but that's another story for another day.

Mostly my first months as a tester were spent watching youtube, and believe me, I wasn't happy about it. It kinda sucked. Occasionally my team would remember I was there and I'd get a bug to test, but honestly I wondered if I'd made a huge mistake. Maybe I should go back to Tech Support? At least I was useful over there. Was this all there was to testing?

It turned out the answer was two fold. For some people, that's really what testing is. You have super specific test cases and you just see if they're a pass or fail. For others though, testing was this massive thing that could make or break your product/software. There were testers out there who did BA, UX, Dev, automation. People who really care about the output of their teams and who through their passion, get others to care about those things too. I never would have turned into one of the second lot of testers if it hadn't been for a new wide-eyed team lead who started maybe 4 months after I moved to testing. She cared. She really cared, and because she did, I started to care too. Suddenly I'm starting to look into what exploratory testing really is (I was doing it well wrong), how testers can guide the team without doing every tiny bit of testing and checking that needs to be done. Did you know there's a whole world of tools and discussion out there about testing? 2 years ago me didn't, but boy did she learn.

It's interesting to think that without the addition of my new Team Lead, I might never have stayed or learned about what testing really is. I might not have tried my hand at public speaking at WeTest this year, and I might not be writing this blog.

All it takes is a spark to ignite passion in someone, and even though it took a bit more time and work over the next 2 years to get where I am now (with a fair few tantrums and almost giving it all up), I'm glad it worked out the way it did. Otherwise, I might never know otherwise.

Helena <3