How we handle Bug Reports - Revision history

SarahK at 14:20, 5 September 2023

2023-09-05T14:20:49Z

James.white: /* Known Bugs and Hotfixes */

2023-08-29T14:39:58Z

‎Known Bugs and Hotfixes

SarahK: /* Known Bugs and Hotfixes */

2022-03-11T22:43:48Z

‎Known Bugs and Hotfixes

SarahK at 20:55, 25 January 2022

2022-01-25T20:55:24Z

John: /* How we handle Bug Reports */

2021-02-11T17:52:04Z

‎How we handle Bug Reports

DanR: /* How we handle Bug Reports */

2019-12-05T15:05:13Z

‎How we handle Bug Reports

DanR: /* How we Handle Bug Reports */

2019-12-05T15:03:24Z

‎How we Handle Bug Reports

DanR at 15:00, 5 December 2019

2019-12-05T15:00:48Z

PeterB at 13:19, 27 August 2019

2019-08-27T13:19:45Z

PeterB: Create placeholder for DOCS-6867

2019-08-27T13:01:05Z

Create placeholder for DOCS-6867

New page

Coming soon.

@@ Line 57: / Line 57: @@
 When we identify issues between releases, we publish individual patches (hotfixes) outside of the update structure. You can apply these if you are encountering issues.
