Bugs - NextensArelB/SwaggerGenerationTool GitHub Wiki

When testing and actual behavior is different from expected behavior, it could be a bug (it is described in the requriements/user story) or a new task/PBI (it is not described in the requriements/user story)

How to determine if it is a bug or a task/US? Is the expected result described in the acceptance criteria or design

  • Yes, it is a bug
  • No, it is an RFC (request for change) and thus a task or a User Story. It has not been taken into account during refinement or development, as it was not documented, therefore it is a change

Yes, create a bug

  • It might be useful to create a template for a bug, in this way it is easy to enter all the information without the possibility to forgot anything
  • Bug title: [Feature abbreviation][Subject eg xbrl, UI, report] short logical description
    • example [Erv][Bezt][XBRL] 2 xbrl fields are missing
  • Bug description: describe repro steps (which page, which actions/steps, which user role and authorizations), including actual result and expected result
  • If applicable: add environment
  • Add screenprints and used test data
  • Add logging and other evidence out of Management Portal and Console (F12)
  • For fiscal apps:
    • Add xbrl files: this file can be used to compare with the new XBRL when retesting
    • Add report: this can be used to determine which test data exactly has been used when the bug occurred, to mak sure the exact situation is retested
    • Add a data export (export aangifte): this can be used by QTA or by DEV to reproduce and/or to retest
  • Indicate the priority (high, medium, low) to know for dev's which bugs should be picked up at first

No, Is the RFC a task or a User Story?

  • Can it be fixed within the scope and time of a related open User Story
    • Yes, log it as a task in that User Story, assign it to DM and have a discussion on when and where to pick this up
    • No, it can not be fixed within the scope and time of a related open Feature, log it as a User Story in that Feature, assign it to DM and have a discussion on when and where to pick this up

Retest a bug It is not sufficient when retest is completed, to mention test OK in the bug, especially when it is a complex bug. Therefor at least do the following:

  • Add screen print with the correct result, including test data
  • Add other prove:
    • Correct XBRL
    • Report

The proof is needed, especially when audit trail/track back is required in case of production incidents.

⚠️ **GitHub.com Fallback** ⚠️