Hi there, I’m Alex, and new to testing. I’ve been reading up on a lot of manual testing techniques to start out with, but can’t seem to be able to find someone to talk to about what their day-to-day life is like at work so I can better direct my learning. Thank you in advance to all who read or reply!
So…what is your average day like at work? Even if you’re into automation now, what was your experience as a manual tester (if you were one)? How is your day structured? What would you recommend to someone with no real-world job experience (in testing) trying to get started in this career? What is the best way to get started in automation, and which languages do you recommend? What is your favorite part of being a tester? Your least favorite? Any other advice?
Hi Alex!
I was exactly in the same position 2,5 years ago - reading a bit about testing before I apply for my first testing job. What I can say is: just start applying for entry-level jobs now There are companies who will gladly hire a newbie and have them learn on the go. And then you’ll (hopefully) have somebody to guide your learning. I’m still at that same company that hired me as a “clicking monkey” with basically zero testing knowledge - I’m learning new stuff every day and loving it!
Each day is different, that’s what is so amazing about it. Sometimes it’s back-to-back meetings, sometimes it’s a whole day of exploratory testing an API, sometimes it’s a million of tiny annoying tickets to test, or pairing with a colleague to explore a new web feature… But every company and every team in a company has their own idea of what a tester does so somebody else’s experience will be very different from mine.
I would recommend gaining a lot of experience and knowledge in “manual” testing before diving into automation. There’s nothing worse than automation scripts written by somebody who not only doesn’t know how to code, but also has no idea how to test Get your hands dirty, learn the principles of testing and most importantly, learn how applications work under the hood.
As for languages - whichever language your team works in But if you’re looking to get started before you join a team, then Javascript is your best bet.
Good luck!
Check the dashboard to see what ticket are ready for testing
Check with other testers on the team who picks up which tickets
Test the tickets, and give feedback accordingly.
– Automate if required
– Write some documentation if required
– Poke some business people if business testing is required
Learn what you like to do. Which language is a good question but look around (vacancies, companies near you) I could tell you to learn Python or C# but if no single company around you uses those technologies then what’s the point?
JavaScript/Python/Java/C# will probably be your best bets but do check your surroundings.
You get a new piece of software, that nobody ever saw. You can break it down, nuke down servers, hack applications and criticize people’s work AND get payed for it? #Dreamjob
I work in consultancy and people don’t always appreciate QA or see the true value of QA.
Hi!!
I am SO HAPPY to hear you say that
It seems everywhere I look a lot of folks have negative things to say about newbies going into testing. But I’m glad that that’s not the case here!
That’s exactly what I was wanting to do - learn as much as I can on the job! I love learning! I’ll definitely take your advice to heart about automation - I only know a tiny bit of HTML and CSS, but should keep focusing on manual testing first. I’ll definitely look into Javascript.
I’m really happy to hear that you enjoy the ever-changing aspect of your days! That’s exactly what I was hoping for as well - my old job was entirely monotony, hardly any learning, and boring as heck.
Holy cow, you are so right. This sounds like an incredible amount of fun! I used to do a bit of editing, and I had that exact same feeling about it!
I will also do some research into local companies and see what languages they use, and I can always ask in interviews what I might be able to get into on the job as well. I’m cool being a “clicking monkey” as Eva said above until I get the foundations down and then look into automation. I’m sorry you feel unappreciated sometimes as QA. I’m sure they would feel much differently if all of their QA suddenly disappeared!
I really appreciate your feedback and advice. I can’t wait to jump in
My usual day starts with daily stand-up, after that I check the Kanban board to check the tickets assigned to me, then there are usually a few more meetings trough the day. If I have time, I’ll work on automating a few checks, report a bug or two, ping the POs and/or the BAs to get clarification on certain requirements, write some test cases at per each sprint, send a test report at the end of the 2-week sprint.
When I’m taking a break I’ll grab some lunch, check out the MoT club, maybe read some testing blogs, watch a short course, or attend some online events, like meetups or 99 minute workshops.
I started out as a manual tester and I gradually moved to doing more automation, in my first company the management didn’t let us to try automating anything, I started doing some Selenium in my second company, in my third (and current) company I’m doing API automation, which is my favourite by far!
If you don’t have previous work experience, try to get into an internship, or try applying for enter level role once you spend a couple of months learning. Get to know the theory and testing jargon, learn how to write test cases and some general understanding out automation.
The least favourite part, for me, is writing test cases - I’m more of believer in exploratory testing.
Or, you can always drop into the “Hangout” Sign in - Google Accounts and get a real live tester on video IRL. (Google account required) There is someone online most workdays West-Europe timezone mostly
Thank you for your response! What do you mean by “daily stand-up”?
I’ll definitely put my feelers out for internships as well as entry-level positions, just to cover the bases a bit better. Which theory in particular were you recommending? I’ve read extensively on exploratory testing, and some on basic testing.
Daily standup is just a short meeting where team members say what they were working on, what they plan to work on today and if they are facing any impediments, for example, for me to test a new user story the code would need to be deployed to a test environment, or at the very least I’d need access to the code repository so I can test it locally.
I’m going to throw a bomb in here. It’s basically a waterfall progress update meeting, but you do it every day instead of once or twice per release. Unfortunately that is how a lot of people treat it.
For me personally Agile should be about moving fast in small increments, it’s much more important for people to use the daily to talk about what they need help with, rather then just quoting the IDs of Jira tickets they’re working on. One of the podcasts I’m listening to (AB Testing) to starts with the host saying the following, in a robotic voice: “I’m a mindless Agile robot, I must iterate”
I think the above diversion proves one thing, testers like to talk about the SDLC.
But yes, my day is all about trying to work out what we can automate, spending a few hours manually testing, automating, and then lots of meetings with everyone average 1-2 hours per day in meetings, more as you become more senior. Testers are “across” a lot of the SDLC because testing happens at all points in product creation from the design right up to the shipping, that’s a lot of moving parts. Hence lots of meetings.
Thanks for your insight! I appreciate it. I’ve never minded meetings, since more communication is better than less (I’ve worked somewhere where we could have used more meetings so everyone could be on the same page).
EDIT - I think I figured it out
P.S. I’ve never used Slack before - it takes me to a page where I can’t just make an account, but have to join a (non-existent) workspace - is there something I’m missing?