You should swim, it’s that or drown.
Sometimes you come into a company or team mid-sprint, the heat is on and no one really has time to hold your hand through the first few weeks. You’re expected to not only hit the ground running, but keep up with people who’ve been in the race for a while. This, to put not too fine a point on it, is daunting.
This recently happened to me, not through design, the people I am working with are good people with good intentions, but a combination of pre-booked holidays, intermittent internet for remote workers and my notice period on my previous job conspired such that the second week of my new job had me as the lone manual tester on the team, as we were pushing our release out the door. Oh and there was nearly nothing a new team member needed to know on our internal wiki.
I’d had a week of basically learning a little bit about the product as I ploughed through some bug verification and improvement integration. A lot of my time was spent learning what on earth our part of the product did and what the tests we were doing actually did and meant.
I was pretty lucky in that I’d worked with some of the developers before and I’ve been around the block long enough to know how to handle the kind of things that a standard release cycle will throw up. I also had a series of tricks, or should I say techniques so I look more refined, that allowed me to effectively assimilate a lot of information quickly and use them to make my way through the first couple of weeks. I’m going to share these amazing techniques today, gratis and for free.
My first trick was this: write it down. It doesn’t matter what it is, it doesn’t matter how you write it, just write it. You’ll get reams of information, far far more than the human mind can remember. Honestly, you get about 6-9 slots in current memory and unless you get a chance to push it to long term, it’ll be lost when your stack overflows*. This is a problem as you’ll probably be losing information in less than a minute at normal speeds. Writing things down shoves the problem aside and actually helps ameliorate it. When you write something down, you not only create an external store of information, but it also helps you commit it to memory**. It’s also often the case that if someone is teaching you something and they can see you writing, they will often pause, or slow down so you can finish writing. This helps to stem the tide of information overload. Now, all the research I’ve seen suggests that writing with a pen and paper is far better for information retrieval than typing into a laptop so if you can do it that way, definitely do. However my handwriting is a write only mechanism, so I use Sublime Text and a hierarchical directory structure which serves me well.
My second trick is to remember that you were hired/transferred because people think you can do the job well. It’s all too easy to underestimate yourself and think that everyone else is not taking into account the fact that you sometimes get distracted, or that you forget things, or that some days you just wish you were at home. Here’s the real kicker, those people are only judging you on your results. They don’t care how you get them, they don’t mind if you forget the odd thing, because they probably don’t notice it. What they see is what you achieve, not who you think you are. So not only can you do it, you can do it despite all the flaws you see in yourself. I came into testing through a 6 week temporary contract while I looked for a job. That 6 weeks became 4 years. I don’t have a degree, I don’t have any formal training in testing, I don’t even, hand on heart, think of myself as someone who can program. If you asked me who I was, it’d be a writer and gamer, a father and gardener, a cook and an entertainer. Yet here I was, dropped into a new job where I’d be doing some automation, lots of organising of tests and learning a new product on the fly. I honestly didn’t think I could manage it, but I always feel that way. I sat down each morning and I reminded myself that not only could I do it, but that everyone who hired me thought I could too. So either everyone was wrong, or my feelings were. Six weeks later, I think everyone else was probably right. You can do it too, write that down.
Thirdly, remember that while software products and development strategies might change – I just went from waterfall to agile – the core precepts of testing don’t change. You will be presented with many things you can’t immediately categorise as a bug or an expected behaviour. You freeze and worry that if you raise it as a bug, you’ll be wrong and seen as unreliable, or if you don’t it’ll be an actual bug and then you’re even more unreliable. What do you do? What would you normally do? You’d open your mouth (or chat client) and ask someone. No one sane, at all, would ever expect you to understand an entire software product on first glance, except the people running the Hello World! Company. Ask questions, ask them often, read existing bugs, get a feel for how people phrase things. You’ll also see a lot of terminology you don’t understand, things that are specific to this project or company. You will not understand these, again, ask. It’s here that writing it down can really help. You can write enough notes that the next person to join can merely read your notes on an internal wiki or the like and cut their learning time in half. This, in the hideous corporate speak of Silicon Valley, adds value. Always bear in mind that while what you’re seeing in the specific might be wildly different, if you abstract it a little, you’ll see it’s just a variation on things you’ve seen before.
Fourthly, don’t be afraid to fail. This has two meanings for a tester, it means be prepared to try new things without worrying that failure will somehow mar your perfect image. It can also mean not being afraid to say “No, this product does not pass this test, I will fail it”. There can be a strong temptation to curry favour among a new team by saying “this product is great, no problems”. It’s natural to want to be nice to new people, but you’re a tester and the best love a tester can give is tough love. You were hired to say “There is a problem we need to fix before we can let this out the door”, so if you find that problem you need to say it loud and proud. Your team will, eventually, thank you for it. Trying new things is also extremely good for you and certainly won’t make you seem bad if you fail at something new. Try writing a new test, try clarifying a test. If automation is in a language you don’t know (or you’re simply not a programmer), try adding a test. Ask for help, look for examples, but be willing to give it a go. The very worst that can happen is that you learn something, assuming you’re not playing in production of course!
Finally, my absolute killer technique, when you go home, leave work at work. I am terrible at this, I want to check emails, maybe kick a automated run off, perhaps read some of the test repositories. I have to fight it. I don’t always succeed. But turning off when you go home and focussing on your life will actually help your work the next day, and the day after that. Go home, talk to your friends and family about things that aren’t work. Read a book. Watch a movie. Sleep. Everything you do outside work that isn’t work will give your mind time to puzzle things out about work in the background. You’re helping the company and yourself by watching that Netflix series or reading the new book you’ve been waiting for. Obviously partying every night would take its toll, but be sensible and you’ll find that you’re a lot more productive and learn faster.
In conclusion then:
Write everything down
Everyone else judges you by your actions and results, they are more objective than you and they believe in you. Run with it.
Everything new is something old in a hat. You know how to deal with it, just look past the false mustache.
Failure is always an option and it’s not even a bad one at that.
Work to live, don’t live to work.
*http://psycnet.apa.org/journals/rev/63/2/81/
**http://pss.sagepub.com/content/early/2014/04/22/0956797614524581.abstract