Tester interview questions and answers are completely based on the interview I and my friends attended during last years of working experience as Quality Assurance Testers. These SQA questions and scenarios are based only on real experience and were asked during actual QA interviews. Therefore, QA Tester who is looking for a Quality Assurance job will greatly benefit from this. If you are the first time job seeker as a QA Tester, then it can help you even better. Finally, if you are plant to attend an interview, you have to know these questions and answers by heart and must be very smooth in answering these questions. Practice in front of the friends or just a mirror, speak loud and clear. Most of the time, when you study the questions, you feel fine and feel relaxed, but the reality is, at the time of the actual interview, even though you feel you have the knowledge, cannot express it well. It may sound a little rough, but this is everyone’s hard experience. When you come out the interview door, you are deeply regretted. If you cannot remember these by heart, believe me, it may not work. Readers are welcome to post own questions and answers to the following SQA interview questions.

Test case template

The test case template may be giving your some input how to develop detailed test case. The test case example is suitable for manual system test cases. The test case should be written with enough detail that they could be given to a new QA Tester who would be able to quickly begin to carry out the tests and find bugs. Microsoft Excel is my preference for test case template. Excel makes the overall test cases format much more readable, quick and easy then Microsoft Word. There are a few main advantages of keeping test case template in Excel – QA Tester could query Microsoft Excel just as a database, Excel can calculate Quality Assurance metric without custom VBA, finally Excel files can be easily output in many different formats for use by other tools or for QA manager review.

Sample Test Case Template


Test Case ID:
Unique identifier for test case.
Requirement ID:
The identifier of the requirement or business scenario for which this test case is designed for. Logging this will ensure you have adequate testing for all requirements. You can have one-to-one, one-to-many, many-to-many and many-to-one relationships between requirements and test cases, e.g. one requirement per one test case, one requirement per many test cases etc
Test Case Description:
Short description about the aspect of the feature is being tested.
Dependency or Prerequisites:
Any action that need to be done prior to test case execution. For example, "SQL database is down", "guest login to Confluence allowed", "user Jira exists" and so on.
Test Data:
Name of variables, configuration environment and their possible values used in the test case. 
Steps:
Steps to carry out the test. The test steps have to be descriptive and clear.
Expected Result: Expected behavior of the application as a result of steps executed in the test case.
Actual Result: Actual behavior of the application as a result of steps executed in the test case.
Priority Set the priority for test case execution.
Estimated time: Estimated period of time that is need for executing the test case.
After every test case run, this value should be updated to reflect actual time that was spent to run a test case if different from estimated.
Notes, Bugs and Remarks: Any special notes or remarks can be recorded. QA Tester could also directly denote the bug number from bug trucking database like Jira, Bugzilla or Track.
Subscribe to: Posts (Atom)

Common QA Tester interview questions