<skill_overview> Classify bugs effectively and write clear, reproducible bug reports

Documenting a bug found during testing Triaging bug reports Assigning severity and priority to defects

</skill_overview>

<bug_severity> Classifying bug impact on system functionality

Blocks main functionality or causes data loss

Application crashes completely Data loss or corruption Security vulnerability allowing data breach Payment processing fails Users cannot login or access system

Fix immediately, block release

<level name="Major"> <description>Significant feature doesn't work as expected</description> <criteria> <criterion>Core feature fails in common scenarios</criterion> <criterion>Important functionality is broken</criterion> <criterion>Workaround exists but is inconvenient</criterion> <criterion>Performance issues affecting many users</criterion> </criteria> <action>Fix soon, high priority</action> </level>

<level name="Minor"> <description>Minor issues that don't block functionality</description> <criteria> <criterion>Feature works but has minor issues</criterion> <criterion>UI/UX issues that don't affect functionality</criterion> <criterion>Documentation errors</criterion> <criterion>Inconvenient but acceptable workarounds</criterion> </criteria> <action>Fix in next release or when convenient</action> </level>

<level name="Trivial"> <description>Cosmetic issues or very minor problems</description> <criteria> <criterion>Spelling or grammar errors</criterion> <criterion>Minor UI inconsistencies</criterion> <criterion>Edge cases that rarely occur</criterion> <criterion>Issues with no impact on functionality</criterion> </criteria> <action>Fix when convenient, may defer</action> </level>

<bug_priority> Determining order of fixing bugs based on urgency

Fix right now, stop everything else Critical production issues, security vulnerabilities, data loss

<level name="P1 - High"> <description>Fix as soon as possible</description> <when>Major functionality broken, high user impact, affecting many users</when> </level>

<level name="P2 - Medium"> <description>Fix in next release or sprint</description> <when>Minor issues, moderate user impact, acceptable workarounds</when> </level>

<level name="P3 - Low"> <description>Fix when convenient, may backlog</description> <when>Trivial issues, rare edge cases, cosmetic problems</when> </level>

<priority_vs_severity> Severity is about impact, Priority is about urgency

Severity: Critical, Priority: P1 - Critical but no workaround, fix soon Severity: Major, Priority: P2 - Major issue but rare occurrence Severity: Minor, Priority: P1 - Minor but affecting many users

</priority_vs_severity> </bug_priority>

<bug_report_template> Standard format for bug reports

<section name="Summary"> <description>Clear, concise title describing the bug</description> <guidelines> <guideline>Start with what is broken</guideline> <guideline>Include key details in title</guideline> <guideline>Keep under 80 characters if possible</guideline> </guidelines> <examples> <good>Login fails with "Invalid credentials" after correct password change</good> <good>Checkout button does nothing when cart has multiple items</good> <good>Application crashes when uploading image larger than 5MB</good> <bad>Login doesn't work</bad> <bad>Problem with checkout</bad> <bad>Bug in upload</bad> </examples> </section>

<section name="Environment"> <description>System and environment information</description> <fields> <field>Browser and version (e.g., Chrome 120.0.6099.109)</field> <field>Operating system (e.g., macOS 14.2, Windows 11)</field> <field>Device type (Desktop, Mobile, Tablet)</field> <field>Screen resolution (e.g., 1920x1080)</field> <field>Application URL or environment (Production, Staging, Local)</field> <field>Date and time of occurrence</field> <field>User role or account type (if applicable)</field> </fields> </section>

<section name="Steps to Reproduce"> <description>Detailed, step-by-step instructions to reproduce the bug</description> <guidelines> <guideline>Each step must be clear and unambiguous</guideline> <guideline>Include exact data entered</guideline> <guideline>Specify exact elements clicked or interacted with</guideline> <guideline>Include navigation details (pages, URLs)</guideline> <guideline>Steps should be reproducible by another person</guideline> </guidelines> <format> <step>1. Navigate to [URL/page]</step> <step>2. Click on [element]</step> <step>3. Enter [data] into [field]</step> <step>4. Click [button/link]</step> <step>5. Observe [result]</step> </format> </section>

<section name="Actual Result"> <description>What actually happened when following the steps</description> <guidelines> <guideline>Be specific and descriptive</guideline> <guideline>Include exact error messages</guideline> <guideline>Describe what is seen on screen</guideline> <guideline>Note any unexpected behavior</guideline> </guidelines> <examples> <example>User redirected to error page with message "500 Internal Server Error"</example> <example>Button does nothing, no error shown</example> <example>Form submits but data not saved, success message shown</example> </examples> </section>

