What if we rephrased bug reports as feature requests? What if there was no distinction between a bug fix request and a feature request? If we zoom out a bit, there is technically no difference between the two. Both are a statement about current behaviour (implicit or explicit) along with a request to change the behaviour.
The only difference between a bug fix request and a feature request, is that something would be considered a bug if there was a reasonable assumption that the current behaviour should never have happened in the first place.
It will likely still be valuable to know whether a given change request is considered to be a bug or a new feature, a label / tag / ticket type (whatever your ticketing system supports) should work just fine for these purposes.
Crucially, normalising the content and format for bug fix requests and feature requests into a single, generalised notation, could help to simplify these processes, such that you don’t have any special cases. Both types are treated in the same way.
Context
We’ve built and deployed a user registration form that doesn’t accept the “+” character in the email address input.
Approach 1: Bug Fix Request Approach
The email address input in the user registration form doesn’t allow accepting the “+” character
Steps to reproduce:
As a logged out user
When I visit the user registration page
And I type “test+1234@test.com” into the email address input
Then the email address input has the value “test1234@test.com”
Expected result:
The email address input should have the value “test+1234@test.com”
Approach 2: Feature Request Approach
Acceptance Criteria:
As a logged out user
When I visit the user registration page
And I type “test+1234@test.com” into the email address input
Then the email address input should have the value “test+1234@test.com”
Suggested Approach
Approach 3: Generalised Change Request
Current Behaviour
As a logged out user
When I visit the user registration page
And I type “test+1234@test.com” into the email address input
Then the email address input has the value “test1234@test.com”
Expected Behaviour
As a logged out user
When I visit the user registration page
And I type “test+1234@test.com” into the email address input
Then the email address input should have the value “test+1234@test.com”
This approach to requesting changes has a few advantages:
It releases people from the stigma that often surrounds bug reports (hopefully less, preferably zero, animosity between developers and testers)
Moves your mind into more of a “creator” mindset, rather than a “fixer” mindset (at least, it does for me)
Simplifies workflows into one model (yes, this is a slippery slope, there’s never one suitable model for all problems)
Probably more…
This approach also has a few disadvantages:
It feels “odd”, almost like you’re lying to yourself – “I know it’s actually a bug”
Most people will be confused by it, it’s not “the way we’ve always done it”
Tooling support might make it unreasonable to implement
Probably more…
I hope this subtle mindset shift helps you or your teams. It’s had a positive impact in the very limited testing I’ve done.
Nice! I think having 1 change request structure is a big win.
Also I like the fixer vs creator mindset. Could help the confidence of devs to be creating/extending their features instead of fixing issues with them.