Let's start with the happy path — a.k.a., the pros.
When you’re the only QA analyst assigned to a project, the freedom is simply grandiose. You get to decide on how to approach the whole QA process, when to start testing and which processes and technologies you want to use.
It doesn’t matter whether you’re an early bird starting at 5 a.m., a night owl working up to ungodly hours or a permanently exhausted pigeon preferring to work a couple of hours every day. Whatever the case, it’s all good. Of course, sometimes you need to adjust to the pace of your team, but usually, you are the master of your own time.
Frequent Cons & How to Flip Your Thinking
Warning: The above-mentioned pros can actually turn into cons.
Since you’re the only analyst on a project, sometimes you have to push pretty hard. It’s quite challenging when there is no one from your department on the project with you, especially when the workload is increasing day by day; the pressure can get pretty overwhelming.
My personal advice is, when there’s a lot on your plate, don’t be afraid to prioritize tasks. Certain features might be crucial to analyze in detail, but some don’t require as much attention. The more senior you are, the easier that prioritization becomes as you learn to predict what might be causing the most trouble.
Apart from that, being the only analyst on a project can occasionally feel lonely. Of course, you can turn to your colleagues for help, but sometimes you just crave a buddy that’s always there. Plus, since most departments have multiple people working on a project, seeing them having fun together can be a little bittersweet. Their inside jokes can make you feel like, “Damn, I want this, too.”
Here, it’s just a matter of perspective. You’re not really alone; you have plenty of people around to have a laugh with — especially your QA colleagues that are in the same boat as you.
When Facing a Problem, What Should You Do?
First of all, calm down. Not sure if this phrase ever helped anyone, but seriously — calm down.
If you feel that things are starting to go south, communicate it to anybody on your project team, be it the PM, engineer or designer. And turn to your entire QA team, too. Trust me, they’ve most probably been there, done that.
Whenever you need help, a piece of advice or an opinion on something, there’s always a person who’s got your back. And the best part is that — at least from my STRV experience — you won’t be met with some professional, bare minimum decency. You get the real drive and enthusiasm of people around you, people who care and love to see you grow.
Oh, and definitely do sync regularly with members of your project, to make sure you understand all the features and their functionalities properly. Remember, it is better to ask twice than not at all.
Think Ahead, Plan & Track Everything
In the case of STRV, QA analysts join projects at a very early stage, so we have enough time to think about our approach. Start with analyzing the product and everything around it.
Dive deep into designs and product specifications to become an expert who knows everything about your project. Prepare a bulletproof test strategy and to top it off, do some market research to find the most suitable devices for your project. Summarize your findings and conclusions in a proper test report, and have one ready after every sprint (or any other time period of your choosing, ‘cause you’re the boss here).
You might argue: Why so much documentation? Isn’t it a waste of time and energy?
Well, it’s definitely not. Having proper documentation helps you navigate the whole testing process, and it is especially beneficial when the project gets into its most intense stage. Additionally, sharing the documentation with your client helps them better understand the whole QA process and what we, as analysts, actually do.
Test cases go hand in hand with documentation. Make sure to have them ready even before you start testing the app, so that you never miss a thing once the active testing process starts. Think of different flows, edge cases, limitations and potential risks with every feature. Trust me, it’ll help you to catch bugs before they can cause some serious problems.
Talking about bugs, it is crucial to report them properly. Include their description, steps to reproduce, environment and device where they appear and, ideally, attach a screenshot or a screen recording. It’ll not only help you to immediately know how to reproduce them when retesting, but it’ll make the whole team more aware of them — so they’ll be easier to fix. And you never know; one accurately reported bug might even uncover some more potential issues.
Always Remember: Lonely Doesn’t Mean Alone
Even though you might be a lonely tester on a project, you are still part of a team. At STRV, the QA team is pretty big — and as a whole, we know the right processes for every situation. If you’re lucky enough to have a similar setup, it makes everything easier.
Do you feel like you need to get inspired? No worries, the team has tons of excellent internal samples of any documentation you might need. Are you still struggling? Plan a meeting with some of your QA colleagues; having that extra pair of eyes often comes in very handy. And during your regular syncs (ours are every week), be ready to analyze the hell out of our projects.
So, should you be a lonely tester? Well, it’s a crazy ride, but a ride worth taking. At least at STRV.
