How to write an effective test case
Test Case should be simple and easy to understand. A well-written test case should allow any tester to understand and execute the test, this will save you time and effort further down the road.
Aim For 100% Test Coverage -
The whole point of writing good test cases is providing test coverage as widely as possible. Together with all the test case, a must aim to cover as many features, user scenarios, and as much of the workflow as possible.
Additionally, the test coverage to verify the events in EventStore both success & failed events (in automation, expected events can be written in comments), verify the ElasticSearch for new or changes to the indexes, Minio if required to validate the media files, verify diagnostics logs where ever applicable
Traceability -
Map test cases to user stories. This way, if your test case execution has unexpected behaviour or results, it can be traced back to the user story to see if any changes were made to the user story, or if it’s a valid test case. Also, when the user story/requirement changes, you can update/change the mapped test cases appropriately.
Use a Strong Title -
A good test case starts with a strong title. As a best practice, it’s good to name the test case along the same lines as the module that you are testing.
The best test case title — is a short yet complete sentence that answers 3 simple questions:
what’s an object?
what’s it’s behaviour?
at what condition?
For example, if you’re testing the login page -
A good test case titles are :
Login with valid credentials
Login with invalid credentials
Login with empty credentials
A bad test case titles are :
System successfully authorizes user who logged in with valid credentials and redirects to Home Page
System does not allow to login to user who tried to log in with invalid credentials and displays error message
System does not allow to login to user who tried to log in with empty credentials and displays validation error message
Types of Test Cases -
In order to efficiently cover the functional tests, for any application you need to cover below types of test cases:
Positive cases
Negative cases
Field Validation cases
A negative case is as important as a positive case. Make sure that for each scenario you have atleast two test cases- one positive and one negative. The positive one should cover the intended or normal flow and the negative one should cover the unintended or exceptional flow.
Correct Sequence -
Check whether the sequence of steps in the test is absolutely correct. A wrong sequence of steps can lead to confusion.
Feasible Test Data -
Ensure that the test data specified in TCs is feasible not only for actual testers but is according to the real-time environment too.
Shared Test Steps –
Any re-usable test steps should be written in shared test steps, making it easy to use a set of steps in multiple tests and reduce maintenance effort when steps change.
Refer : Using shared steps when writing test cases
Note -
A step-by step guide on e2e test flow articles E2E Test Flow Articles will help to spread the knowledge across the teams and a central repository guide to refer. It is responsible for individual tester's to create and maintain any new features that team owns. For a good example on how to articles, refer to https://uniphore.atlassian.net/wiki/spaces/RedboxHome/pages/2562774304 .
Include Assumptions and Preconditions -
You should include any assumptions that apply to the test and any preconditions that must be met prior to the test being executed. This information can include dependencies on the test environment and any special setup requirements that must be done before running the test. This information also helps keep the test steps short and concise.
Keep the Test Steps Clear and Concise -
Test cases should be simple. Keep in mind, the person who wrote the test case might not be the same person who executes the test itself. The test steps should include the necessary data and information on how to execute the test.
For example, In the test steps include the breadcrumbs navigation of the request from the Postman -POSTMAN:Licensing->Apply Licences
{{scheme}}://{{host}}:{{port}}/api/v1/Licences
And optionally - Copy the request Json body of the request as a plain text - see below figure.
This is perhaps the most important part of a test case. Keep this section clear and concise, but don’t leave out any necessary details. Write the test case so that anyone can go in and perform the test.
Include the Expected result –
The expected result tells the tester what they should experience as a result of the test steps. This is how the tester determines if the test case is a “pass” or “fail”.
Include the Attachments (screenshots) –
Add the screenshots/ files/ logs of your tests in the attachment (ex., a screenshot from the Postman with request payload and response) to the test steps. This is to evidence that test is working as expected and helps regression testers to compare side-by-side the results.
Note: Screenshot - Grab the important part of the screen (to include request & response) to keep it minimum. And highlight the important actions which requires attention as per the test step.
For a good written test case, refer to https://redboxdev.visualstudio.com/Nubis/_workitems/edit/40347