This time last year, I was invited to move from my customer-facing tech support role to my current testing one. A lot has changed in the last year, and my role, knowledge and experiences have really grown in what feels like a very short, yet action-packed, period of time. Working in a small business, I was very much “thrown in at the deep end”, and this has allowed (or forced?) me to learn fast.
I wanted to reflect on how my thoughts around testing have evolved during the last year. Perhaps it would be interesting to other testers early in their career, those considering a career in testing, or hiring managers / trainers working with the former two.
Failure
When I was first asked to take on testing, I was really excited. As a user and consumer, I’ve always been big on quality and UX, and I love to find out how things work. But I was also nervous. What if I missed a high or critical bug? Moving from a tech support role, I was already fully aware of the impact that bugs in production can have – and how users react to them. The thought of missing something was a scary one, but one I was prepared to face.
One year on, and it hasn’t been too bad at all. There have, of course, been some things I’ve missed but nothing major that I can think of. To be honest, I’m a little disappointed about that. I’ve gone from not wanting to “mess up” to understanding that failure can teach us important lessons, and almost feeling like I’ve missed out by not having bigger failures. When I see Twitter threads of people sharing stories about the worst bug they ever missed, or issue they accidentally caused in production, I kind of envy them and wish I had a story like that of my own to tell. At the same time, I know from experience that dealing with the backlash of such things isn’t fun, so maybe the grass is always greener.
Now, I find myself in the odd position of trying to be comfortable enough to let other people fail, in order to let them learn. As a tester, I’m acting as a “look out” and making decisions based on risk assessments. This means that if I see a colleague about to smash head-first in to a big issue, my gut reaction is to prevent that collision. However, I’ve come to find that too many interventions like this are exactly how testers become the “safety net”, and people learn to no longer look out for hazards themselves, or have no incentive to.
Like most of the things I want to get better at, it’s a tricky balancing act and an opportunity for me to learn as well. As a tester, I can’t stop looking out for these things, but as a team member and someone who wants to be supportive, I also need to spot the right times to allow others the space and trust to learn from their own experiences, not mine.
Learning
I’m currently the only tester of the current version, having taken over testing from the CEO. In the beginning, we had good intentions of how I might be “trained” on certain things, but this wasn’t really practical, given the busy schedule of a very hands-on CEO. In reality, I’d say about 90% of my learning has been on the job, independent, or done in my own time. That’s suited me perfectly well for a few reasons: I learn better by doing than reading or listening; my eyes get very sore if I spend too much time watching or reading from a screen; I like to experiment with my learning and follow the natural flow of curiosity; I’m passionate about testing.
Despite my comment about reading from a screen, I get most of my external information from articles written by other testers, and conversation threads on Twitter. Without someone asking, “How far have you gotten in the reading list?” or, “Have you looked at number x on the resource list?” I’m more relaxed and free to absorb information on my own terms. Sometimes, this still means my eyes get sore and I take an accidental nap, but at least I’m doing that at home and not at my desk.
I’ll create a page at some point with a list of resources that I find useful, but the site that sends me the most useful testing content most often is Software Testing Help. I highly recommend you sign up for updates and browse the archives. Their content is a good mixture from broad to specialised; beginner to advanced.
As I continued writing this section, I realised that it should really be a post of its own, so I won’t drill down on any other ways of learning just now. However, I will stress something to those also eager to learn…
You will never read all the articles, watch all the webinars, or listen to all the podcasts.
Don’t give yourself a hard time for not doing all the things you want to, and allow yourself some non-study time.
Documentation
Like most “agile shops”, we were very low on documentation when I took the testing reins, and I was tasked with putting together test documentation so that “anyone could walk in and start testing”.
It hurts me to even write those words now, but back then, it seemed like a perfectly reasonable request. That is, until I started doing it.
I promised that I would write about my experiences with documentation, and that post is still on the cards, but I’ll give you the gist for now. (Edit: read the post here) Essentially, I realised very quickly what a ridiculous idea it is to write documentation with that mentality or goal. I’ll skip the self-righteous explanation as to why and stick with the main facts, although I can’t promise the same for future posts.
Any documentation I wrote like that (based on a template one of our developers had come up with), I never used, ever. A step-by-step instruction manual on how to point and click a mouse is not useful to any competent tester, and anyone who thinks it is is kidding themselves. If your software is really that difficult to use, you have bigger problems than documentation. Even if I had this kind of instruction booklet on day one of testing, I wouldn’t have used it. It only wastes time.
Nevertheless, I persevered and experimented with different ways of recording these step-by-step instructions in a way that might adequately cover my many, many test cases, thinking maybe I just hadn’t found the right template yet. Pretty soon, I was without the luxury of time to waste on a task like that and abandoned it, instead going rogue and adopting my own “cheat sheet” format that’s created documentation which is actually useful. It only has five headings: Version / Environment, Feature, How It’s Supposed to Work, Don’t Forget to Test, Other Affected Areas. Now, I have a brief reference for the intended behaviour and a prompt list for things that are likely to catch us out – much more helpful, and quicker to create, maintain and use.
Automation
Like many others, I came in to testing with the perception that automation could solve many of the software testing world’s problems and, having already attended a Women in Programming group for about a year, was keen to see what was possible. I was told early on that if anyone was going to bring automation to the business’ testing practises, it’d be me. I was keen to start experimenting.
I don’t have a lot of experience with code, but after a few hours of digging (in my own time), I realised that automation was not going to solve all our problems. In fact, I’m still hard pushed to confidently suggest two things that it would solve for us. The main reasons aren’t even technical; it all comes down to change and resource.
The software I test is heavily influenced by client feedback, and we’re pushing to improve and release shiny new things every single week. This means that our automated tests would change every week too, if we ever had the resource to write them in the first place. We have less than twenty people in the company; eight of whom write production code and only one who tests (if you don’t count the CEO) – me. And testing is only part of what I do every week, when I’m not playing Product Owner or wearing various other hats, so my extra-curricular brush with coding and zero free hours are unlikely to be of any real help.
Who knows, maybe we’ll have the use and capacity for automating some test activities in the future, but that time is certainly not now, and I’m not sad about that. In fact, with so much hype and misunderstanding about automation, I’m almost resistant to it at this stage, as I see so many people belittling testing activities that are carried out by an actual, thinking human – how quaint!
No, the time for me to include automated tools in my testing is not now, but I’m open to that changing – only when the time is right. I’ve never been one to follow trends, and this is no different.
Community
When I first got in to testing, as a lone tester, I really did think I was by myself. There are so many groups and meet ups for developers, and I really struggled to find anything similar for testers. That was before I found Software Testing Club and Ministry of Testing. The BossBoss, Rosie Sherry, has done a wonderful job of creating a true community for testers, and we owe her a lot for that. Please do have a look at these if you haven’t already, and sign up for the newsletter for great resources from the around the community.
What I’ve also found is that testers hang out on Twitter! This was bad news for me initially, as I’ve never understood the craze around it and don’t have a personal account. But, wanting so much to be part of the testing community and have someone else to talk testing with, I joined in April. In all honesty, it’s been fantastic. I’ve learned so much and had really interesting conversations with the people there, as well as receiving lots of support from people I’d never met before. If you’re resistant like I was, I recommend you just open an account and see for yourself! Rich Rogers has put together a list of who to follow on Twitter to get you started. Remember to participate in conversations! The more you put in, the more you will get out.
Imposter Syndrome
It might be a little intimidating to contribute to testing conversations at first, or at least it was for me. I worried that I would look silly for not knowing or fully understanding what everyone else was talking about, that they would find out I’m not a “real” tester and don’t use the same fancy words as they do. To be honest, this feeling of imposter syndrome hasn’t completely gone away, but I’ve learnt to deal with it differently. Whenever I feel like that now, I use it as an excuse to put myself out there and instead of quietly shrinking in to the background, I let people know that I don’t fully understand what’s going on. The results have been wonderful.
The first time I tried this was with my Thoughts on TDD blog post. It started when a colleague asked me what I think about TDD, and I decided to write about just that – what I think about it, not what I know about it. I made it very clear that it’s something I’ve only read about, and not in much detail. Readers of the post reached out to me, letting me in on their experiences of TDD and offering resources for further learning. No one ridiculed me; no one made me feel small for lacking knowledge; no one told me I had no right to publish my thoughts with so little experience. They actually made me feel good to admit I didn’t know about something. Hopefully, they got some insight on an “outsider’s” first impressions of TDD as well.
If you find yourself with the odd case of imposter’s too, lean in and use it to your advantage.
Sharing with Others
I was in total sponge mode a year ago, thinking there was only knowledge for me to absorb and none to pass on. What useful knowledge or experience did I have to share with anyone? Surely more experienced, established testers wouldn’t have much to learn from someone like me who’s just starting out.
But maybe they do. The same way that we become advanced users of the software we test and quickly forget what it was like to start from scratch, perhaps I could remind more experienced testers what it’s like to get started. Perhaps I could show new or aspiring testers what they’re about to go through – in current circumstances, not ten or fifteen years ago. Perhaps I do have something useful to share.
To date, I’ve been overwhelmed with the response to my blogs on testing and software development. Since starting it around six months ago, I’ve already had over 1000 visitors. That probably doesn’t sound like much but, to me, it’s an amazing and exciting thought to have reached 1000 people with my posts, lots of whom share and comment on them too. I’m really grateful to everyone who takes the time to read, share and interact. It’s great to know you’re out there!
I also spoke at SIGiST in London just last week, as part of their new speaker mentoring scheme. It was the first pre-planned testing talk I’ve ever done (in contrast with short, spontaneous talks I’ve done as an attendee at events), and it was fantastic experience. I’m so grateful to have received very kind words and useful feedback, and am looking forward to speaking again soon. My next “appearance” will be at the first UKSTAR in February 2017. Having only been testing for a year, it seems a bit surreal to be speaking about testing in front of audiences already, but I’m so passionate about it and it’s a great way to engage with other testers and learn from one another.
If you’re thinking about starting a blog or speaking at events but are unsure about what you can offer, do it anyway. Only by sharing your experiences, knowledge and perspectives with others will you realise how much you truly have to offer. If you’d like to chat with me about this before you get started, or you’ve taken the first step but aren’t sure where to go next, please do get in touch with me. I’ve had wonderful people from the testing community supporting me, and I’d love to be able to support others too.
The Future
I’m not exactly sure what the future of testing holds for me, but if it’s anything like this past year then it will be jam-packed! There’s so much to learn in testing, and that’s part of why I love it. I had a totally different career before I started working in software, and I’ve honestly never looked back. I really hope that my experiences can inspire someone to do what they love, even if it means taking risks and even if it’s not testing.
Our industry, and our world, is always changing. Sometimes that means uncertainty and discomfort, but I’m pretty happy with how I’ve handled things so far and I really am so grateful for the wonderful community we have. I’m confident that the warmth from that community will always be around, and it makes me feel good to be part of it. To the future!
________________________
I’d love to hear about your experiences. Whether you’ve been testing for one year or ten, please let me know how things have changed for you over the year(s).
One thought to “1 Year in Testing: Then and Now”