Six Bug Reporting Best Practices for Manual Quality Assurance Engineers

Manual quality assurance (QA) in web development is the process of manually checking a website or application to identify bugs, usability issues, and design inconsistencies. Typically performed by QA specialists or developers, it ensures a seamless user experience by catching issues that automated tests might miss. In other words, it’s essential to delivering a fully functioning website that works as intended.

However, identifying bugs is only part of the QA job — reporting them effectively is just as critical.

 A well-written bug report helps developers understand the issue quickly, saves time, and improves the chances of a fast and accurate fix. In this post, we’ll look at six key characteristics of an actionable bug report.

1. Clear, Descriptive Titles (Think “Obvious” but Helpful)

First impressions matter, and your bug title is the first thing your team will see — so make it count! A good title conveys exactly what the issue is by identifying the specific component, page, or feature affected, along with a concise summary of the problem.

Consistency is key — avoid interchanging terminology (e.g., “Taxonomy” vs. “Taxonomy Term,” which may refer to entirely different things) and stick to the naming conventions established in your CMS or project.

Example Title:
“‘Cute Puppy Photo Request’ form can be submitted even when required fields are blank.”

2. Explain How to Reproduce the Issue

Reproducibility is the cornerstone of bug resolution. If developers can’t replicate the issue, they’ll (rightfully) struggle to understand what QA is reporting.

Provide clear, step-by-step instructions in the exact order you performed them. Don’t skip seemingly trivial details, as these can often be critical in reproducing the problem accurately.

Example Steps to Reproduce:

  1. As an anonymous user, navigate to [relevant URL here]
  2. Verify that the “Cute Puppy Photo Request” form is visible
  3. Leave all required fields blank
  4. Click the “Submit” button at the bottom of the form
  5. Note that the form is successfully submitted without validation errors

3. Include Relevant Screenshots or Screen Recordings

Visual aids like screenshots or videos provide context and make it much easier for developers to understand visually complex issues, such as alignment problems or animation glitches. Tools like Scrnli, native OS features, or browser extensions can help capture these details.

For extra impact, consider providing a voiceover for your recordings. There’s nothing like softly narrating QA best practices to soothe developers while they debug.

Pro tip: Include screenshots for any ticket a QA professional touches. Not only does this serve as a handy reference for future troubleshooting, but it can also pinpoint exactly which merge introduced a new bug.

4. Describe the Expected vs. Actual Results

Clearly outlining both the expected and actual outcomes helps distinguish a genuine bug from a feature or misunderstanding. Whether it’s a quick one-liner (“error should not appear”) or a more detailed explanation involving user experience considerations, this context is invaluable.

Example:

  • Expected Result: After clicking “Submit,” the user should see an error message if the required fields are not filled out.

Actual Result: After clicking “Submit,” the user can submit the form without completing the required fields, and no error message is displayed.

5. Specify the Environment and Configuration

Some bugs occur only in specific environments (we’re looking at you, Safari). Always include details about the browser, OS, device, and CMS or app version where the issue was encountered. This helps prioritize fixes and ensures issues can be replicated under the same conditions.

Example:

  • Browser: Chrome v95.0
  • OS: Windows 10 Pro
  • Device: Desktop
  • Screen Resolution: 1920×1080
  • CMS Version: WordPress 6.5

6. Reference Related Bugs or Previous Fixes

Many bugs are related to previous issues or fixes. If something feels familiar, take the time to dig into the backlog or related tickets—it might save hours of investigation. Mentioning related bugs, project-specific issues, or core bugs provides helpful context for developers and ensures nothing falls through the cracks.

Example:
“This issue appears to have resurfaced after the ‘Cute Puppy Forms’ module update in ticket #12345.”

Final Thoughts

Effective bug reporting is one of the most valuable skills a QA engineer can bring to a project. Clear, detailed, and organized reports enable developers to address issues quickly, ensuring a better end product. And let’s be honest — developers will secretly thank you for it (even if they never say it out loud).

