Join thousands of students achieving their dreams with expert-led courses.
Join free and unlock everything on EasyShiksha.
Takes less than 3 seconds โ no password needed
Please enter a valid email address.
Checking your emailโฆ
Almost done โ just verify your number so we can send course updates and certificates.
Used only for verification & updates
Incorrect OTP. Please try again.
Takes less than 10 seconds
Please select your country.
Please select your state.
Finding a bug is a normal part of software development. A button may stop responding, a form may accept invalid information, an API may return an unexpected response, or a page may display incorrectly on mobile devices. Discovering the problem is important, but explaining it clearly is what helps a developer investigate and fix it efficiently.
This is where a bug report becomes useful.
A good bug report describes what went wrong, how someone can reproduce the problem, what should have happened, and what actually happened. It gives developers enough information to investigate the issue without repeatedly asking the person who discovered it for missing details.
For students, software testers, interns, and junior developers, learning to write clear bug reports is a practical professional skill. It helps during college projects, software testing assignments, internships, team development, and open-source contributions.
In this guide, you will learn how to write a bug report step by step, understand severity and priority, recognise common mistakes, and use a practical template for your own projects.
A bug report is a structured description of an unexpected behaviour, defect, or failure in a software application.
It communicates a problem to the person or team responsible for investigating it.
For example, imagine you are testing a student registration website. You enter a valid email address and password, click the Register button, and nothing happens. The expected result is that the account should be created or a clear error message should appear. Instead, the page remains unchanged.
Simply saying “registration is not working” does not provide enough information.
A useful report explains the browser or environment, the steps followed, the expected result, the actual result, and any relevant error messages or screenshots.
Bug reports are commonly used in:
Website and mobile application development.
Manual and automated software testing.
API testing and backend development.
College software projects.
Internship assignments.
Product development and quality assurance.
Open-source software contributions.
Not every unexpected behaviour is necessarily a confirmed software defect. Sometimes it results from incorrect configuration, unavailable services, invalid test data, or a misunderstanding of the intended functionality. A good report describes the observed behaviour accurately so the team can investigate it.
A vague report can create unnecessary back-and-forth communication. Developers may need to ask which page failed, what information was entered, whether the problem occurs consistently, or what result was expected.
A detailed report reduces this uncertainty.
Developers need to see the conditions under which a problem occurs. Clear steps make it easier to recreate the same behaviour and investigate its cause.
A report containing relevant logs, screenshots, request details, and environment information can help narrow down possible causes.
Testers, developers, designers, project managers, and other stakeholders may describe the same problem differently. A structured report gives everyone a common reference.
A minor alignment issue and a failure that prevents users from logging in do not necessarily deserve the same urgency. Clear descriptions help the team evaluate the impact.
Bug reports help teams track issues, confirm fixes, identify recurring problems, and prevent previously fixed defects from returning.
Students who maintain clear records of their testing and debugging work can also explain their problem-solving process more effectively. This is valuable when demonstrating practical project experience, as discussed in EasyShiksha's guide to creating verifiable pre-employment work samples.
A bug report does not need to be unnecessarily long. It needs to contain the right information for the particular issue.
The following components form a practical starting point.
The title should describe the affected feature and the observed problem.
Weak title:
“Website issue”
Better title:
“Registration form does not submit when all required fields are valid”
The second title tells the reader which feature is affected and what is going wrong.
Avoid vague titles such as “Error,” “Please fix,” or “Something is broken.” They make it difficult to identify the issue when reviewing a long list of reports.
Environment information describes where the issue occurred.
Depending on the application, useful details may include:
Operating system.
Browser and browser version.
Device type or screen size.
Application version or build.
Testing or deployment environment.
API endpoint or test environment, when relevant.
For example:
Environment: Windows 11, Chrome, desktop browser, test environment.
Include details that could affect the behaviour. You do not need to record every environmental detail for every minor issue.
For mobile applications, device model, operating system version, and application version may be particularly useful.
Preconditions describe what must be true before someone attempts to reproduce the bug.
For example:
The user is logged in.
A test account has been created.
The shopping cart contains at least one product.
The application is connected to the test database.
If a problem occurs only for a particular account type or data condition, mention that explicitly. Otherwise, a developer may test the wrong scenario and fail to reproduce the issue.
These are the exact actions needed to trigger the problem.
Write them in a logical sequence that another person can follow.
For example:
Open the registration page.
Enter a valid name and email address.
Enter a password that meets the displayed requirements.
Complete all other required fields.
Click the Register button.
Observe the page.
Avoid steps such as “use the website normally” or “try registering again.” They do not identify the precise actions that caused the failure.
Use numbered steps when order matters. If the issue depends on a specific value, state that value or provide safe test data.
Explain what should happen according to the requirements or intended behaviour.
Example:
“The application should create the account and display a success message, or explain any validation issue that prevents registration.”
Expected behaviour should be based on the documented requirements, agreed design, or clearly established product behaviour—not simply personal preference.
Describe what happened instead.
Example:
“After clicking Register, the button remains in the loading state and no confirmation message appears.”
Keep this section factual. Avoid guessing at the cause unless you have evidence supporting that explanation.
Evidence helps developers understand and investigate the problem.
Useful evidence may include:
A screenshot showing the incorrect interface.
A short screen recording demonstrating the steps.
Browser console errors.
Network request and response details.
Relevant application logs.
API response status and error message.
Test data that safely reproduces the issue.
Remove passwords, access tokens, personal information, and other sensitive data before sharing evidence.
A screenshot can show what went wrong, but it may not explain why it happened. For issues involving API requests or asynchronous behaviour, logs or network details may be more useful than an image alone.
Severity describes the impact of the defect. Priority describes how urgently the team should address it.
They are related but not identical.
For example, a serious defect affecting a rarely used internal feature may have high severity but a different priority from a slightly less severe problem affecting every customer during a major release. The final decision depends on business impact, user needs, and the team's release plans.
Do not assign labels randomly. Explain the impact and follow the team's agreed classification system.
Suppose you are developing a task management application. Users can create tasks, edit them, and mark them as complete.
During testing, you notice that marking a task as complete changes its appearance, but refreshing the page makes the task appear incomplete again.
Here is how you could prepare the report.
Avoid writing “Task status problem.”
Use a title that identifies the failure:
Title: Completed task reverts to incomplete after page refresh
Environment: Web application running in the test environment, Chrome desktop browser.
If the issue occurs only on a particular browser or device, include that information.
Open the task management application.
Create a new task.
Mark the task as complete.
Confirm that the interface displays the completed status.
Refresh the browser page.
Check the task status again.
Expected result: The task should remain completed after the page refresh, assuming the application is designed to persist task status.
Actual result: The task appears incomplete after refreshing the page.
This comparison helps the developer distinguish between a display issue and a possible data-persistence issue.
You might include a recording showing the task changing status before the refresh and reverting afterward.
If you are debugging the application yourself, you could also inspect the relevant API request, browser storage, database record, or application logs, depending on how the application was implemented.
Impact: Users may believe their task updates were saved when the status does not persist after refreshing.
Suggested severity: Moderate, subject to the team's severity definitions and the importance of task persistence.
Notice that the report describes the observed problem without immediately declaring that the backend or database is responsible. Further investigation is needed to identify the root cause.
You can use the following template for college projects, internship assignments, or software testing practice.
Bug ID: Assigned by the tracking system, if applicable.
Title: A short description of the problem.
Environment: Operating system, browser, device, application version, or relevant test environment.
Preconditions: Required account state, data, configuration, or other setup.
Steps to reproduce:
First action.
Second action.
Action that triggers the issue.
Expected result: What should happen.
Actual result: What happened instead.
Evidence: Screenshot, recording, logs, console output, or network details.
Severity: Impact of the defect based on the team's definitions.
Priority: Urgency of fixing the issue, if known or assigned.
Reproducibility: Always, sometimes, or unable to reproduce under current conditions.
Additional notes: Relevant observations, workarounds, or related issues.
You can copy this template into your team's issue tracker or adapt it to the format required by your instructor or organisation.
For a very small project, some fields may be unnecessary. In a larger engineering team, the issue tracker may automatically capture information such as the reporter, creation date, status, and assignee.
Severity helps communicate how seriously a defect affects the application. Teams may use different labels, so always follow the definitions established by your project or organisation.
A common illustrative classification is:
| Severity | Typical impact | Example |
|---|---|---|
| Critical | A major essential workflow is unavailable or a severe system failure occurs | Users cannot access the core service |
| High | Important functionality fails without a reasonable workaround | Users cannot complete a required payment |
| Medium | A feature behaves incorrectly, but the application remains usable | Saved task status does not persist |
| Low | A minor issue has limited functional impact | A non-essential icon is slightly misaligned |
These examples are not universal rules. For example, an incorrect price displayed to users may have much greater impact than an ordinary interface defect, even if both involve only one page.
Severity should reflect actual consequences, not how difficult the bug was to find or fix.
Consider two issues:
A minor spelling error appears on a frequently visited public page.
A serious defect affects an administrative function used infrequently.
The team may choose to fix the spelling error quickly because it is visible to many users and easy to resolve. The administrative defect may require more investigation but still carry greater functional severity.
This illustrates why severity and priority should not be treated as interchangeable. Report the impact accurately and allow the responsible team to make prioritisation decisions.
The basic structure stays the same, but the evidence and technical details change depending on the system.
For website issues, include the affected page, browser, device or viewport size, user actions, and screenshots when useful.
For example, if a navigation menu disappears on a mobile screen, specify the screen size and the steps that make it disappear.
If the issue concerns layout, describe the visible problem precisely. “The menu is broken” is less helpful than “The navigation menu overlaps the page heading at a viewport width of 390 pixels.”
API reports should include the endpoint, HTTP method, safe request payload, response status, response body, and relevant authentication or permission conditions.
For example:
“Sending a valid update request to the task endpoint returns HTTP 500 instead of the expected success response.”
Include request and response details where permitted, but never share real passwords, bearer tokens, or confidential customer information.
A request that fails because of an invalid payload should also be distinguished from one that fails despite valid input.
Database issues may require information about the affected record, the operation performed, the expected data change, and the result observed afterward.
Use test records where possible. Do not attach entire production database exports when a small, anonymised example is sufficient.
For mobile applications, include the device model, operating system version, application version, network conditions when relevant, and whether the problem occurs after a specific sequence of actions.
A problem that appears only after switching networks or returning from the background may require those exact conditions to be included in the reproduction steps.
Performance reports should describe the operation being measured, the approximate duration, the environment, and how often the issue occurs.
For example, rather than saying “The page is slow,” report that “The dashboard takes approximately eight seconds to display its main content in the test environment under the stated conditions.”
Use measured observations rather than estimates presented as exact results. If you have performance traces or logs, include relevant evidence.
Even when someone finds a genuine defect, the report may be difficult to use if essential details are missing.
Writing vague titles: Titles such as “Error in page” do not explain the affected feature or failure.
Combining unrelated problems: If two defects can be investigated and fixed independently, create separate reports unless your team's process says otherwise.
Skipping reproduction steps: A developer should not have to guess which actions triggered the issue.
Confusing expected and actual results: State both clearly so the difference is easy to understand.
Guessing the root cause: Report observed behaviour first. A suspected cause can be included separately when supported by evidence.
Attaching excessive evidence: Provide relevant screenshots, logs, or recordings rather than a large collection of unrelated files.
Ignoring environment details: Some defects occur only on particular browsers, devices, versions, or configurations.
Using severity labels without context: Explain the user or system impact instead of choosing “critical” simply to attract attention.
Sharing sensitive information: Remove credentials, private user data, and confidential details from screenshots, logs, and request payloads.
Failing to update the report: If you discover additional reproduction steps or learn that the issue no longer occurs, update the issue rather than leaving misleading information in the tracker.
Some problems happen only occasionally. A request may time out once and succeed on the next attempt, or a page may freeze only under a particular combination of actions.
In these cases, do not invent a reliable reproduction sequence.
Instead, record:
What you were doing when the problem occurred.
The date and approximate time, when useful.
How often it occurred during your testing.
Any relevant network or environment conditions.
Available error messages or logs.
Whether the issue appeared again after a reasonable number of attempts.
Use a description such as “Intermittent: observed twice in ten attempts” if that accurately reflects your testing.
Avoid claiming that a bug happens every time when you have seen it only once. If you cannot reproduce it again, say so and provide the evidence available.
The issue may still be worth investigating, particularly if it affects an important workflow or has evidence in the system logs.
A bug report is the beginning of an investigation, not the end of the process. A typical workflow may include the following stages, although terminology varies between teams.
Submission: The reporter creates the issue with the available details.
Triage: The team checks whether the issue is valid, understandable, and sufficiently distinct from existing reports.
Prioritisation: The responsible people assess the impact and decide when it should be addressed.
Investigation: A developer or tester attempts to reproduce the issue and identify the cause.
Fix: The responsible developer changes the code, configuration, or relevant component.
Verification: A tester or developer checks whether the original problem has been resolved.
Regression testing: Relevant existing functionality is checked to ensure the fix has not introduced another defect.
Closure or reopening: The issue is closed if the resolution meets the acceptance criteria, or reopened if the problem remains.
The workflow is not always strictly linear. An issue may be reassigned, returned for additional information, or reopened after further testing.
If you are responsible for verifying a fix, repeat the original reproduction steps. Also check nearby functionality when appropriate, rather than assuming the fix is successful simply because the application loads.
You do not need an expensive testing platform to start learning bug reporting. The most suitable tool depends on the project and the team's workflow.
Issue trackers: Tools such as Jira or GitHub Issues can organise bug reports, assign work, track status, and record discussions.
Browser developer tools: Browser consoles and network panels help investigate frontend errors, failed requests, and response details.
API testing tools: Tools such as Postman can help reproduce request-related problems and inspect responses.
Screen recording and screenshots: These can document interface defects and the sequence of actions that causes them.
Application logs: Server and client logs can provide additional context when the defect involves an error or unexpected system behaviour.
For a college project, a shared issue list or repository issue tracker may be enough. For a professional application, use the tools and reporting process established by the team.
The objective is not to use the largest number of tools. It is to collect reliable evidence and communicate the problem clearly.
Imagine a developer receives this message:
“Login not working. Please check.”
The message does not explain which account was used, what information was entered, whether an error appeared, or what the application did.
Rewrite it by answering these questions:
Which login page or application version was tested?
What actions were performed?
What should have happened?
What happened instead?
Was an error message displayed?
Can the issue be reproduced consistently?
Is there a screenshot, console error, or relevant network response?
A more useful report might say:
Title: Login form displays a server error for valid test credentials
Environment: Web application in the test environment, Chrome desktop browser.
Preconditions: A test account exists and is active.
Steps to reproduce:
Open the login page.
Enter the valid credentials for the designated test account.
Click Login.
Observe the response.
Expected result: The user should be authenticated and redirected to the intended page, assuming the account and credentials meet the application's requirements.
Actual result: The application displays a server error and does not complete the login.
Evidence: Attach the relevant error message and, if available, a sanitised network response or application log.
This example is more actionable, but the details must be replaced with the actual observations from testing. Never report that credentials were valid or an error occurred unless you verified it.
Practise this exercise with three different defects in a sample project. Over time, you will become faster at separating facts, expected behaviour, evidence, and assumptions.
Writing a clear bug report is an essential part of building and testing reliable software. It helps developers understand what went wrong, reproduce the issue, assess its impact, and verify the eventual fix.
A useful report does not have to be lengthy. It needs a specific title, relevant environment details, reproducible steps, expected and actual results, and appropriate evidence. Severity and priority should reflect the problem's impact and the team's process.
For beginners, the best way to improve is to practise documenting real issues in small projects. Test forms, navigation, API requests, data persistence, and responsive layouts. Whenever you find unexpected behaviour, record exactly what happened and what evidence supports your observation.
As you gain experience, clear bug reporting will help you communicate more effectively with teammates, contribute to testing, and demonstrate a disciplined approach to software development.
A bug is a defect or unexpected behaviour in a software system. A bug report is the structured record that describes the issue, its conditions, reproduction steps, expected result, actual result, and supporting evidence.
It should be as short as possible while still providing enough information to understand and investigate the issue. A simple visual defect may need only a few sentences and a screenshot, while a complex API or performance issue may require logs and detailed reproduction steps.
Sometimes, especially for an obvious visual defect. However, many problems require reproduction steps, environment details, error messages, or network information. Use evidence appropriate to the type of issue.
Severity describes how much the defect affects the system or its users. Priority describes how urgently the team should address it. Teams use their own definitions and may consider business impact, affected users, and release requirements.
Yes. The reporter's responsibility is often to describe the observed problem accurately and provide useful evidence. Identifying the root cause or implementing a fix may be the responsibility of another team member.
Record the conditions under which it occurred, how often you observed it, and any available evidence. Clearly state that it is intermittent or currently not reproducible rather than inventing steps or claiming that it happens consistently.
The best tool is the one that fits the project and team workflow. Beginners can start with GitHub Issues, a shared issue tracker, or another simple system. Browser developer tools and API testing tools can provide supporting evidence for technical defects.
More News Click here
Discover thousands of colleges and courses, enhance skills with online courses and internships, explore career alternatives, and stay updated with the latest educational news..
Gain high-quality, filtered student leads, prominent homepage ads, top search ranking, and a separate website. Let us actively enhance your brand awareness.
Download EasyShiksha Mobile Apps from Android Play Store, Apple App Store, Amazon App Store, and Jio STB.
1 million+ย learned on the EasyShiksha App
Trusted by Standards & Global Compliance Frameworks
Built under internationally recognized standards for quality, information security, educational excellence and business continuity.
ISO 9001:2015 | ISO/IEC 27001:2022 | ISO 21001:2018 | ISO 22301:2019 | DPIIT Recognized Startup | MSME Registered
