DEV Community: Wahome Stephen

Understanding Bug Reports

Wahome Stephen — Wed, 05 Aug 2026 19:20:48 +0000

If you are new in the QA space, you may not really know what a bug report is. While this is a common term, many fail to dissect what it really is and what an effective bug report should really look like. In this blog we discuss everything you need to know about bug reports.

A bug report is a document/ record outlining defects in a software. An effective bug report should tell a developer what went wrong, specific environment where this happened and how to reproduce this issue for further diagnosis.

Priority Vs Severity

When writing a functional bug, we must first understand severity.
Simply out, severity means "How bad will the defect affect the functionality/ performance of a system?"
Not to be confused with priority which simply answers the question - How fast/urgently do we need to fix the defect?

Severity is a technical assessment of the defects impact ranging from minor to critical issues. This is typically determined by QA engineers
Priority on the other hand is a business-driven parameter meant to determine order in which defects should be fixed - influenced by deadlines, customer impact and strategic considerations. This is usually set by the product owner.

An effective bug report should have;

Title

This is a summary of the bug and contain necessary information to understand the defect without having to open the bug report.
This information includes;

What happened
Where the bug occurred
When the bug occurred
How the bug occurred or under which condition this was triggered

Steps to Reproduce

Document a step by step guide to reproduce the defect. This should be numbered and clear

Expected Result

Outlines what should have happened. Think of it as what should have happened if no bug existed.

Actual Result

Define what happens after the last action. This does not have to be similar to the title. However, to ensure it is effective, this should be formed using one or more sentences.

Environment used

Indicate the environment in which this defect occurred i.e. production, sandbox, development...
Include the browser used e.g. Chrome, Microsoft Edge, Safari
Operating System e.g. Windows, Linux, MacOS
Device used

Evidence

This includes screenshots, videos and error logs

Common pitfalls when creating bug reports

Title

Like mentioned earlier, a bug report title should summarize the bug without the reader having to read the entire report to understand what the bug is.

Describe what is happening not what is not happening
Avoid statements like does not work and focus on actual behavior
To come up with a descriptive title, put yourself in the shoes of someone who has never tested the website, who doesn't know what page you are on and what you did.

Exemplary bug titles

~~Checkout does not work~~
Error message is displayed on the checkout page when submitting an order ✅
~~Cart page displays a 404 error~~
Cart page displays a 404 error when opened by a logged-in user ✅

Steps to reproduce

The first step should contain an indication to access the URL of the customer environment provided.

Exemplary Good Steps

Go to http://www.examplewebsite.com
Enter any search query in the top-right search bar (e.g. “San Francisco”)
Click on the “Search Now” button
Scroll down and click on "Sort by"
Select the option "Sort by price: High to Low"

Expected Results

Should contain a short description, but for complex bugs, additional information is needed.

Great expected result

The Checkout page should be loaded successfully. ✅
~~The user should be redirected correctly to the Checkout page, where he should be able to add shipping and payment info and place an order.~~
"T-Shirt" should be added to the cart so that the user can proceed with the order. ✅
~~The product “T-Shirt” should be successfully added to the cart. The user should not encounter errors like “Error 500” and should be able to check out any items in their cart.~~

Actual Results

This should be precise and don't be too general

The actual and the expected results must never be just the opposite of each other.

Should include further details on top of the title such as scenario information, examples and results obtained while performing the steps to reproduce the bug.

Effective Actual Result

"Error 500 - Internal Server error - Sorry something went wrong" is shown to the user after he tries to proceed to the Checkout page. ✅
~~Error shown on the Cart page after clicking on the Checkout button.~~
An "Unexpected Error" error message appears in the top right corner of the PDP, and the product is not added to the Cart. ✅
~~The user cannot add a product to the Cart, an error is shown.~~

Environment Used

Include only one device or browser when you are reporting the bug, and upload only attachments for it.
If you are able to reproduce the bug in other devices or browsers, please mention this in your Actual result.

How to create a test case ID?

Wahome Stephen — Wed, 05 Aug 2026 09:49:26 +0000

Writing Effective Test cases

Wahome Stephen — Wed, 05 Aug 2026 09:40:31 +0000

Writing effective test cases ensures that software functions correctly and meets requirements. But before then, what is a test case?
A test case is a documented set of conditions, inputs, actions and expected results used to verify that a feature/ functionality in a software works as expected.
Test cases help to

Validate expected functionality of a feature.
Detect defects early in the SDLC - thus reduce future cost and effort.
Improve overall software quality by ensuring reliable and accurate performance.

Flow of Test Case

Well executed test cases should follow a properly laid-out flow.

Define test objectives - What to test and what to expect
Test case design - From the identified test objectives, create detailed test cases to validate the requirements. Test cases should also have test data.
Test Execution - Run the test cases against the application.
Results comparison - Capture the expected Vs actual results.
Defect reporting - From step above, report any issues found.
Re-test - This step is only necessary if we captured any defects. This is a confirmation test done to validate a fix.
Test case conclusion - Mark the final status as (Pass/ Fail)

Structure of a Test case

To ensure clear and consistent test cases across a team, teams should use a defined template.

A proper test case template is divided into these two broad sections

Header - Contains the tester name, description and prerequisites
Body - Contains test steps, test data, expected and actual results

More precisely ensure that your test cases has the following main parameters

