If you believe you've found a bug in Chorus, you should first work through the steps in the "Investigation" section of this guide, this ensures that the development team has all of the information they need to begin working on a fix without needing to come back to the Support team for additional information, which slows down the process.


Once you have sufficient evidence to believe a bug is present in the live Chorus environment, and have gathered the pieces of information noted in the "Investigation" section of this guide, then you can proceed to the "Raising a bug" section, which will automatically generate a ticket in Azure DevOps (The program the development team uses to track and work through bugs).


TABLE OF CONTENTS


Investigation

Since Chorus is a web-based specification writing platform, there are a lot of different computer environments it can be run on, essentially any device with a web browser. There are also a number of web browsers out there, and the version the customer is using may not be the most up-to-date. Additionally, Chorus is a piece of software with a lot of menus and pages a user can be on. The more specific we can be, about the environment in which the bug is being experienced, the easier our developers can narrow down a cause and create a fix.


A first troubleshooting step we recommend is to follow what the user is doing just before they encountered the suspected bug, and see if you can recreate it on your own computer. If you can recreate the issue test it on another web browser, also see if a colleague is free to test the bug on their PC too. If it can be reliably recreated on multiple machines then we have a good case for it being a Chorus-wide bug, rather than a product of the user's environment. There are also a number of generic troubleshooting steps such as clearing browser cache and cookies that i'll not go into in this article.


If the issue cannot be recreated by us, then the development team are unlikely to be able to recreate it themselves, and if they can't recreate it then they're unlikely to be able to action a fix.


Information gathering

Once you've determined that a bug is present in Chorus and it can be recreated, information about the issue then needs to be gathered for the next step, which is raising this as a bug in Freshdesk. 

In general, the more screenshots we get of the issue, the better. Either ask the user to provide these via email, or use tools like MS Teams or remote viewing software to take screenshots of the issue yourself. If the issue is Chorus-wide and you can recreate it, then screenshots of your own screen showing the issue are absolutely fine.


Please liaise with the customer who reported this bug and gather the following pieces of information as a minimum:

- Customer name

- Company

- Email address

- Level of access (Standard user, Organization administrator)

- Subscription level (Chorus, Chorus Pro, Chorus for Manufacturers, Chorus Enterprise, Chorus Premium)

- Is this the first time you have experienced the issue? 

- When was the last time you used it successfully? 

- Are you working from home? (if yes) Are you connected to a VPN?

- Can you let me know when this issue needs to resolved by? (this helps the developers assign a priority rating)


Depending on the nature of the query, the following information may be key to determining the cause of the issue.

This is not an exhaustive list, please use your own deductive reasoning to ask any follow-up questions.

Generic error message:

- Ask the user to provide the full URL of the page they are on when they encounter the error

- What was the user doing immediately before this error appeared? Does pressing a particular button cause the error for example?

- Do their colleagues have the same issue on their machine?

- Ask the user to open the browser console with the F12 key (when the error message is on screen) and navigate to the "Console" tab and provide a screenshot

Specification issue

- Does the same issue occur with other specs/projects? Can they try another spec/project? (can we replicate it?)

- Do their colleagues have the same issue on their machine?

- Was the specification imported into NBS Chorus? (If yes, where from?)

Publishing issue

- Does it happen in both export formats? (PDF/Word)

- Are they publishing all the sections in your spec or a select amount?

- Does it do the same on other clauses? (If clause specific)

- Can the customer provide a copy of the exported document or stylesheet in order to illustrate the issue?


Logging the bug in Freshdesk

Once you have compiled all of the information above, now it's time to log it in Freshdesk and raise it with the development team.

The first step is to change the "Type" field in Freshdesk to "bug", this will display a number of additional fields that need to be filled in (Only the onses with the red asterisk are required)




Field title What to enter
Internal bug description 1 sentence that succinctly describes the issue
Reproductive steps A short list of bullet-point steps that can be taken to recreate the issue
Actual result What actually happens when you follow the steps above?
Expected result What should happen when you follow the steps above?
Environment/URL Either the URL for the particular project where the issue occurs (if project specific), or "Live" if this is present in the live version of Chorus
Product version Should be "Chorus Live" in all circumstances


After filling in these fields, change the "Status" to "Waiting on QA/Dev" then press the blue Update button.

After around 30 seconds a note will be automatically added to the ticket that looks like the one pictured below.

This note includes a link to the ticket that had just been generated in Azure DevOps.

Take the "VSTS number" from this note and enter it into the "VSTS ref" box on the right hand side of the ticket just above "Status". Click the blue update button again.


It's very important that you wait the 30 seconds for the VSTS reference before doing anything else.
While it's raised as a bug anything you do in that ticket will raise another Azure DevOps ticket if the "VSTS ref" box is empty. make sure you wait for the ref and fill this in before doing anything else with the ticket.



Using that reference, you should be able to locate the bug within Azure DevOps.

Most of the information should pull through from Freshdesk, but screenshots and documents won't.

Ensure that the "Description" box on the left of the screen contains all of the pertinent written information you gathered in the "Information gathering" stage including any screenshots.

There is also a paperclip icon to the right of the screen, this is where you can add any supporting attachments.


Please remember to click the "Save" button in the top-right of the ticket after adding information. If you navigate away from this page before clicking Save, any unsaved information will be lost.