Writing test case effectively is one of important parameter in software testing. Test case is core part of software testing and execution of test cases actually decides the quality of the product.
there different ways of writing test cases we can seen in different organisations or projects. in this post we will concentrate on one of the way to write the test cases.
writing test cases is highly dependent on the tester how he/she thinks. many variations we can find in writing test cases such as..
- scenario based test cases
- small test cases ( consider only one verification point per test case)
- combination of above two – which covers scenario and carry multiple versification.
Its totally depends on the application to application which test case writing should gets followed. but make sure that, team should use only one writing style, otherwise it will mess-up your test estimation and execution.
It has been always recommended to write the test cases feature wise and has to derived from Test plan. while writing test cases try to write test cases in 4-5 distinct software testing methodologies.
- User interface testing
- Functional testing
- Integration testing
- Performance testing/Load testing/Stress testing
- Security testing
coming to writing styles: A typical test case should have
- Test Case Title:
- Expected Result for the step
- Additional information
- End result of the Test case. ( Passed/Failed/Block)
Test Case Title :
Test case title should be precise and tells what needs to do. if possible give navigation in title
like , Login : Login button : Login button is disabled after entering UserName and Password.
this always help team to understand about the test case.
Make sure that if the test cases requires to prior state before starting the test case or need data preparation that needs to be mentioned in pre-requisites.
many times it happens, QA can not able to explain the test case in one line. so in summary section QA should put the details about the test case. typically the objective of test case.
Steps and Expected results:
It is always beneficial to have detailed steps and expected result of each step. which really helps in test execution. do not write test step which include lot of steps and other QAs cannot understand it. to combine the test cases use arrors for navigation (>),
- Log-in to <website url> with valid credentials
- Click on XXXXX Link > Click on Edit button > Enter XXXX value in YYYY field.
in similar way QA can combine the workflow steps and optimize the Test case.
There should be come place where QA can put additional information about the test case link document links, QA documents, dependencies RTM links etc. which helps QA to understand the test case and execute it effectively.
at the end execution result, whether test case is passed or failed or blocked or skipped.