DEV Community: Cristiana Constantin

How to write a bug report

Cristiana Constantin — Mon, 07 Apr 2025 12:38:16 +0000

Overview

In this article, we’ll walk through what a bug report is and why it’s useful. We’ll get a simple understanding of:

What to include in a bug report
How to describe an issue clearly
What a real bug report looks like
Handy tools that make reporting easier

This is just a friendly guide that I use to feel more confident when reporting bugs.

What is a Bug Report?

A bug report is a written document (or ticket) that tells a developer (or team) that something in the software isn’t working as it should. Think of it like leaving a note that says:

"Hey, I found something broken. Here's what happened, where, and how you can see it too."

A bug report is important because it helps us clearly explain what’s broken, where it happened, and how to reproduce it. As a result, developers can understand the problem, fix it faster, and make sure nothing important gets missed.

The Key Points of a Bug Report

Title - We should write a short and clear summary of the issue.
Where It Happened (Environment) - Let’s include details like the device, operating system, browser, or app version where the bug appeared.
How to Reproduce It - We need to list the exact steps that lead to the bug so someone else can follow them and see the same issue.
What You Expected (Expected Result) - Here, we describe what should have happened if everything worked as intended.
What Happened (Actual Result) - In this part, we explain what actually happened when we followed the steps.
Severity (Impact) - We should mention how badly the bug affects the user.
Priority (Urgency) - We also need to say how quickly the bug should be fixed based on urgency or business needs.
Screenshot or Video - Let’s include visuals if they help show the problem more clearly.
Error Messages or Logs - If there are any error messages or logs, we should attach them too.

Examples of a Bug Report

Title:
"Login fails on LinkedIn despite correct credentials"
Environment
- Device: Windows 10 laptop
- Browser: Google Chrome (v122.0)
- App Version: LinkedIn Web

Steps to Reproduce:
1. Go to linkedin.com
2. Enter a valid email and password
3. Click the "Sign In" button

Expected Result: The user should be logged in and redirected to their LinkedIn homepage.
Actual Result: The page reloads with no error message, and the user stays on the login page. The login does not succeed.
Severity: High – Users cannot access their LinkedIn accounts.
Priority: High – This prevents users from using core functionality.
Screenshot / Video:
[Attach screenshot or screen recording of the failed login attempt]
Error Logs (if available):
No visible UI errors. Browser console shows:

POST https://www.linkedin.com/checkpoint/lg/login-submit 403 (Forbidden)

Tools

There are many tools to help report and track bugs:

Jira – Great for full project and issue management
Trello – Simple and visual for small teams
Bugzilla – Good for detailed tracking
GitHub Issues – Works well for developer teams
ClickUp – Combines task management and bug tracking in one place

The right tool depends on how your team works and the complexity of your project.

Example in Jira

Here is an example of a bug report in Jira:

Conclusion

In this article, we started by understanding what a bug report is and why it matters.
It’s all about helping teams spot and fix problems faster.

Then, we looked at the key parts: a clear title, the environment where the issue happened, and simple steps to reproduce it.
We talked about describing what we expected to happen versus what actually did, and why severity and priority help show how serious and urgent the bug is.
Additionally, adding screenshots, videos, or error messages makes the report even clearer.

Finally, we also walked through a real bug report example and mentioned some helpful tools like Jira, Trello, and GitHub.
In the end, a clear bug report helps everyone work faster and smarter.

Black Box, White Box, and Grey Box in Software Testing

Cristiana Constantin — Mon, 07 Apr 2025 11:36:03 +0000

Overview

In software testing, Black Box, White Box, and Grey Box refer to three distinct approaches that differ based on how much insight we, as testers, have into the internal workings, structure, or code of the system being tested.

Understanding these differences helps us design better testing strategies. Each method offers unique benefits and focuses on different parts of the software, making it easier to identify bugs and improve overall quality.

Black Box Testing

Black Box Testing means testing the software without any knowledge of its internal workings. We only know the inputs and the expected outputs.

We focus only on the interface of the product, interacting with it just like an end user, without knowing how it works internally.

Key Points:

Focuses on functionality
Based on requirements and specifications
Test cases are created from the user’s perspective
Common techniques: Boundary Value Analysis, Equivalence Partitioning, Decision Table Testing

Example:
We test a login form by entering valid and invalid usernames/passwords, without knowing how the authentication is implemented.

