A Simplistic Approach to Writing Test Cases – The Black Box way
Article by: Swastika Nandi – a guest publisher of the article.
Before gathering knowledge on how to write test case methods, we have to know what basically a test case is! Have you ever noticed that every one of us is a tester in one way or the other? So task to write test cases becomes all the simpler, as we all know what to test and how to test.
The following discussion depicts simple pointers on test case writing methods.
Here are some points on writing test cases and test case procedures.
What is a test case?
A test case is basically a comprehensive form of inputs, events or actions and an expected outcome of that action. Test case is a method which helps to determine if any condition or feature is working correctly or not�.
Does the above lines sound complicated �then think of test case as
a set of actions to achieve desired results. For e.g. what will you do when buying 1 kg of apple from a shop, how you will ensure that the ones you are choosing are the quality ones. Just think about simple steps and you will soon realize that writing test cases is so very simple.Why test cases?
Writing test cases has come into picture to validate the coverage effectiveness of testing of an application. Basically test cases brings different sort of standardization. Though different format of test cases are followed by different industries, there is IEEE 829 standard: test design specification template for writing test cases. Test case provides to follow the particular conditions to test an application or software instead of adhoc testing.
The Test Design Specification Template contains the following fields:
1) Test design specification identifier
2) Features to be tested Approach
3) Refinements Test identification Feature
4) Pass/Fail criteria
How to write test cases?
While writing test cases, we should notice that all the test cases should be easy understandable so the one who is unknown to the application can also execute the test steps. Test case should be simple always. For an application or software to be tested, basically we have to cover different types of test cases including normal or success flow, exceptional or negative flow, alternative flow and boundary value test cases.
Different levels of test cases in a SDLC could be of the following: (Black box)
1) Functional Standalone Test Cases (Functional Testing)
2) Functional Integrated Test Cases (System Integration Testing)
3) System Testing
4) User Acceptance Testing
Apart from the above, there could be Non Functional test cases for vulnerability, load, stress, volume etc, network, database and other performance related test cases and Operational Readiness test cases.
The level of test cases in order to avoid duplication of efforts:
1) Use bottom up approach (start from the lowest component level)
2) Derive the functional test case from Use case or SRS module wise.
3) Identify the interfacing references to get the integration test cases.
4) Have a higher level composite systems test case to test the system�s functionality end to end.
5) For each build released, most critical features covering all the functionalities, a smoke test or build validation regression suite can be built based on the priority of the test cases set at the time of creation.
Post UAT there might at time ORT or operational readiness test cases written and executed which comprises of network, bandwidth, load stress (Non functional requirement) and critical functions and documentation for maintenance.
Lastly � check what you intend to test and what is it that you are testing, if it matches “Bingo!!!” you are on the right track �.
About the Author: Swastika Nandi is a guest publisher of the article & is solely responsible for the ownership of its contents.
Many more Flambuoyant Articles on Test Design