QA Engineer Interview Questions

You did it. After all of your coursework and projects, you’ve learned enough about QA to apply for a position in your new chosen field. You’re excited and nervous, especially when it comes to the interview. 

A job interview in tech might be a brand new experience for you, or maybe it’s been a while since you’ve had any job interview. Prepare yourself for some of the quality assurance interview questions you’re most likely to be asked and get the gig of your dreams. Remember, these are sample questions that might not be asked of you verbatim, but preparing to answer them will certainly aid your interview preparation.

So What is QA Anyway?

The term QA is vaguely defined with different people giving a variety of answers. This question is a great way for interviewers to a) see what your philosophy towards the job is and b) show that you’ve given it some thought. One definition or question that sums it up well is that the QA person might ask, “are we building the correct product and, if so, are we building it correctly?” 

How Would You Distinguish Between Testing, Quality Assurance, and Quality Control?

These terms get used pretty interchangeably. If you’re asked about them in an interview, you’ll want to be prepared to answer well.

• Testing covers any process of looking for and recording any defects or bugs. This is the work of deciding if software is doing what it’s supposed to or not.

• Quality assurance is the organization of testing. It’s planning and maintaining control over the testing process and decides what a passing test entails.

• Quality control is the evaluation of the defects found in testing and determining what the best solutions are for them. At this stage, suggestions for improvement of the software could be made.

Looking at all of them as a whole, testing is what’s done when quality assurance and quality control look at their results to decide what actions to take next.

What Are the Different Methods Used for Testing Software?

This is a pretty broad question for you to be asked, but you’ll want to narrow it down to give an organized answer.

Generally speaking, there are three main methods of testing software:

• Black-box testing
• White-box Testing
• Gray-box Testing

Black-Box Testing

This involves testing by only using a list of requirements and specifications. In other words, the tester isn’t required to know anything about how the software works. They are testing it as a user. 

White-Box Testing

This is testing within the software itself and requires knowledge of the codebase, as well as an understanding of programming in general.

Gray-Box Testing

As you can imagine, this is a mix of both black and white where the tester has some knowledge of the inner workings of the program. 

Any sort of testing that is done will fall into one of these three categories.

So, What’s the Difference Between Validation and Verification?

Those two words get used interchangeably quite a bit in the tech field. If you’re being interviewed by someone with some QA experience, you don’t want to confuse the two.

A very good way of distinguishing between them is to ask two different questions: 

a) Are we building the system properly? 

b) are we building the proper system? 

The first question answers about verification. It asks if the software being built is working according to its business requirements. The second question asks if it’s doing what its user expects. Verification finds problems with specification, validation finds defects in implementation.

What Are the Levels of Software Testing?

You’ll want to narrow down your answer to make sure it’s organized and coherent.

Again speaking in general terms, there are four levels of testing that a product will go through:

• Unit testing
• Integration testing
• System testing
• Acceptance testing

Unit Testing

This is also called component testing. This stage of testing isolates parts of the software in such a way that single components or sections can be tests alone. This is done early on during the software development process. In fact, there’s a method of coding called ‘test-driven development’ in which the developer writes a unit test first, then codes to make that test pass.

Integration Testing

Once the components are made and can interact, integration testing can happen. This is testing the parts working together. Think of it as a collection of the units tested in the previous step. In what’s called ‘bottom-up testing’, the unit testing from the previous step is combined to make more complex scenarios with more components.

System Testing

Once everything is more or less assembled, system testing will–as its name implies–test the whole system together. By this point, more specific business requirements will have been written to test against it. This is testing the software in a manner similar to how its users will operate it.

Acceptance Testing

This stage adheres closely to whatever the business requirements specify and is the final testing done in a user role.

What Goes Into Making a Good Test Case?

The bread and butter of software testing is the test case. This is the fundamental experiment that testers perform on the code to check its quality. Being able to write good test cases is something employers will look for. 

A good test case should have:

• A test case ID number: There can be hundreds of test cases–if not thousands–on a software project, so some form of easy identification for organization is crucial.
• Test case description: You want a clear, human-readable description of what this case is testing so that anyone can understand it at a glance. You’ll be thankful for this clarity especially if you’re working at the eleventh-hour trying to meet a shipping deadline
• Severity level: Is this a show-stopping bug? An irritant? Something that might be nice to have? Having this clearly indicated in the case helps when people are trying to organize test cases under pressure (like that eleventh-hour deadline above).
• Priority: Just like severity above, being able to organize test cases quickly is important.
• Environment: So many variables can cause bugs. You want to be able to eliminate those factors quickly, so having the environment (ie: Mac Sierra) in which it occurred can help triage. 
• Build Version: Just like with the environment, having this data can reduce time spent trying to find a cause.
• Steps to execute: This is probably the most important part of a testing case. These need to be written in such a way that anyone could pick up the case and perform exactly the same actions to compare results. The art of writing great testing steps is what separates good from great QA professionals.
• Expected and actual results: These need to be as clearly specified as the steps to execute in order to have uniformity for comparison.

When is It Not Good to Do Automated Testing?

If you’ve had any experience with automated testing, such as with Selenium or a similar platform, you’ll no doubt have questions about that experience to field from an interviewer(and if you haven’t had any experience with it, consider a QA course at a local coding bootcamp). The range of possible technical questions that could come up are beyond the scope of this article, but a fundamental question would be: when should you do it and when shouldn’t you?

"Career Karma entered my life when I needed it most and quickly helped me match with a bootcamp. Two months after graduating, I found my dream job that aligned with my values and goals in life!"

Venus, Software Engineer at Rockbot

Find Your Bootcamp Match

• Any testing requiring human validation that can’t be done by machine should be done in a manual test. This might mean evaluating the look and feel of an app, or deciding if something is readable or intuitive.
• If a feature is in constant flux, requiring constant rewriting of automated tests to fit, this should remain manually tested until it can be pinned down.
• If the testing is very complex to the point of more time spent writing an automated test than makes sense, keep it manual. Automated testing should be just that, automated and out of mind so that it can free up your human resources.

Automated testing is great for those small, tedious tasks that can be easily automated. If it’s easily coded and provides good information, automate it. Otherwise, leave it to the humans.

Be Prepared for the Big QA Questions

You’ll certainly want to make sure you’re prepared for technical quality assurance interview questions based on any automated testing you’ve done, but don’t forget about the human aspect of any quality assurance. Testing is about humans evaluating work and making sure it’s up to the standards they expect. A potential employer is looking for someone who will keep up their organization’s standards on the front line of software development, so put yourself out there as the best gatekeeper for them.

If you want a solid background in QA for any possible employment–or you’d just like to make sure your skills are at the top of where they should be–enroll in the QA track at a local coding bootcamp. Get the training you need and the confidence to ace any QA interview.