Finding the right fit between employer and employee is always tricky, and it becomes even more important when dealing with QA positions. Good QA testers can be worth their weight in gold for a business, while bad ones can create more problems than they solve.
No matter which side of the table you'll be sitting on, here are four of the most important questions that should be brought up during your next QA job interview -- and four suggestions for a quality answer.
A good answer should mention the fact that there rarely is enough time to test absolutely everything about an application and the fact that these decisions need to be made in collaboration with management. Interviewees should then come up with a list of at least four or five criteria that can be used to identify the most important application areas to test. These can include:
As mentioned above, there's rarely enough time to test an application thoroughly, so QA staff need to know when enough is enough. The simple answer here is "when the time is right." The "right time" (also known as the exit criteria) might be determined by a number of factors, including:
The wrong answer to this question is definitely "when the application has no more bugs." Even the most well-designed and well-tested application for consumer use has bugs and issues, and the trick is knowing how to prioritize and deal with them when they arise.
Answers here may vary depending on exactly which application you're referring to. A good answer will first describe a reasoned, higher-level view of the situation without rushing into specifics.
Before beginning testing, QA staff should read the requirement document for the software, which outlines the application's features and functionalities and the expected user base. This should provide enough information to create a software test plan, which describes the scope and schedule of the testing and the activities that will occur during testing. From this test plan, the tester can then proceed to write a number of test cases. At this point, the interviewee might want to pause and give a few ideas for test cases and the types of testing to perform -- from unit testing and security testing to load testing and regression testing.
Again, the right answer here may vary depending on the software testing and development workflow that you have set up. In general, a good answer will address all three stages of finding a bug: replication, documentation and logging.
First, testers should make sure the bug is reproducible before reporting it and then take notes on how to reproduce it for developers to use. Although bugs that are seemingly not reproducible can also be reported, there are no guarantees that developers will be able to fix it before the next time it's observed.
Second, create a document, screenshot or video demonstrating the bug to send to developers. Finally, log the bug in your issue tracking software, providing a title, a description, the status and the severity, plus any other helpful information.