Viability of Software QA as a Stable Career
December 9, 2015 12:24 PM   Subscribe

I've spent 3.5 years as the main QA person designing and executing test cases in a small e-commerce software company, and have recently been contemplating the possibility of software QA as a long-term career. The issue: I majored in the social sciences and have no tech skills. Is my plan viable? If so, what steps can I take now to build a marketable skill set?

The internet is saying that I should start by learning how to write automated test scripts and to do this requires programming knowledge. Which language should I invest my time in learning--SQL, Javascript, Python, Ruby? I would appreciate any advice on the best course of action to take.

Many thanks in advance.
posted by tackypink to Work & Money (9 answers total) 7 users marked this as a favorite
 
This is totally a viable plan! Companies are far more willing to consider candidates with non-CS degrees for QA than they are for product development (and they're starved for good QA candidates).

You don't actually necessarily need to know a programming language to start (although it'll be helpful): Selenium allows you to record tests interactively (by clicking through the web UI you're testing) and then replay them later. But to the extent you do want to learn a language, I would personally suggest Python; I find it easier to get on with than either Ruby or Javascript, and the community support around it is IME much better than either of them. SQL is a different thing entirely.

Feel free to MeMail me if you have any more questions or want more detailed pointers to learning resources! (I used to work in QA and I've helped tutor beginning Python developers.)
posted by asterix at 12:41 PM on December 9, 2015


If I had to pick blind I would say Python - it's generic, widely used, and fairly easy to pick up. However, it's probably better to learn whatever language is the main one at your current company. If you can learn one language you can learn another.

You should also learn about the role of automated testing and the testing tools for that (link to python unit-test). You should also learn about Agile development as test-driven development tends to fit very much into that area + QA skills with Scrum is probably a good way to make yourself more marketable and not get pegged as just a tester.
posted by crocomancer at 12:41 PM on December 9, 2015


I don't work in QA, but I've known quite a few QA testers with non-technical backgrounds; it's definitely a viable plan. I work at a place where a lot of automated testing is done, and the main languages used are Python, Groovy, and CoffeeScript. We also use a variety of tools; off the top of my head, I can think of Protractor, JMeter, Fitnesse, Gatling, HP UFT, and Selenium. Jenkins is also a good product to be familiar with.
posted by neushoorn at 12:46 PM on December 9, 2015


Agreed that it is totally a viable plan, and I know many, many people with "soft" degrees in QA.

Apart from the other advice about languages and testing tools, consider becoming an expert with source control tools like Git or Perforce.
posted by Cool Papa Bell at 12:53 PM on December 9, 2015


echoing everyone else: certainly possible.

but i'd also add: learn technologies you can use at work. that way, you get to understand them more deeply. you don't really say what kind of testing you are doing, but if it's using web pages then selenium, already mentioned, is what i have used before. for testing programs (or parts of programs) as "black boxes", robot framework is another popular tool.

if you're testing code at a lower level then generally you write tests in the same language as the code that you're testing. so maybe that would help guide what language you learn first (ie use whatever is used to write the code at work).

but if you're just tying various things together (moving results around, making plots, etc) then a scripting language like python is a good choice.

someone else mentions jenkins. that's a tool that automatically runs many kinds of tests each time software changes. again, it may already be in use where you work, if the developers are into "continuous integration".
posted by andrewcooke at 1:01 PM on December 9, 2015


Best answer: Go for it, if you enjoy it. Your competition will be cheap outsourced labor, test automation itself, or companies believing that developers can test their own code well enough to not need you.

Skills which can help you succeed:
  • writing clear tests/documentation
  • excellent communication with technical/non-technical peers and management
  • writing automation
  • reading product code
  • debugging product code
  • understanding good software/UX design
  • deep understanding the product/problems/solutions/users/competition
  • understanding what management is concerned about and mitigating it
  • positive vs adversarial relationship with developers
  • identifying and managing outsourcable tasks
  • ... and many more
Automation is not the holy grail of QA, it's just another tool in the tool belt. If you want to learn coding, you should find a problem that you care enough about to go solve, then go solve it using whatever language seems like it might be the best to solve it with. You will get this wrong, but that's OK, you will learn from it. The biggest hurdle is not giving up. A good first task could be parsing logs using python, perl, or just about any other language in the world.

Feel free to MeMail if you want to discuss further. I've been in QA for 15 years doing manual, automated, and management. No plans on ever changing careers.
posted by Diddly at 1:45 PM on December 9, 2015 [3 favorites]


Great answers here.

I'm a tester, now test manager, whose degrees are a BA in French and a Masters in comparative literature. As others have mentioned, having a non-CS degree can actually be a plus in testing. It's a field where you need to understand the purpose and expectations of a product more than the code inside it. Indeed, test types that concern the code are generally done by technical teams, where other types of testing are done by more specialist test teams.

Communication is a huge part of testing: you have to not only understand the specifications, but actually get them in the first place, as in have the documentation. This often turns into being an ad hoc consultant who helps define and implement the processes to create and/or improve the writing of specifications. That's kind of far down the line from a beginning tester, but I use it as an example to show where this sort of thing can go. When you have specifications, you will find issues with them; they'll need to be analyzed, qualified, traced; you'll need to have meetings with design and development teams to clarify things both upstream (before testing) and downstream (after discovering bugs/defects). Your tests will need to be well-organized, specific, clear, and able to be executed and understood by others. Good writing skills are a fundamental requirement in the field.

As for automation, it's only part of testing. It tends to be more on the technical side, but is getting more into functional testing as well. Websites are great with Selenium, but for instance, my teams do a lot of work on applications designed for internal usage only, on specific systems, where automation has too little of an ROI compared to a well-written, easily maintainable manual test repository. Everything depends on what you're testing, how it's going to be tested, budget, priorities... Just to say that automation is not actually everywhere. Only half of the people on my teams know how to write scripts in a given language.

In addition to the other suggestions here, there is a certifications board for testing, ISTQB. Their syllabi are available online for free. It's an excellent methodology, though not the only one. Goes into different testing types, et cetera, and has the advantage of not being linked to any particular company. (Full disclosure: I know the founders, my Foundation certification course was given by one of them and I worked years with another. So I speak from direct experience when I say they are really dedicated to it being open and not linked to a specific place. I do not earn anything by recommending them.) I'd definitely recommend reading the Foundation syllabus; it will give you an overview of testing types and help you direct your research; help decide what suits you best.

I've been in software and systems testing for 8 years now and love it. It brings together my soft skills – people, writing, analysis – and my geek side that has always loved computing and figuring out how stuff works. Plus I get to help fix things! I see myself doing this for the rest of my career; it is definitely a field with a future.
posted by fraula at 3:12 PM on December 9, 2015


Learn whatever languages your coworkers can answer your questions in. Python is fine but don't count out JavaScript there is a huge ecosystem of tooling and knowledge on how to do things. Selenium is a great tool but there a lot of other testing tools out there. Automation isn't everything but it makes it much easier in some cases. I worked as a QA Engineer verifying and automating tests and moved into Software Development. QA is a great career and there's no reason anyone couldn't make it a long term career.
posted by andendau at 3:29 PM on December 9, 2015


Response by poster: Thanks everyone for the encouragement and very helpful suggestions! I'm excited to pursue this path. :)
posted by tackypink at 11:44 AM on December 10, 2015


« Older How to record and have my notes transcribe?   |   Gift for beloved boss on my last day after 7 years... Newer »
This thread is closed to new comments.