Content provided by Peter Fisher. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Peter Fisher or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

146 - What makes an acceptable bug ticket

42:21
 
Share
 

Manage episode 319458707 series 2674787
Content provided by Peter Fisher. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Peter Fisher or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

Change log

  • We got to lesson 4 of the PHP course on Tuesday. Lots of bad documentation has been fixed
  • Working on a Jenkins server for HTCW as I want to move away from GitHub Actions
  • We’re getting another English Springer Spaniel called Goose in a few weeks time. He will only be a puppy
  • I am giving a new talk called coding with confidence using PHPStan at PHP South West next Wednesday.

What makes an acceptable bug ticket

  • Bugs are not equal and no bug should be treated equally. Therefore no ticket is equal nor should the ticket be created or processed equally.
  • Bugs come in various shapes and sizes.
  • There is a fine line between having too much or too little process
  • A ticket which requires over processing in its lifespan will slow down delivery of the fix. This is due to the amount of red tape needed to record and fix the bug
  • A ticket which doesn’t require the right amount of process during its lifespan will slow down the project as the actors that influence or oversee the ticket may have insufficient information required.

Usually a bug is categorised by priority.

  • P1 is critical
  • P2 is less so and so on

We are skirting around the ITIL change management process

  • An incident is not the same as bug or an issue
  • An incident is an unplanned interruption. An incident could be a bug after investigation
  • A bug is a fault in the system found by a tester and accepted by the developer
  • A issue is a business question that could needs to be addressed. The app doesn’t work on X but should it?

I have not done ITIL (Information Technology Infrastructure Library) training so please don’t see me as an authority on change management or IT service management disciplines.

In my opinion the the minimum a that a bug ticket should have are:

  • A heading that quickly summaries the bug
  • Clear and concise steps to reproduce the bug
  • Clear requirements and environmental setup
  • Clear acceptance criteria (A definition of the correct behaviour)
  • Clear priority and the priority definitions
  • Clear understand of the bug impact

  continue reading

201 episodes

iconShare
 
Manage episode 319458707 series 2674787
Content provided by Peter Fisher. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Peter Fisher or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

Change log

  • We got to lesson 4 of the PHP course on Tuesday. Lots of bad documentation has been fixed
  • Working on a Jenkins server for HTCW as I want to move away from GitHub Actions
  • We’re getting another English Springer Spaniel called Goose in a few weeks time. He will only be a puppy
  • I am giving a new talk called coding with confidence using PHPStan at PHP South West next Wednesday.

What makes an acceptable bug ticket

  • Bugs are not equal and no bug should be treated equally. Therefore no ticket is equal nor should the ticket be created or processed equally.
  • Bugs come in various shapes and sizes.
  • There is a fine line between having too much or too little process
  • A ticket which requires over processing in its lifespan will slow down delivery of the fix. This is due to the amount of red tape needed to record and fix the bug
  • A ticket which doesn’t require the right amount of process during its lifespan will slow down the project as the actors that influence or oversee the ticket may have insufficient information required.

Usually a bug is categorised by priority.

  • P1 is critical
  • P2 is less so and so on

We are skirting around the ITIL change management process

  • An incident is not the same as bug or an issue
  • An incident is an unplanned interruption. An incident could be a bug after investigation
  • A bug is a fault in the system found by a tester and accepted by the developer
  • A issue is a business question that could needs to be addressed. The app doesn’t work on X but should it?

I have not done ITIL (Information Technology Infrastructure Library) training so please don’t see me as an authority on change management or IT service management disciplines.

In my opinion the the minimum a that a bug ticket should have are:

  • A heading that quickly summaries the bug
  • Clear and concise steps to reproduce the bug
  • Clear requirements and environmental setup
  • Clear acceptance criteria (A definition of the correct behaviour)
  • Clear priority and the priority definitions
  • Clear understand of the bug impact

  continue reading

201 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide