How to Transition to Tech: A Friendly Guide to QA Careers

When I tell people about my transition from mental health science to quality assurance testing, the response is similar across the board: “Wow, I could never do that!” There’s a false perception that the tech industry is unreachable for people with backgrounds outside of tech. I spent over half a decade dedicated to psychological medical science, earning my Bachelor of Science in Psychology and working directly with clients in mental crisis times. Now I’m the lead tester for Lucidchart’s mobile team. While I was able to leverage the skills and tenacity I gained from my previous work experience, I had to learn how to be successful in a completely new field. I had friends to encourage me when making my transition to tech, so here I am, your new friend with an insider perspective, to give you all the information you need to make your own jump.

Making a change

I was already accepted to nursing school when I became a software tester. I had my Bachelor of Science in Psychology and had been working at a nationally recognized psychiatric hospital for three years. Making a career in the medical field required a lot of hours, a considerable amount of loans, and endless patience. I had put in my time (medical certifications, three years of hospital work, countless volunteer hours, a year and a half of nursing prerequisites) and was committed to spending several more years getting a second degree in nursing so I could have more of a career choice in the medical world. Around the same time, a friend of mine became a front-end developer, transitioning from an arts degree with a game design emphasis. When I became interested in tech, she advised me to attend meetups with Girl Develop It. At a meetup, I heard about different avenues for entering the tech industry, including going to a coding bootcamp. However, I decided I was most interested in QA. I began applying for jobs, not exactly knowing what I was looking for but knowing I wanted a change. I declined my spot in nursing school and began software testing at Lucid Software in early 2016. Sounds terrifying, right? I had planned on staying in healthcare for a long time. I came to tech with a good knowledge of computers and software but without ever having formally tested outside of play testing my spouse’s Indie games. These are the three steps that prepared me for the interview process:

Networking to interviewing: Getting started

1. Connect: Attend meetups, use online resources, find mentors. Do you have a developer acquaintance who is willing to go to coffee with you and talk about their field? Even in a smaller city, you can look up tech meetups and usually find something going on. Neither of those an option? Then Google is your new best friend. You can find blog posts, articles, even entire websites of people discussing their experiences. In this stage, you’re making connections and finding your direction. 2. Leverage: Once you have an idea of the kinds of jobs you want to apply to, you can determine (a) what skills and knowledge you already have that will apply to a collaborative environment and (b) what background information you’ll need to gain to be competitive. A good first step is to research current processes and leaders in whatever area you’re applying to. Development methodologies, test types, and some general understanding of code will help you in an interview, but it also tells you a lot about the company you’re interested in if they use outdated methods.  What skills do you already have that you can show off? Have you worked with teams before or been in a leadership position? Do you have projects where you took initiative to get things done? Do you have a great attention for detail? Leverage the skills you will be using in your day-to-day job. Doing so will help you feel more confident in the interview as well. 3. Apply: Apply to every job you’re interested in, regardless of whether or not you have that one year of QA experience they want. Most employers compile a “wish list” when making their requirements, but unless you need a degree (which you usually don’t in tech), your knowledge and skills will get you further than you think.

You decided you want to do QA! Here’s what to look for in a company.

Below are some telling questions to ask in your interview or when touring a new company to help determine how enjoyable it is to do QA there.

How is QA implemented? Do you use metrics to track QA progress? Know ahead of time if you will actually be testing or if you’ll spend most of your time writing cases. Understanding the emphasis of the QA team—if they focus more on automation, writing test cases, or exploratory testing—can inform you not only on what kind of work you can expect but also on the priorities of the company. If a company is more interested in metrics or requires constant test case writing, they presumably don’t have a strong sense of QA best practices and will be less likely to treat you well as their tester.

When is QA involved in the process? For QA to be truly effective, you need to have QA during the entire development process. If QA only gets to see the product at the end of a long development cycle, they aren’t going to be able to do their best work, and bugs will almost certainly go uncaught. In addition, it’s good to know how integrated the QA team is. While it’s not uncommon to shove all your QA testers in a room far away from your developers, it’s certainly not ideal. Knowing how much you will be able to communicate with the team, and by extension how seriously your input is taken, will give you an idea of how valuable QA really is to the company.

Is QA considered a gatekeeper of bugs? If the answer is yes, I have one piece of advice for you: run.

 

Who is responsible for bugs that make it into production? The goal of QA is to make sure nothing happens, thereby allowing  the user to get what they need from your product without headaches caused by bugs or unintuitive workflows. Ideally, your user would never know a feature was half broken for three sprints. However, the truth of all software is that we have no idea how many bugs there potentially could be. Bugs exist in every software product you use, but a good QA team can make sure that most of those bugs are relegated to strange edge cases and that more widespread bugs get reported and fixed quickly. A good QA tester knows they can’t catch everything, but they also know what features and bugs are going to have the biggest impact on users and can make prioritized testing and development decisions. If the attitude at a company is “a bug got by QA, so now I’m going to yell at you for an hour,” or “QA causes all the bugs,” I’d suggest you politely decline—they are not worth your time. ___________________________________________________________________________________________________

Alright, so you did your research, you networked, you applied everywhere you could, and you got an offer! But what if...

I got the job, and I’m more terrified than before.

When you’re making a transition from a completely different field, you’ll likely find that for the first three to six months, you’ll have to be vulnerable in order to learn while leveraging your existing skills. The most desired, qualified candidate still has to come up to speed with the company’s product, jargon, concepts, and team dynamics. You may have felt very confident or proficient in your previous career, so just be aware that the transition can be a confusing time where you may doubt yourself. But remember it’s also an exciting time! To get up to speed, your best resources will be other QA specialists, your developers, and Google. Learn the jargon quickly, as it’ll help you with the most important piece of any team dynamic: communication. Writing “that dropper thing” in a bug report won’t get you as far as using the syntax your team is already familiar with. You’ll be asking lots of questions, so this step will help you get the answers you actually need. Of course, nothing beats grabbing another QA team member or a developer and showing them your process. The most important piece of enjoying your new career is whether or not you actually enjoy it. You likely made this change with the intent to improve or shake up something in your life, but always remember that your level of happiness will determine whether or not you still like your new career after the first six-month hurdle.