Skip to content

Instantly share code, notes, and snippets.

@Gits-hub
Last active May 25, 2024 11:16
Show Gist options
  • Save Gits-hub/61c236d67ad930479082cb27e14a9e6d to your computer and use it in GitHub Desktop.
Save Gits-hub/61c236d67ad930479082cb27e14a9e6d to your computer and use it in GitHub Desktop.
bqa_report

Bug, Improvement and New Features


I would like to briefly explain the difference between Bugs, Improvement/Adjustment and New Features as I have come to understand from a development POV

Bugs


These are coding errors that produce unexpected behaviours that were not anticipated by the developer. It can be either visual bugs (user completes given function but something about the ui looks wrong. Often its an error resulting from responsiveness). E.g.,

A large button that does not fit well in smaller screen resolutions

or functional bugs(error in computation or logic that leads the app to not work as intended or produce flawed results) E.g.,

A form submission produces errors instead of saving information or a certain link is broken

Improvements/Adjustments


These are actions or visual components that appear and/or work as intended but can be reimplemented to improve overall ui/ux or fit certain preferences. E.g.,

Changing a text input to a dropdown to capture data.

Removing unused api calls.

Note: Some Improvements could double as new features and vice versa if they include adding more to the functionality. Similarly some improvements could also double as bugs if they significantly affect operations on the app i.e significant RTT or TTFB . It is sort of a grey area

New Features


These are any features than are not found or plainly stated in the original SRS (Software Requirement Specifications) or contradict a feature in the SRS. The SRS is a document that we developers frequent visit to get an idea of what they are building.

A brief example of what a new feature is:

Section 14 in the SRS under Subscription settings second line contradicts this ticket raised on bugboard.co

I would kindly suggest for the team doing testing to follow this when raising tickets. It helps with prioritizing based on the Urgency of a bug like a break in a core app feature. If unsure of where the ticket falls under it can be placed at the bottom of the Backlog list and while reviewing I'll transfer to the correct list.

I would also kindly suggest caution exercised when using terms like 'Regression errors in application'. Most of the bugs raised once closed, that part of the application is not really touched again unless new features that involve that feature are raised thus if a ticket was passed and no feature involving that feature has been implemented, ideally old tickets should not reappear. Errors can only reappear if

  1. The environment tested on changes
  2. The codebase was changed

More on this below.

Some Issues I came across


  • Some bugs like the 'Leave Job' feat not working seem to be a problem that occured from commits not on our side or maybe configs of something on clients server since on my local copy and test deployment it works as expected. If this was a regression error, local copies and the test deployment we have should replicate the errors. I would suggest for anything that feels like a regressed error to also be tested on a local copy too.

  • A couple of new features introduced as 'bugs'. Will move them to relevant list.

  • Some tickets are introduced as bugs over and over again.

Adjusting start end dates on project creation/edit first occurrence

Adjusting start end dates second occurrence

third ticket occurence on board

  • Generalization and/or Contradiction of certain features that leads to ambiguity of what is to be implemented.

Last section ai waiting list, add mockup and analytics and reports to be expected??

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment