Writing an effective and easy to understand test cases is a main responsibility for a test engineer. An organized test cases document is a easy way for every person in a software development to understand test case design.
For writing an effective test cases you should follow these guidelines :
Guidelines/Best practices/Tips for writing test cases :-
1. Test cases need to be simple and transparent :
Test case writing should be organized, step-by-step, and easy. A simple test case can be understand by anyone.
Name of the test cases should be easy and simple, which is able understand by anyone. Like this example,
"Facebook" is a project name, which has different modules like "Login", "Homepage", "Settings", "Profile" etc.
So the test cases name should be like,
- TC001_Facebook_Login page_Login functionality....
- TC002_ Facebook_Settings_changing password.....
So its easy for everyone to understand test cases just by its name.
2. Create Test case with End User in mind :
End User is the last step of the software development, His reviews helps in software improvement. Always we have to make software user friendly so as test cases.
Test cases should be user friendly. If end user uses this application, so which objects of application he/she will use, how he/she will use. Test engineer should think like end user and create test cases as end user perspective.
3. Avoid Test case repetition :
Test case repetition is a major issue in software testing. Even experienced test engg. sometimes made mistakes. But as test engg. you should not repeat any test case, because if you repeat that means:
- You have to execute that test case twice.
- If test execution got issue, so you have to report bug twice.
- That means developer have to check that issue twice.
- Your time, dev. time and whole software development process time wasted twice.
If developer have to fix an issue twice, so he will may get frustated and he might will report against you.
4. Do not Assume :
Never assume expected results. Every conditions, or expected results are already declared in the test plan documents(SRS,FRS). If there is no expected result is declared, so you should reported the situation to the test lead.
5. Ensure 100% test coverage :
100% test coverage is almost impossible, but you should cover atleast 95% software for testing.
For ensuring that you cover all the objects in the document, you should use test case design techniques for functional areas to find every possibilities of testing. Find as many bugs as you can, that is your job. Use Requirement Traceability Matrix to ensure no functions/conditions is left untested.
6. Test cases must be identifiable :
Test cases should be simple and easy. Whenever we have to find the test case so we identify test case easily by its name.
Name the test case id such that they are identified easily while
tracking defects or identifying a software requirement at a later stage.
7. Implement Testing techniques :
It's not possible to check every possible condition in your software
application. Testing techniques help you select a few test cases with
the maximum possibility of finding a defect.
- Equivalent Class Partitioning(ECP) : Classes of input conditions called equivalence classes are identified such that each member of the class causes the same kind of processing & output to occur.
- Boundary Value Analysis(BVA) : The test cases explore the boundary condition have a higher probability of detecting error.
- State Transition Technique : This method is used when software behavior changes from one state to another following particular action.
- Error Guessing Technique : This is guessing/anticipating the error that may arise while testing. This is not a formal method and takes advantages of a tester's experience with the application.
After creating test cases, get them reviewed by your colleagues. Your peers can uncover defects in your test case design, which you may easily miss.
These guidelines are very important for perfect test case writing.
No comments:
Post a Comment