How To Write Test Cases And Bug Reports & Amp; What Are Its Main Components
An INFJ personality wielding brevity in speech and writing.
In this article, we are going to learn about test cases and bug reports and how to write really good ones so that it helps the testers and developers involved in the process.
What is a test case?
A test case is a set of actions to verify functionality or feature in a software application. It contains specific tests, test data, precondition, postcondition, etc. Some of the most popular test case management tools are Quality Center, JIRA, etc. In fact, many companies still use excel sheets when it comes to writing test cases.
How to write test cases?
Writing test cases entirely depend on what is being measured by the test case. By sharing test cases with testers and developers, it is possible to accelerate the testing process, but most of it depends on how well test cases are written.
Below are some of the integral parts of a test case.
Step 1: Test case ID
All the test cases should have a unique ID that can be used to identify them. Assigning a test case ID makes it clear for the developer to take care of the issue.
Step 2: Test case description
Describe in detail about the unit, feature and function which is being tested or verified.
Step 3: Assumptions/Pre-conditions
In this step, you will outline all the conditions that are supposed to be met before test case execution. For example, one of the conditions could be that only an email of an organization will be allowed.
Step 4: Test data
It refers to the variables and their values which are in the test case.
Step 5: Steps for execution
Do remember that these steps are executed from the perspective of an end user, so they should be easily repeatable. For example, logging into the portal could have the following steps.
- Open the portal using the URL or internal link
- Enter username
- Enter password
- Click ‘login’ or ‘submit’.
Step 6: Result
It shows the result that you can expect after the test case step execution. When you enter the right login information, what is the expected result and where does it take the user.
Step 7: Result and post-conditions
We can determine the test case based on whether the right values have been input or not. The post-condition is what can occur as a result of the execution steps, whether they will be able to login or sent to a page where they are asked to input the information again.
Step 8: Pass or Fail
It determines the pass/fail status depends on how the expected result and the actual result compare to each other.
Best practices for writing good test cases:
- Test cases have to be simple and transparent: The test cases should be as simple as possible. Make sure you use simple language such as ‘Click on the Home page’ or ‘Enter the data’ so that it is easy to understand the steps.
- Create test cases with the end user in mind: The objective of any project is to ensure that it meets the expectation of the end user. A tester must keep the end user in mind while creating test cases.
- Do not repeat test cases: If a test case is required for executing some other test case, you can call the test case by the test case ID in the precondition column.
- Stick to the specifications document: Do not make the mistake of assuming the functionality and features of the software application.
- 100% coverage: Ensure that you write test cases to check all the software requirements mentioned in the specifications document.
- Name the test case IDs so that they can be easily identified while tracking defects or identifying a requirement.
- Get the test cases reviewed by your colleagues.
What is a bug report?
Writing a good bug report increases the chances of it getting fixed. If the bug is not reported in the right manner, then it will be ignored by the developer saying that it was not clear.
How to write a good bug report?
A good bug report has to be specific, informative and reproducible.
Specific- When you are reporting the bug, make sure you don’t dawdle from the issue by writing things that are not necessary. Be specific. Drive straight to the point.
Informative- Make sure that you assign a unique number to each of the bugs in your report. It helps with identifying the bug record. When you use an automated bug reporting tool, a number will be assigned automatically.
Reproducible– If the bug cannot be reproduced, then it cannot be fixed at all. Make sure that the bug is reported in a step-by-step manner. There are times when it is not possible to reproduce the bug as is, in such a case, you should mention the periodic nature of the bug while mentioning it.
Test the bug on similar modules– Developers are known to use the same bug for similar modules. In that case, you will find the bug appearing in other modules as well. It is even possible to find a more complicated version of the bug on a different module.
Write clearly– Before you click on the submit button, it is imperative that you re-read the bug report at least three times to make sure that it is correct. The words that you use should be simple, clear and easy to understand. Try to avoid jargon, unless absolutely necessary.
What are the components of a bug report?
Below is a sample bug report that can be used for effective reporting.
Tester– Name and email address.
Product– The product in which the bug was found.
Version– The version of the product in which the bug was found.
Component- Major sub-modules of the product
Platform- In which hardware platform was the bug found? PC, MAC, HP, Sun, etc., are some of the platforms.
Operating system– While Windows, Linux, Unix, etc, are operating systems, make sure that you mention which OS version it is. Without knowing the exact platform, it can get difficult for the developer as the bug might behave differently according to the environment in which the application is being used.
Priority- The priority of bugs are usually set in the format P1 to P5. P1 is the bug with the highest priority while P5 is a bug that doesn’t require immediate attention.
Bug severity- The impact of the bug can be described in many ways.
Blocker– You cannot do more testing on this.
Critical– This bug can cause the application to crash.
Major– It affects the application severely.
Minor– They have little impact on how the app functions.
Bug status – When you are logging into the bug tracking system, the bug status will be assigned as ‘New.’ After this, the status of the bug keeps changing- fixed, verified, reopen, cannot fix, etc.
Assign to: Mention the email address of the developer.
Describe the issue: Write a brief about the bug so that it is easy for the developer to understand the issue.
Conclusion:
Your bug report should be of high quality as there is a lot riding on it. Imagine going through a different problem than the real one because the bug report wasn’t written clearly. There should be clear communication between the testers and developers so that both of them know what to expect from each other. While writing a good bug report is the responsibility of a tester, the developers should also convey their guidelines if any.
Looking to improve your software testing? Take a look at Zuci’s software testing services and see how you can leverage Zuci for your business needs.
Related Posts
