BugHerd Documentaion

BugHerd is a simple one-stop bug tracking and website feedback tool. Previously, 829 Studios was using multiple tools to consolidate, track, and execute website feedback (i.e. Click Up, Active Collab, and BugHerd). Going forward, BugHerd should be treated as our single source of truth for tracking all website feedback. Specifically:

BugHerd should be used for internal testing, bug fixing, and validation tracking during pre and post content population QA 

This happens prior to the website presentation call with clients

BugHerd should also be used in collaboration with clients after the website presentation call to collect their website feedback

This happens prior to the website launch

Trainual

BugHerd in Launch Process

Installing the Script

How it's used in Propel

/app/public/wp-content/themes/propel/includes/bugherd.php

function load_bugherd() {
    if ( defined( 'BUGHERD_API_KEY' ) ) {
        wp_enqueue_script( 'bugherd', 'https://www.bugherd.com/sidebarv2.js?apikey=' . BUGHERD_API_KEY, array(), '1.0', true );
    }
}
add_action( 'wp_enqueue_scripts', 'load_bugherd' );

/app/public/wp-config.php

define( 'BUGHERD_API_KEY', 'XXXXXXXXX' );

Developer Process

  • Everyone on the project team owns the responsibility of keeping the BugHerd project board updated.

  • In general, bugs should be addressed on a per-commit basis. That means that one commit should contain one bug fix implementation (i.e. not multiple).

    • Each one of those commits should include a BugHerd link in the commit message along with a brief description of what has been done.
    • Ex: Adjusting Nav Margins - https://www.bugherd.com/projects/01234567/tasks/123

  • When Developers (either with 829 Studios or external development partners) are reviewing development bug tasks, including a level of effort (LOE) in the comments is helpful. It allows the Project Manager to review and verify that LOE against the timeline to ensure we have enough time to fix all of the bugs needed. If you’re unsure of the severity of the bug you’re logging, here are the available levels:

    • Critical - the defects that need to be fixed immediately because it may cause great damage to the product
    • High - the defect impacts the product's main features
    • Medium - the defect causes minimal deviation from product requirement
    • Low - the defect has very minor affect on product operation

  • Dev tasks can be moved from the TO DO (DEV) to the 'Doing' column once any work has begun on a task.

  • Leave a comment before moving the bug through the board

    1. When you have a question to designer or any other team member (but it’s not yet finished), the task should be put into BLOCKED and assigned to correct person.
    2. When you are finished testing the task, it is ready for QA, but from the comments you can tell that the certain person is more aware of what is happening - then you put it into Ready For QA column and assign that person.
    3. When the task is ready for testing, but there are no specific people connected to it, or you weren’t discussing it with anyone - assign it to Alena and put into Ready For QA.

  • Add Assignee (if possible)

    • Change the assignee every time you work on the bug or it is done

  • Note: Please add some type of Profile Image for yourself so it's easier to quickly tell visually where tickets are assigned/originating from.