Manual Testing Interview Questions

Kasia Mikoluk

After weeks of caffeine fueled nights, you’ve finally landed that dream interview for a manual QA testing job. Congratulations! But there is still a big hurdle to cross before you can pop off the bubbly and celebrate. Clearing the interview, after all, is no child’s play, especially for jobs as technically demanding as a manual QA tester.

Most manual QA testing interviews will try to assess your technical skills as well as your personality. Based on this fact, you can expect the following questions in any manual QA testing interview:

Personality Based Questions

Q.1 When did you first start using a computer? What sort of help did you have when you first used a computer?

A. What does this question have to do with a manual QA testing job, you ask? Nothing, and everything!

Manual QA testing is a unique job in the sense that it requires the tester to not only have strong domain knowledge, but also be intimately familiar with computers. Hackers who grew up with computers will generally outperform engineers who started using computers only in their late teens or college. This is the reason why many developers like to ask the interviewee questions about his or her computer usage habits. The assumption is that the earlier you started using a computer (and the less help you had in using it), the better practical understanding you would have of how computers actually work. After all, anybody can get a degree from a college; only a few have the experience and the passion to be standout testers.

So even though this question asks you nothing about QA testing, it still helps the interviewer learn a lot about how much you know about software.

Q.2 What are your hobbies and interests?

A. Yet another question that has nothing to do with testing, but keeps popping up in virtually every interview. One of the key principles of the school of Context Driven Testing that has increased in popularity with some recruiters recently is that your hobbies and skills are transferable qualities that affect how you work. Put simply, the modern organization does not merely want someone who can test out applications; it wants people who are passionate about software, computers and how systems work in general.

Hobbies and interests, therefore, become a way to know about what really interests and motivates you.

As you can imagine, there is no ‘right’ answer to this question. What the interviewer is really looking for is the passion and depth of knowledge you show for your hobby. It also helps to have hobbies that involve working with complex systems. This course on succeeding in interviews will give you just the right pointers on how to talk about anything – including your hobbies and interests.

Q.3 How would you define a ‘good tester’

A. Good testers are people who have an inherent knack for taking things apart. They are natural tinkerers and hackers who will find all possible ways to break apart any software. A good tester will find hundreds of test cases for testing a simple electronic device (like a microwave oven). Good testers also have the ability to work in a team and communicate freely and frequently with the developers.

You can learn the essence of software testing and what makes a good tester in this online software testing course.

Q.4 Can you act like an inexperienced user?

A. This rather tricky question is one of the favorites among developers simply because so many QA testers slip up on it. Since the job of the tester is to find errors and bugs in the program, being able to work and think like an inexperienced user is a huge bonus. But any competent QA tester is so used to working with technology that he cannot be reasonably to expected to think like a beginner.

So when you get a question like this, don’t answer with an emphatic “yes!”. Instead, say that while you can’t think like an inexperienced user, you can definitely write test plans to approximate such a user.

Q5. What is your process for QA testing? OR What was the process for QA testing in the last company you worked with?

A. QA testing is the process of following processes. Great testers are anything but not methodical. When an interviewer asks you this question, he expects you to tell him or her – in detail – the process you follow(ed) when testing software.

A sample answer would run the interviewer through the entire software development process – from the creation of the business requirement document to the development of the test plan and the actual testing (both manual and automatic).

Technical Questions

Q.1 How would you test a toaster?

A. Another staple of QA testing interviews, this question is designed to see how you approach a problem. The interviewer might replace toaster with any device – blender, microwave oven, food processor, etc. The answer should follow the same process with only a change in the relevant details.

A sample answer would consider the following:

a. External features (i.e. the UI) of the device such as color, design, power cable, odor, etc.

b. External indicators such as LED/power light, switch condition, etc.

c. Condition of equipment.

d. Functional aspects of the device. In the case of the toaster, this should be a long, methodical process that will involve running an empty toaster, checking for quality of toast at different settings, checking for performance after significant load, checking with different types of bread at variable voltage, checking for performance when toaster is run on battery backup, etc.

The more in-depth and methodical you can get in your answer, the better. For a better grip on testing fundamentals, check out this course on software testing basics from Udemy.

Q.2 What is the difference between priority and severity? Give examples of each.

A. Severity defines the extent of the damage caused by a defect, while priority defines the order in which the defect should be solved.

A problem that causes the entire application to crash when a user performs a very rare sequence of steps has high severity (since the app crashes altogether), but low priority (since the defect is accessible to very few users). On the other hand, a defect that causes a specific, scarcely used function to become non-usable when a user performs a common action has low severity (only a part of the application stops working) but high priority (it’s affecting a large number of users).

You can get more information on priority and severity here.

Q.3 How would you define a ‘Test Plan’? What all should a test plan contain?

A. A test plan is the road map according to which all QA testers must work. It is a high level document that explains in detail, the testing strategy, expected delivery time, and the type of resources available to the tester.

Most test plans can be broken down into the following constituents:

a. Objectives of the test

b. Strategy adopted to fulfill the test requirements

c. Resources available to complete the test

d. Entry criteria

e. Exit criteria

f. What must be tested/what must be skipped

g. Risks involved in the testing process, and how can they be circumvented.

Q.4 Explain the difference between Retesting and Data Driven Testing?

A. Retesting is the process of testing any software application before bug fixes, changes and enhancements. It is done manually and thus, is more time consuming (but also more insightful) than Data Driven Testing.

Data Driven Testing, also called DDT, describes an automated testing process wherein multiple data sets are used to test a feature.

Q.5 How would you write a good bug report OR What all must you tell the developer to fix a bug?

A. Never underestimate the value of good communication skills. Generating bug reports is a huge part of any tester’s job. Being able to create concise, easily readable bug reports is essential to success as a QA tester.

Any good bug report should have at least all the following components:

Summary: As obvious, the summary should give the programmer at-a-glance description of the bug. It should be descriptive without being verbose. As with wit, brevity is the soul of summaries as well!
Priority: How important is the bug? Does it break the application or only cause a specific feature to not function as expected? This component will tell the developers how fast the bug should be rectified.
Affected Versions: What versions of the software carry the bug in question? The report should list all current and previous versions in which the bug is found.
Operating Environment: Some bugs pop up only when the software is run on certain operating systems, browsers or computer-types. This component should list all relevant details about the operating environment, including browser, OS, and hardware specs.
Reproduction: This field should tell the reader about the frequency of the bug and how can it be reproduced. It should also include a list of steps that can be taken to reproduce the bug.

Additional items you can include in the bug report are screenshots, error messages, URL of the erroneous page (if testing web apps), etc.

Conclusion

Manual QA testing is more than a simple technical pursuit; it is a way of perceiving things. Great testers continuously think of new ways to work with any object, be it a toaster or a software program. So while you can certainly be expected to answer theoretical questions in a manual QA testing interview, it is your personality and passion that will eventually get you that dream job.