How to write test case appropriately & efficiently.

1. TEST CASEWRITING

2. What is Test Case?
■ A test case is a document, which has a set of test data,
preconditions, test steps, expected results and post conditions,
developed for a particular test scenario in order to verify compliance
against a specific requirement.
■ Test Case acts as the starting point for the test execution, and after
applying a set of input values; the application has a definitive
outcome and leaves the system at some end point or also known as
execution post condition.
■ The process of developing test cases can also help find problems in
the requirements or design of an application.
■ In general we can say that a test case tells us what need to be done
to test a system. It gives us the steps which we execute in a system
using the input data values which we enter in the system, it also
gives us the expected results which should come when we execute a
particular test case.

3. Issues to remember while writing test case
As far as possible, write test cases in such a way that you test only one thing at a time. Do
not overlap or complicate test cases. Attempt to make your test cases ‘atomic’.
Ensure that all positive scenarios and negative scenarios are covered.
Language:
– Write in simple and easy to understand sentences.
– Use active voice: Do this, do that.
– Use exact and consistent names (of forms, fields, etc.).
– Avoid writing multiple and complex sentences.
– Make sentences specific and to the point.
– Write relevant values. (for test data)
– Avoid redundant sentences.

4. CHARACTERISTICS OF A GOOD TEST CASE
– Accurate: Exacts the purpose.
– Economical: No unnecessary steps or words.
– Traceable: Capable of being traced to requirements.
– Repeatable: Can be used to perform the test over and over.
– Reusable: Can be reused if necessary.
– Simple: Test steps should be simple and easily understandable.
– Objective: Test case should be objective and should only give the specific outcome. One test case should not
give multiple outcomes.
– Relevant: Test case should not be irrelevant and should be within the context of the system.
– Duplication: Test case should not duplicate other test cases.
– Dependency: Test case should not depend on other test cases.
– Correspondent: Test case should follow the preconditions and test data.

5. Resources
■ The resources that are generally used for writing test cases are:
– Business Requirements Document (BRD)
– Functional Requirements Document (FRD)
– System Requirements Specification (SRS)
■ A good test case cover the aspect of the requirement described in these documents and
checks whether the purpose of the requirement is met successfully or not. A good test case
ensures that the goal of a particular requirement is met in the way as it is told. That is,
besides checking whether the requirement is fulfilled or not, a good test case also maintains
the flow of the process to reach the goal of that particular requirement via its test steps.
■ There can be test cases that are outside of the context of these documents as documents
sometimes lack some specifications of the application. But test cases must be within the
context of the application.

6. Importance of Test Case
Test cases organize the whole testing process. If the test cases are prepared keeping in
mind the requirements of a particular system then they really helps a lot in checking
whether the requirements are fulfilled or not. While doing ad hoc testing, one may neglect
or skip functionality or a bug which will definitely be caught when the system or site will be
live or when it will be tested from the client’s end and it is going to affect the company’s
credibility.
We have heard from Big Brains that no software is bug free. But care should be taken so
that all the possible bugs are eliminated from the system before it goes live. Test cases
help a lot in this. With the help of proper test cases, a Quality Assurance Engineer should
make sure that the system’s features & functionalities are working fine and are bug free.

7. Ideal Test Case Steps
Test Case Id.
■ Unique Test Case Identification Number. This id can be combined of many sections.
■ Example: SF_MIS_LOGIN_001
Use Case ID
■ Unique Use Case Identification Number from the requirement documents like BRD
or SRS.
Test Objective
■ What is the main purpose or target of this test case.
■ Example: Suppose you are going to test the login page. So one of the Test Objective
can be like “To test the login page’s remember me option”.

8. Pre-Conditions
■ Sometimes there can be some dependency to execute the test case, then that dependency can be
considered as Pre-conditions.
■ Example: If any system provides report & gives an option to export it in an excel sheet, then
configuring excel support in the device is a pre-condition to test this option.
Test Data
■ Test Data is some pre-defined or fixed data to check any option or test case.
■ Example: A numeric field only takes even number. So before start testing process we can fix the
inputs like 2n+2. So 2, 4, 6, 8… are the test data for this test case.
Test Steps
■ Details of the procedure to continue the test case process.
■ Example: In any system the objective of the test case is “Appears application splash screen as the
first screen”. So the Test Steps can be
1. Launch the application.
2. Check if texts are appearing correctly as referred to the UX Specification document.”

9. Expected results
■ The output of the process we have done while executing test case.
■ Example: If the process is “2*2”, then the expected result would be “4”.
Actual results
■ The result system gives a tester after executing a test case.
Cycle
■ A system can be tested several times. So tester can maintain a cycle number for better
understanding the changes of the testing process.
Date of execution
■ The day of executing the test case
Tested by
■ Name of the tester

10. Test Status
■ Passed or Failed. When “actual results = expected results” the executed test case is
passed. Otherwise failed.
Attachment
■ Taking the screenshot or make the video of the process while testing related with the test
case. It is better to mark the fault point on the image or video.
Defect Severity
■ The degree of impact that a defect has on the development or operation of a component or
system. This step is for failed test cases. There is several level of the failure for any test
case. These levels are
a) Critical, b) Major/High, c) Medium, d) Minor/Low.

11. Critical: The defect affects critical functionality or critical data. It does not have a workaround.
Example: Unsuccessful installation, complete failure of a feature, Showing
development level pages on the front end.
Major/High: The defect affects major functionality or major data. It has a workaround but is
not obvious and is difficult.
Example: A feature is not functional from one module but the task is doable if 10
complicated indirect steps are followed in another module/s.
Medium: The defect affects minor functionality or non-critical data. It has an easy
workaround.
Example: A minor feature that is not functional in one module but the same task is
easily doable from another module.
Minor/Low: The defect does not affect functionality or data. It does not even need a
workaround. It does not impact productivity or efficiency. It is merely an inconvenience.
Example: Petty layout discrepancies, spelling/grammatical errors.

12. Defect Status (QA)
– Open / Reopened / Retest In Production / Closed
– Open: Initial status of any failed test case. Generally it occurs in cycle 1 testing.
– Reopened: If the test case again fails in cycle of retesting, then the defect status will
be changed into “Reopened”.
– Retest In Production: Testing process on going state.
– Closed: When the failed test case passes, then the status will be changed into closed.
Resolution Status (developer)
– This field will be updated by the developing team. The status can be Fixed / Future/ In-
Progress/ Not A Fault.
– N.B.: Only this field will be used by the developing team.

13. Date of closing
■ The date when a failed test case finally passed.
Comment
■ If there is anything more to say about the test case. It can be used by both QA & Developing
team.