-* For solutions to known problems, see [https://whmcs.community/files/categories/ Hotfixes Forum].
+* For solutions to known problems, see our [https://whmcs.community/files/categories/ Hotfixes Forum].
 * For hotfixes prior to WHMCS 7.0, see [[HotFixes]].
 __NOTOC__

@@ Line 57: / Line 57: @@
 When we identify issues between releases, we publish individual patches (hotfixes) outside of the update structure. You can apply these if you are encountering issues.
-* For solutions to known problems, see [https://forum.whmcs.com/forumdisplay.php?158-Hotfixes Hotfixes Forum].
+* For solutions to known problems, see [https://whmcs.community/files/categories/ Hotfixes Forum].
 * For hotfixes prior to WHMCS 7.0, see [[HotFixes]].
 __NOTOC__

@@ Line 55: / Line 55: @@
 == Known Bugs and Hotfixes ==
-When we identify issues between releases, we publish individual patches (hotfixes) outside of the update structure. You can apply these if you are encountering issues. For solutions to known problems, see [https://forum.whmcs.com/forumdisplay.php?158-Hotfixes Hotfixes Forum].
+When we identify issues between releases, we publish individual patches (hotfixes) outside of the update structure. You can apply these if you are encountering issues.
 __NOTOC__

@@ Line 52: / Line 52: @@
 <tr><td>CONFIRMED</td><td>We have been able to reproduce the issue and have confirmed it is not intended behaviour. We will raise an internal bug report for our developers to investigate further.</td></tr>
 </table>
 __NOTOC__

@@ Line 27: / Line 27: @@
 may require us to ask for further details if necessary to enable us to reproduce the issue described.
-We will use the details provided to try and replicate the settings used and the steps provided to replicate the issue. Should we confirm the behaviour described, we will then confirm if this is as designed, or if it does indeed represent a bug.
+We will use the details provided to try and replicate the settings used and the steps provided to replicate the issue. Should we confirm the behaviour described, we will then confirm if this is as designed, or if it does indeed represent a defect against how the product is designed to operate.
 '''Step 2a: Issue Confirmed'''

@@ Line 31: / Line 31: @@
 '''Step 2a: Issue Confirmed'''
-When we are able to replicate the reported bug and confirmed it is unintended behaviour we will then create and internal bug case with the steps to reproduce, and details of the issue so it can be investigated by our developers.
+When we are able to replicate the reported bug and confirmed it is unintended behaviour we will then create an internal bug case with the steps to reproduce, and details of the issue so it can be investigated by our developers.
 We will provide the reporter with the case number which will also be shown on future [[Changelogs]] once the issue is resolved.

@@ Line 16: / Line 16: @@
 * Provide real world examples where possible
-===How we Handle Bug Reports===
+===How we handle Bug Reports===
 When we receive a bug report, we will go through the steps below to verify the issue and where confirmed we will then create a case internally to have the issue investigated further and gather further information.

← Older revision		Revision as of 15:00, 5 December 2019
Line 1:		Line 1:
	<div class="docs-related-pages">[[How we handle Feature Requests]] \| [[How we handle Bug Reports]]</div>		<div class="docs-related-pages">[[How we handle Feature Requests]] \| [[How we handle Bug Reports]]</div>

−	~~Coming soon~~.	+	This document explains how we manage Bug Reports regarding the WHMCS Software.
		+
		+	WHMCS is a powerful and feature rich product used by tens of thousands of companies, of varying sizes, all around the world. From time to time, users may identify reproducible examples of unintended behaviour and we encourage users to report these using the Bug Report form so they can be investigated further.
		+
		+	===Making a Bug Report===
		+
		+	We welcome Bug Reports via our the form here: https://www.whmcs.com/members/bugreport.php
		+
		+	===Tips for Submitting a Good Bug Report===
		+
		+	* Clearly explain the problem you are experiencing and how you expected WHMCS to work
		+	* Provide detailed steps of how to reproduce the issue - detailed steps (or even a video!) avoids the need for our team to ask further questions so we can try and reproduce the issue and ensure faster handling of the bug report
		+	* State any relevant configuration option setting values which relate to the feature you're having an issue with
		+	* Provide real world examples where possible
		+
		+	===How we Handle Bug Reports===
		+
		+	When we receive a bug report, we will go through the steps below to verify the issue and where confirmed we will then create a case internally to have the issue investigated further and gather further information.
		+
		+	Once issues have been identified, we will then monitor the issues and gather further information so that our team can consistently monitor and prioritise the issue with the development team.
		+
		+	'''Step 1: Validation'''
		+
		+	The first step in our Bug Report process is to attempt to verify the reported issue on our testing environment. This
		+	may require us to ask for further details if necessary to enable us to reproduce the issue described.
		+
		+	We will use the details provided to try and replicate the settings used and the steps provided to replicate the issue. Should we confirm the behaviour described, we will then confirm if this is as designed, or if it does indeed represent a bug.
		+
		+	'''Step 2a: Issue Confirmed'''
		+
		+	When we are able to replicate the reported bug and confirmed it is unintended behaviour we will then create and internal bug case with the steps to reproduce, and details of the issue so it can be investigated by our developers.
		+
		+	We will provide the reporter with the case number which will also be shown on future [[Changelogs]] once the issue is resolved.
		+
		+	Our team will monitor and review bug reports, ensuring sufficient detail is available for our development team to investigate and resolve the issue, as well as re-prioritising issues based on the impact and prevalence of the problem.
		+
		+	'''Step 2b: Not Reproducible/Not a bug'''
		+
		+	When we are not able to replicate the issue described or have determined it is by design, we will then transfer the bug report ticket to our support team to assist the customer further in resolving the issue on their installation or possible ways to achieve their ideal outcome.
		+
		+	===Bug Report Status Definitions===
		+
		+	Below is a list of all bug report statuses along with an explanation of what they mean.
		+
		+	<table class="table table-striped">
		+	<tr><td>'''Status'''</td><td>'''Description'''</td></tr>
		+	<tr><td>UNCONFIRMED</td><td>All reports start life in this status. At this stage we have not yet reviewed and verified the reported issue.</td></tr>
		+	<tr><td>NOT A BUG</td><td>We have determined the reported issue is intended behaviour.</td></tr>
		+	<tr><td>NOT REPRODUCIBLE</td><td>We have been unable to reproduce the issue in our test environment, the ticket will then be transferred to the support team to assist further.</td></tr>
		+	<tr><td>CONFIRMED</td><td>We have been able to reproduce the issue and have confirmed it is not intended behaviour. We will raise an internal bug report for our developers to investigate further.</td></tr>
		+	</table>
		+
		+
		+	__NOTOC__

← Older revision		Revision as of 13:19, 27 August 2019
Line 1:		Line 1:
		+	<div class="docs-related-pages">[[How we handle Feature Requests]] \| [[How we handle Bug Reports]]</div>
		+
	Coming soon.		Coming soon.