Okay, a few things before we get started:
I am going to be at the pre- and post- testbash meetups, come at me testing folks!
I will be bringing my mic along to testbash, if people want to be on the show! I can do full interviews or shorter vox-pop style segments, so hit me up if you want in on it! I’m also talking to Mark Tomlinson and others regarding a podcast mashup, so I’ll keep you upto date on things in the works there!
I finally got selenium (both webdriver and IDE) installed, so going to start playing around with that and get started on my 2016 goal of getting some automation under my belt. I’m armed with some resources from Richard Bradshaw12 and I am ready to go!
And now, on to the show!
At the moment I’m doing some brief preparation to have a couple of apprentice developers shadow me for a while as part of their training. It’s hard to know what to show them, and I want to make sure that I’ve got both planning and testing work I can do to show them the breadth of work the QA/test team do, and this will give them an overview of how we use jira.
But they’re very new to all this stuff, so I want to make this more broadly useful for them – not just showing them what I do and what tools I use, but how and why, and therefore help them to become good developers who do some of this themselves and also understand the worth of QA/test beyond breaking shit. Though I will also show them how I apply the knowledge I have to the system to try and break it.
My first port of call was Katrina’s pathway for non testers3. I’ll send this link to the department head in charge of their training, but for my session, I’ll use two or three specific parts, depending on how much time I have/how long we spend discussing these ideas.
The first thing I want to use is a blog post around the concept of testing being a team responsibility1. At our place, the devs own the automated checks – they add acceptance checks (based on AC) for all stories, and run those before it comes to me. If they don’t pass, they fix, then it’s ready for me to test. This means there are very few circumstances where I reject a story based on AC – either something has been missed because people are human after all, or there’s something in the AC that is 1) too complex to write automated checks for or 2) the automated checks can’t cover (visual stuff, or really custom things).
This means that the devs have some ownership and investment in their code and the tests.
The next thing I’m going to use is a pdf that covers sources for test ideas5, because ‘where do you even start testing?’ is something I’ve heard. This document is a list of things to consider when starting testing a feature, and covers everything from the obvious (the capabilities and purpose of the system) to the more obscure (rumours around what’s causing the dev team issues, domain knowledge etc).
This will also help explain why I’m involved in planning sessions, and scrums that have no relevance to me – the first few scrums of a sprint I have nothing constructive to add, more often than not, because it’s rare stories have come to me by then. But I’m still part of a team, and I’m still involved, and I learn a lot. Knowing what’s causing devs issues means I know what work might need extra testing, and may be risky. Its both a way for me to plan my work based on when I’m told to expect to get stuff sent to me, and recon for what I might face come testing.
The last thing I want to talk to them about is about testing in an agile environment6, which is useful, I think to all members of an agile team, especially for people new to agile. It covers how agile applies to a tester specifically, but the idea of agile is to promote team cross-functionality, and so knowing this stuff is useful. Its also good to know what to expect from working with testers outside of bugs, like being proxies for stakeholders and users, which will be useful.
I don’t think I’ll get through all of it, and it may be slightly overwhelming, but I’m hoping it will be mostly useful, and I can give them resources to learn from and help them become good developers, and that’s what we’re here for.
I think that’s a decent enough intro for people who aren’t testers and presumably have little interest in becoming testers, but I’d be interesting in hearing what people with more experience of this kind of thing think. Do you teach people differently? Have I missed anything?