<section name="Expected Result"> <description>What should have happened</description> <guidelines> <guideline>Describe correct behavior clearly</guideline> <guideline>Include what user should experience</guideline> <guideline>Reference requirements or design if applicable</guideline> </guidelines> <examples> <example>User should be redirected to dashboard</example> <example>Confirmation message should display</example> <example>Data should be saved and visible in list</example> </examples> </section>

<section name="Screenshots/Videos"> <description>Visual evidence of the bug</description> <types> <type>Screenshot of error or unexpected behavior</type> <type>Screenshot of the page where bug occurs</type> <type>Video demonstrating the bug (if applicable)</type> <type>Comparison screenshots (before/after) if visual regression</type> </types> <guidelines> <guideline>Include full visible area of issue</guideline> <guideline>Capture relevant error messages</guideline> <guideline>Use descriptive filenames</guideline> <guideline>Show context, not just the bug</guideline> </guidelines> </section>

<section name="Logs"> <description>Relevant console logs, server logs, or error messages</description> <types> <type>Browser console errors and warnings</type> <type>Network request/response details</type> <type>Server error logs (if accessible)</type> <type>Application logs with timestamps</type> </types> <guidelines> <guideline>Include full error messages</guideline> <guideline>Include stack traces if available</guideline> <guideline>Redact sensitive information (passwords, tokens)</guideline> <guideline>Include timestamps if relevant</guideline> </guidelines> </section>

<section name="Additional Information"> <description>Any other relevant details</description> <examples> <example>Bug is intermittent - occurs randomly</example> <example>Workaround exists: [describe workaround]</example> <example>First time bug observed, or regression?</example> <example>Number of users affected (if known)</example> <example>Frequency of occurrence</example> </examples> </section>

<writing_effective_summaries> Best practices for bug report titles

Be specific and descriptive Include the feature or component Describe what is broken, not just "bug" Include key symptoms or error messages Keep it concise (under 80 characters ideal) Start with verb or noun (e.g., "Login fails", "Upload error") Avoid vague words like "issue", "problem", "doesn't work"

<bad>Login doesn't work</bad> <bad>Checkout problem</bad> <bad>Upload button is broken</bad> <bad>Something is wrong with password</bad> <bad>Bug in profile</bad>

<writing_reproducible_steps> Creating clear, reproducible step-by-step instructions

Each step should be a single, clear action Number steps sequentially Be specific about elements clicked (IDs, labels, text) Include exact data entered in forms Specify navigation (page names, URLs) Include all necessary pre-conditions Test steps yourself before submitting

<capturing_evidence> Collecting and documenting proof of bugs

<duplicate_detection> Determining if bug is already reported

Search for existing bugs with similar titles Review similar bugs in the same module Check if symptoms match known issues Verify if reported for same version/environment Check comments for workarounds or resolutions

<if_duplicate_found> Add comment to existing bug with your findings Confirm the bug with your reproduction steps Add additional information if you have new details Note that you've reproduced the issue Link to the original bug in your notes </if_duplicate_found> </duplicate_detection>

<wishlist_vs_bug> Distinguishing between bugs and feature requests

<classification_guide> Does it work differently than designed or documented? = Bug Is this about adding something new? = Wishlist Is this about improving something that works? = Wishlist Is this unexpected behavior or error? = Bug </classification_guide> </wishlist_vs_bug>

<bug_triage_process> Workflow for evaluating and prioritizing bugs

Receive bug report Check for duplicates Reproduce the bug Assign severity and priority Categorize by component/module Assign to developer or team Set expected fix timeline Track until resolved

</bug_triage_process>

<verification_after_fix> Testing bugs after they are reported as fixed

Follow the original steps to reproduce Verify the bug no longer occurs Test related functionality to ensure no regressions Test edge cases around the fix Update bug report with verification status Mark as verified or reopen if bug persists

<verification_checklist> Original issue is resolved No new issues introduced Related functionality still works Edge cases are covered No performance degradation </verification_checklist> </verification_after_fix>

<common_bug_reporting_mistakes> Mistakes to avoid when reporting bugs

Vague summary title <bad_example>"Something is wrong with login"</bad_example> <good_example>"Login button unresponsive after entering valid credentials"</good_example> Developers may misunderstand or ignore the bug