Epic EHR, WordPress, & Drupal

If you’ve been to the doctor’s office recently and seen your provider taking notes on a computer, there’s a good chance they are logging notes into Epic. Epic is a leading electronic health record (EHR) software system that aids healthcare providers in managing and exchanging patient information. Many organizations seek to enhance healthcare websites by providing providers and patients with a more holistic user experience. 

Benefits of Epic Integration

One of the most impactful ways to achieve this unified experience is by creating an online presence integrating Epic with your public-facing Drupal or WordPress website. Epic data exchange can facilitate all aspects of a patient’s care, including:

  • Giving individual patients easy, real-time access to their medical records
  • Enhancing the patient experience with accessible, intuitive presentation of their information
  • Providing individual patient information that facilitates clinical decision support for providers alongside relevant informational and reference content

Epic integration lets you facilitate these activities and much more from a single, unified location. Leveraging Epic’s interoperability allows you to work with the rich, full-featured editorial experience you’ve come to love in your Drupal or WordPress site alongside the power of your Epic EHR implementation. 

Integrating Epic with Drupal or WordPress CMS

Epic offers a robust set of HL7® FHIR® compliant APIs that developers can use to create custom applications for your needs. There’s no suitable “one size fits all” solution for Epic interoperability. Regardless of your CMS, you’ll want to build a solution tailored to your needs.

Security and compliance are paramount when interacting with your patient data. When working with Epic’s APIs, a partially decoupled architecture can protect your patient data while still leveraging the ease of use of a CMS for the rest of your on-site content. 

Consider an entirely headless approach to maximize the security and performance of patient and site data. A headless approach is a website with the backend decoupled from the frontend. The frontend is written with javascript like ReactJS, or VueJS. The content of a headless site typically comes from API’s. This means there is no database like we see in Drupal or WordPress. Your site-data, patient-data, and front-end will all live in different places. 

You can learn more about WordPress and Headless in our blog post. 

While a headless website gives you modern flexibility and separates the end-user experience from your sensitive data stores, it comes with technical complexities and tradeoffs. It may only be suitable for some organizations:

  • organizations with multiple API integrations, including site-content that is centralized and dispersed to multiple services or apps, 
  • those that have the extensive monthly budgets, bandwidth, and expertise to maintain a decoupled system, and 
  • organizations that require the highest security and performance possible may wish to consider a completely headless solution.

There are advantages and disadvantages to each approach. The below Pros and Cons list is an attempt to provide a quick overview to help you make an informed decision.

PRO

CON


CMS only

PRO

  • Site data is easily updatable
  • Skilled developers and agencies are plentiful
  • Ease of use
  • Templating and flexibility in content creation
  • Lower initial cost

CON

  • Patient data could be stored in the database
  • Only as flexible as the content management system allows
  • Only as performant as the CMS will allow for with the coupled front and backend.
  • The site itself is as secure as the CMS and the hosting provider.

Semi Decoupled site

PRO

  • Site data is easily updatable
  • Patient data is very secure
  • Templating and flexibility in content creation
  • Specially skilled developers are required
  • Maintainability cost is lower

CON

  • The site itself is as secure as the CMS and the hosting provider
  • The site itself is as performant as the CMS and the hosting provider.

Entirely Headless Site 

PRO

  • Patient data is very secure
  • Highly performant
  • Highly secure
  • Highly flexible
  • Omnichannel
  • Adaptable

CON

  • Site data is updatable but may require additional caching to be cleared
  • Specially skilled developers are required
  • May require multiple systems and personnel to publish a single update
  • Highest initial cost
  • Most content may be created with raw inputs and APIs

Conclusion

Integrating Epic with WordPress and Drupal empowers healthcare organizations to improve patient engagement, streamline clinical operations, and ensure compliance with regulatory standards. Whether using WordPress for its user-friendly interface or Drupal for its scalability and customization capabilities, healthcare providers can leverage Epic’s EHR functionalities to optimize the patient experience and create better health outcomes.