Test Case

Test Scenario: It is a high level documentation of customer business workflow.

Test Case: It is a document which cover all possible scenarios for a specific requirement.

What are the drawbacks of not writing test cases?
What will happen if you look at the requirement and test the application?
What are the drawback if you test the application by directly referring the requirement?

• There is no consistency in the text execution.
• Test Eng. will miss lot of defects.
• Quality of testing varies from person to person
• Testing depends on memory power of the test engineer.
• Chances are there we might test same scenarios again and again.
• Testing varies from person to person,some of them come up with creative scenarios and test the software for all possible 
• scenarios and some of them may not come up with creative scenarios.
• Test coverage will not be good.

When we write test case?

• When customer gives new requirement we should write test case.
• When customer wants to add new features or extra features we should write test case.
• When customer wants to do modification on the existing feature we should write test case.
• While testing the software if test engineer come up with creative scenarios we should write test case.
• While testing the software if test engineer finds any defect and if test case is not present for defect then we should update test case for the defect.

Why we should write test case?

• To have a consistency in text execution
• To have a better test coverage
• To depends on the process than a person
• To avoid training to every engineers on the products or on requirements.
• It is the only document which acts like a prof to customer,project manages and management that we have testing everything.
• It acts like a base document to write automation test script.
• If you document all the test case in a very organised manner it will take very less time for test execution.

Test Case Template:

PROJECT NAME: Name of the project the test cases belong to
MODULE NAME: Name of the module the test cases belong to
REFERENCE DOCUMENT: Mention the path of the reference documents (if any such as Requirement Document, Test Plan, Test Scenarios etc.,)
CREATED BY: Name of the Tester who created the test cases
DATE OF CREATION: When the test cases were created
REVIEWED BY: Name of the Tester who created the test cases
DATE OF REVIEW: When the test cases were reviewed
EXECUTED BY: Name of the Tester who executed the test case
DATE OF EXECUTION: When the test case was executed
TEST CASE ID: Each test case should be represented by a unique ID. It’s good practice to follow some naming convention for better understanding and discrimination purpose.
TEST SCENARIO: Test Scenario ID or title of the test scenario.
TEST CASE: Title of the test case
PRE-CONDITION: Conditions which needs to meet before executing the test case.
TEST STEPS: Mention all the test steps in detail and in the order how it could be executed.
TEST DATA: The data which could be used an input for the test cases.
EXPECTED RESULT: The result which we expect once the test cases were executed. It might be anything such as Home Page, Relevant screen, Error message etc.,
POST-CONDITION: Conditions which needs to achieve when the test case was successfully executed.
ACTUAL RESULT: The result which system shows once the test case was executed.
STATUS: If the actual and expected results are same, mention it as Passed. Else make it as Failed. If a test fails, it has to go through the bug life cycle to be fixed

Test case ID: Unique ID is required for each test case. Follow some convention to indicate the types of the test. For Example, ‘TC_UI_1' indicating ‘user interface test case #1'.

Test priority (Low/Medium/High): This is very useful while test execution. Test priority for business rules and functional test cases can be medium or higher whereas minor user interface cases can be of a low priority. Test priority should always be set by the reviewer.

Module Name: Mention the name of the main module or the sub-module.

Test Designed By Name of the Tester.

Test Designed Date: Date when it was written.

Test Executed By Name of the Tester who executed this test. To be filled only after test execution.

Test Execution Date: Date when the test was executed.

Test Title/Name: Test case title. For Example, verify the login page with a valid username and password.

Test Summary/Description: Describe the test objective in brief.

Pre-conditions: Any prerequisite that must be fulfilled before the execution of this test case. List all the pre-conditions in order to execute this test case successfully.

Dependencies: Mention any dependencies on the other test cases or test requirements.

Test Steps: List all the test execution steps in detail. Write test steps in the order in which they should be executed. Make sure to provide as many details as you can.

Pro Tip: In order to manage a test case efficiently with a lesser number of fields use this field to describe the test conditions, test data and user roles for running the test.

Test Data: Use of test data as an input for this test case. You can provide different data sets with exact values to be used as an input.

Expected Result:  What should be the system output after test execution? Describe the expected result in detail including message/error that should be displayed on the screen.

Post-condition: What should be the state of the system after executing this test case?

Actual result: The actual test result should be filled after test execution. Describe the system behavior after test execution.

Status (Pass/Fail): If an actual result is not as per the expected result, then mark this test as failed. Otherwise, update it as passed.

Notes/Comments/Questions: If there are some special conditions to support the above fields, which can’t be described above or if there are any questions related to expected or actual results then mention them here.

Add the following fields if necessary:

Defect ID/Link: If the test status is failed, then include the link to the defect log or mention the defect number.

Test Type/Keywords: This field can be used to classify the tests based on test types. For Example, functional, usability, business rules, etc.

Requirements: Requirements for which this test case is being written for. Preferably the exact section number of the requirement doc.

Attachments/References: This field is useful for complex test scenarios in order to explain the test steps or expected results using a Visio diagram as a reference. Provide the link or location to the actual path of the diagram or document.

Automation? (Yes/No): Whether this test case is automated or not. It is useful to track the automation status when test cases are automated

ISTQB Exam Questions On Equivalence Partitioning And Boundary Value Analysis