Additional analyses of bugs root cause.
I use this tab for analysis from where the bug has come. The analysis is done based on the source code changes – I go through versions and find the change that causes the bug. I have a number of reports that use the data from this tab for presenting situation with bugs in different dimensions. It is rather useful for analyses the week point and directions of development process.
- Root Cause – first level cause, it indicates from whom bug has come. The dropdown list contains the following values:
- Business – the error has come from business side – wrong design, the functionality was not tested etc.
- Development – the error has come from IT development team side – poor development, internal errors in code, incomplete test plan for business etc.
- Deployment – the error has come from deployment – incorrect merge, deployment manager’s errors.
- Unit Test – the error was found by unit tests.
- Maintains – server or net were down, or issues on server side that cause application to work not properly.
- No Problem – the application works as it has to, no code changes.
- Root Cause Level 2 – second level cause, it indicates the type of the error:
- Programming – the error was caused by poor programming.
- Testing – the error was caused by poor testing.
- Not complete test plan – the test plan prepared by developer does not contain all application sections that were changed during work on the task.
- Error in design – the error was caused by poor design.
- Without human agency – usually set for Maintains and No Problem root causes.
- Root Cause Date – date when the root cause task was deployed into production environment.
- Root Cause Req# – the number of root cause task (task – that creates the background for the bug).
- Root Cause Person – name of the developer or business that creates the background for the bug.
- Root Cause Code Reviewer – name of the code reviewer who can prevent bad code from deploying into production, but missed it.
- Root Cause Description – several words describing the values filled in described above fields.
Lost task analysis tab.
Helps us not to lose tasks and have a real master of each with date till some actions on the task must be done. I have one report that shows me if we have lost tasks.
- Review Date – the date till that the task must be closed or assigned to developer.
- Responsible – the master of the task, who has to deal with it.
- Comments – a field for Planning Manager’s notes.
When the task is assigned to developer and got Finished Date, the fields Review Date and Responsible are filled automatically from Finish Date and Assigned To fields accordingly. The Planning Manager has to set these fields manually to all new tasks that are not planned to be closed in several days. So responsible person has to assign this task till Review Date, or to prepare design and return the task to Planning Manager, or communicate with business to clarify something etc.