Writing test case effectively is one of important parameter in software testing. The test case is a 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 see in different organizations or projects. in this post we will concentrate on one of the ways 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 verifications.
Its totally depends on the application to application which test case writing should get followed. but make sure that, the 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 derive from the 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
- The 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 helps the team to understand the test case.
Make sure that if the test cases require the 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 the test case.
Steps and Expected results:
It is always beneficial to have detailed steps and expected a result of each step. which really helps in test execution. do not write test step which includes a lot of steps and other QAs cannot understand it. to combine the test cases use arrows 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 a similar way, QA can combine the workflow steps and optimize the Test case.
There should be a 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 a test case is passed or failed or blocked or skipped.