Test Case ID - This should be a unique identifier to the test case. Structure of a good test case ID
Description - This is a high level overview of what the test case is testing/ validating
Preconditions - Conditions that must be satisfied before test execution
Post conditions - Conditions that must be satisfied after completion of a test case.
Test Steps - Sequential step-by-step actions to perform
Test Data - Input values to use during testing
Expected Result - How should the feature/ functionality work
Actual Result - How is the feature is question working?
Status - This is usually the final result which can be a (Pass/ Fail) depending on the comparison between expected and actual results
Comments - This indicates the remarks/ observations made.

Stages of Writing Test Cases

Now that we've discussed the structure of test cases, our next question is when should we write test cases? Several approaches can be used.

Before Development - This is an important approach used in shift-left testing. Test cases are written directly from requirements ensuring early quality validation and defect prevention.
During Development - Written alongside coding to test modules as they are built
After Development - Created before release to verify completed features and overall functionality.

Test Case Management Tools

To better team collaboration, it is important to have test cases in a central place. Traditionally, and still today, QA teams used excel. While it still serves the purpose, other tools offer better collaboration and ROI in the long run.
TestLink - Open source with excellent bug tracking integration
Xray - Provided by Jira out-of-the-box offering support for both manual and automated testing with strong traceability.
TestRail - Manages test cases, plans and runs with detailed reporting and team collaboration features
PractiTest - Offers E2E test management with reporting and integration capabilities.

As we wrap up, it is important for test teams to develop high quality test cases

Improve test coverage - Ensures all functionalities and scenarios are properly tested
Early Defect Detection - Detailed test cases written before development help identify bugs at an early stage reducing cost and effort.
Ensure consistency across a team
Enhance Documentation - Acts as a reference for future testing and maintenance
Saves Time and Effort - Reduce rework and improve testing efficiency

Testing Lifecycle

Wahome Stephen — Tue, 04 Aug 2026 20:53:59 +0000

STLC or Software Testing Lifecyle is an essential part of the SDLC. Think of it as a set of steps taking in order to effectively test a software product. Its goal is verification and validation of the application i.e. to ensure that an application meets quality standards and user expectations.
Verification - Ensuring that an application meets specified requirements (Did we build the product right?)
Validation - Checking whether the system meets user and stakeholder needs in its operation. (Did we build the right product?)

Why do you need the STLC?

Provide a defined approach to plan, execute and manage testing
Help in early detection of defects thus improve software quality
Ensure complete testing coverage and proper reporting of test results

Phases of STLC

Requirements Analysis
Test case planning
Test case development
Test Environment setup
Test execution
Test closure

Requirements Analysis

This is the first step in the STLC. In this step, a tester aims to understand what needs to be tested.

Review the Software Requirements Document (SRD) and other related docs
Interview stakeholders to gather information
Separate confirmed facts from assumptions, vague terms, contradictions, missing rules and constraints
Identify non-functional requirements;

Usability - Focus on UX, accessibility (A11Y) and intuitive interaction
Performance - Focus on the systems speed and responsiveness and resource utilization
Security - Focus on access control and data breaches

Identify risks and challenges that may impact testing. What is the worst that might happens when testing a feature is not achieved (We will use this to set priority Risk based testing)

Test Planning

This is the most important step in the STLC. Here the overall strategy and plan is created.

Define test objectives and priorities
Develop a test strategy; select manual and automated testing techniques
Identify entry and exit criteria for each phase
Entry criteria - Preconditions that must be met before starting a testing phase
Exit criteria - Conditions that must be met before completing a testing phase
Estimate time cost and resources required to complete the test
Assign roles to the test team
Incorporate risk based testing. Based on priorities set on phase 1, prioritize critical functionalities to test first

Test Case Development

In this phase, testers prepare test data and design detailed test cases.

Identify what test cases will be developed
Write clear, concise and easy to understand test cases
Create test data and test scenarios to be used in the test cases identified above
Identify expected results for each test case
Review and validate test cases
Update the requirement traceability matrix (RTM) to map requirements to test cases

Test Environment Setup

This step aims to define the hardware, software and network conditions under which testing will be executed
Install and configure required software, tools and databases
Set up servers, browser, OS and devices to use
Prepare access credentials and permissions
Validate the environment readiness before test execution

Test Execution

This is the step where we execute the test cases we prepared earlier.

Run both manual and automated test cases(where possible)
Log defects with appropriate details needed to reproduce them
Retest defects
Perform regression testing
Collect and analyze test results
Document and share test reports

Regression Testing is a type of testing done to ensure that recent code changes haven't affected existing functionality
Confirmation testing/ Retesting is a type of testing done to ensure that previously reported bug have been fixed in the latest build/release

Test Closure

This is the last step in the STLC. Testing activities are completed and documented

Prepare a test summary report
Ensure that all defects are tracked and closed.
Clean up the test environment
Archive test cases, data and reports
Conduct a retrospective Retros are mainly done in Agile developments to identify lessons learnt in a sprint. Multiple questions can be asked during this ceremony but we can categorize these into 3 key questions
What went well?
What didn't go well?
What can we do differently next time?
Share knowledge with stakeholders

To wrap it up, STLC is an integral part of SDLC.
STLC defines all steps taken when testing a software. Its focus is validation and verification of a software. This process is done primarily by QA team.
SDLC on the other hand defines all phases of end-to-end software development from requirements gathering to deployment and maintenance. Its focus is building a software. This process involves multiple stakeholders including developers, business analysts, project managers and the QA team.