How to score runs in a developer's pitch?

When communicating or informing a developer that a bug is a bug, it's essential to be clear, precise, and provide sufficient information to help them understand the issue. Here are some steps to effectively communicate a bug to a developer;

Confirm the Bug: Double-check that what you're experiencing is indeed a bug and not an intended feature.

Share System Info: Mention your operating system, browser, or any relevant details about your setup.

Describe the Problem: Clearly explain what the bug is and how it affects the system.

Explain Expected Result: Describe what you were expecting to happen instead.

Show How to Reproduce: Provide step-by-step instructions on how to make the bug happen again.

Attach Screenshots or Logs: If possible, show visuals or error messages related to the bug.

Importance: Indicate how much the bug impacts the system's performance or functionality.

Follow Up: Check if the bug gets fixed and provide feedback if needed.

Be Friendly: Use a polite tone when communicating the issue.

Stay Available: Be ready to answer any questions the developer may have.

---

By following these simple steps, you can help the developer understand and address the bug more effectively.

---

 

Top Ten Open Source Bug Tracking Systems

Top Ten Open Source Bug Tracking Systems

I. Bugzilla > Connecting URL
II. Mantis > Connecting URL
III. Trac > Connecting URL
IV. Redmine > Connecting URL
V. OTRS > Connecting URL
VI. Request Tracker > Connecting URL
VII. Eventum > Connecting URL
VIII. BugGenie > Connecting URL
IX. WebIssues > Connecting URL
X. Fossil > Connecting URL

>Compiled From Different Websites<

Impact Analysis?

Assume once the complete application is been ready for testing from the development side; If one more module is to be added, then we (software testers) need to test the new module as well as the impacted area which might be affected by adding a new module.

Impact Analysis will be done to locate the impact region of the application by adding a new module. Usually a team lead will kick off for this analysis and prepare the Impact analysis document which generally has the variation/deviation stuffs.

When the “Impact analysis” will be essential?
* New module is added.
* Testing the Upgraded application which has a new edition (or) after Bug fixing.

All the cases are better to discuss with development team for detail Impact analysis. If developer is not available then check the design document and functional diagram for the data flow and find the dependency with the fixed or supplementary modules.

Bug Bugger Buggest

I got a title name, all of a sudden on reading my team mate’s status message on Facebook and thought of writing a blog related to it. Before writing a blog with regards to that title, I confirmed no blog had that title but a blog had. That too in the year 2006 itself, it was written.

Title which occurred in my mind: Bug Bugger Buggest. But I’m happy, that I saw the title in one of the famous testing blog and the content was also nice.

URL for that blog post: Bug Bugger Buggest

Courtesy: Pradeep Soundararajan

Standard Bug Post will have?

Bug Summary: [Summary of what happened.]
Bug ID: [Hope most of the tracking tool will automatically create by itself.]
Area Path: [Where the issue is present?]
Build Number: [Version Number which you get in mail from Dev Team.]
Severity: [Text, Tweak, Minor, Major, Crash & Block.]
Priority: [None, Low, Normal, High, Urgent & Immediate.]
Assigned to: [Developer-XYZ]
Reported By: [Hope most of the tracking tool will automatically pick by itself as you would have logged-in.]
Category: [Design Issue, Functional Bug, JavaScript Error (Web app), Added Feature & On Hold.]
Status: [New/Assigned/Resolved/Reopened/Acknowledge/Close] (Depends on the Tool you are using)
Environment: [Windows XP/SQL Server 2005]
Computer Resolution: [Check with your monitor resolution.]
Description: [Precise explanation about the bug.]
Steps To Reproduce: [Optional, when Description is understandable.]
Expected result: [What the exact functionality need to do.]

Buggy Application (or) Software ?

Question: Is your "Software/Application" diseased?

>>> Then there are a few causes for unhealthiness. They are as follows;

1. Breakdown in informational exchange.
2. Unrealistic development time-frame.
3. Deprived design logic.
4. Feeble coding ethics.
5. Lack of version control.
6. Less focus on documentation maintenance.
7. Infectious third-party devices.
8. Less attention on software repairs.
9. End-line Alterations.
10. Individual Traits.

URL(another place where my blog got posted) :: Application-Diseased

Bug Life Cycle