White Box Testing

White Box Testing involves testing the internal structure, logic, and code of the software. We have full access to the source code.

We work directly with the internal code and logic of the product, checking how it processes data and makes decisions.

Key Points:

Focuses on code paths, logic, and conditions
Also called Clear Box or Glass Box Testing
Used for unit testing, code coverage, and path testing
Requires programming knowledge

Example:
This time, we test the login function by reviewing and verifying the code that handles authentication, input validation, and session management.

Grey Box Testing

Grey Box Testing is a hybrid approach, where we have partial knowledge of the internal workings of the application.

We use this limited insight to test both the interface and internal components, such as APIs or data flow.

Key Points:

Combines both Black Box and White Box techniques
Useful for integration testing and security testing
We may know the architecture, APIs, or database schema, but not the actual code

Example:
We test the login system with some knowledge of the backend, so we check both the user input and how it’s processed behind the scenes.

Conclusion

Knowing the difference between Black Box, White Box, and Grey Box testing allows us to choose the right approach for each situation. This not only improves test coverage but also helps deliver higher quality software through well-rounded testing practices.

Testing Type	Internal Knowledge	Focus	Tester Role
Black Box	No	Functional behavior	End-user perspective
White Box	Yes	Internal logic/code	Developer or test engineer
Grey Box	Partial	Integration & logic	Power user/tester with some system knowledge

Functional and Non-Functional Testing in Software

Cristiana Constantin — Wed, 02 Apr 2025 12:04:00 +0000

Overview

In this article, we'll first define functional and non-functional testing and explore the differences between them. We'll also cover several types of testing in each category with brief, clear explanations.

Functional testing and non-functional testing are two categories used in software testing to ensure that the software not only works correctly but also performs efficiently, securely, and meets various quality standards.

Functional Testing

Definition: Functional requirements specify what the system should do and how it should behave in response to specific inputs or conditions.

Functional refers to the specific actions or features that a software or system is meant to perform. It’s about ensuring the software does what it’s supposed to do, according to its intended purpose.

Types of Functional Testing:

Unit Testing: Testing individual components or functions in isolation.
Integration Testing: Testing interactions between integrated modules or systems.
System Testing: Testing the entire system as a whole.
Acceptance Testing: Ensuring the software meets business requirements and is acceptable to the customer.
Functional Testing: Verifying that the software performs according to specified requirements.
Smoke Testing: Preliminary testing to ensure basic functionality works.
Sanity Testing: Focused testing of specific functionalities after changes or bug fixes.

Non-Functional Testing

Definition: Non-functional requirements specify how the system should perform, focusing on attributes such as performance, security, usability, and reliability.

Non-functional refers to the quality attributes or performance characteristics of the system, which aren't related to specific behaviors or features. Non-functional requirements describe how well the system performs the tasks.

Types of Non-Functional Testing:

Performance Testing: Measures the speed, responsiveness, and stability of the software.
Load Testing: Testing the system's ability to handle expected traffic or load.
Stress Testing: Testing the system under extreme conditions to determine breaking points.
Security Testing: Identifies vulnerabilities and ensures the system is secure.
Usability Testing: Evaluates user experience and interface design.
Compatibility Testing: Verifies that the software works across different devices, browsers, and operating systems.
Localization Testing: Ensures the software works correctly in different languages, cultures, and regions.

Comparison

Here we have a short comparison where functional focuses on what the system does, while non-functional focuses on how well it performs those tasks.

Aspect	Functional	Non-Functional
Definition	Refers to what the system does (its features and behaviors).	Refers to how well the system performs (quality attributes).
Focus	Specific tasks or actions the software is designed to do.	System performance, security, usability, and other qualities.
Examples	User login, form submission, search functionality.	Performance speed, security, scalability, usability.
Testing Type	Functional Testing (e.g., unit, integration, system).	Non-functional Testing (e.g., performance, security).
Measurement	Can be directly verified by checking if tasks are completed correctly.	Measured in terms of speed, stability, and user experience.
Priority	High priority for ensuring the system works as intended.	Important for ensuring system quality and user satisfaction.

Conclusion

We can say that both functional and non-functional testing are crucial for ensuring software quality. While functional testing ensures that the software performs the intended tasks correctly, non-functional testing helps us evaluate how well the software performs those tasks in terms of performance, security, and user experience. Together, they are key to delivering a reliable and high-quality product.