Retrospective - Bug Fest Q4 2018
- Anton Emelianov (Deactivated)
FEEDBACK:
It would be very helpful to collect your feedback prior to running the retrospective meeting.
We will be using https://funretro.io/ tool to collect your feedback. It is being used by multiple FOLIO development teams and we though it would be a good idea to follow their steps.
Follow this link to the Bug Fest Retrospective board. It has very nice and self-explanatory user interface.
Please add your comments, thoughts, ideas to "Went well" and "To improve" columns.
If you like or agree with comments of the other contributors please don't hesitate to give them your vote of approval by clicking on the "thumbs up" button.
Also, we would appreciate if could provide your feedback on the following questions:
- Was it easy to follow BugFest instructions? Â
- Are there any gaps in the test case coverage?Â
- Should tasks provide more details and steps? Â
If you have any questions, please post them into Questions column. The answers will be provided during Retrospective meeting and subsequently on this page. Â
MEETING INFO:
Wednesday, January 23rd; 9AM New York Time. (check your local time)
If you have time conflicts please use bug-fest channel to let everyone know. We'll move the meeting if we get a lot of conflicts.
ACTION ITEMS:
Action items were aggregated from the retrospective board:Â
- Consider to use TestRail for subsequent Bug Fest runs
- Not all the areas of FOLIO were covered. Do next BF soon to cover them.
- Better scope definition is needed to avoid testing incomplete features.
- Always use real customer data.Â
- Original reference data must be migrated to the BF environment.
- Must have a planning meeting for every BF run: Define scope; Assign tasks to make sure that participants have time to complete them.
- Test cases for each module need to be reviewed with respective POs
- Discussion is needed about how long BF environment is staying up after test run is over.
- Discuss what should be bug workflow for the future BF runs.Â
Q&A:
Q: What happens next with the bugs?
A: Bugs were triaged. We assigned them proper priority. Several defects were closed after fixing performance problem. Another batch of bug was closed because they were filed against incomplete features. After that defects were moved from Bug Fest project to the respective component projects. It will be up to PO and the team to prioritize and assign them to a sprint.
 Â
Q: Unclear about proper way to handle several bugs filed which are covered by a more general issue. See, for example, STCOM-408, which is apparently the root cause of several Bug Fest bugs. Should those bugs be closed as duplicates of STCOM-408 or should they be linked up as blocked (as is currently the case)
A: It has been don properly. PO doesn't need to add these bugs to a team backlog but needs to check if the issue has been resolved after the main bug has been fixed. Linked bugs may require some specific work like fixing message test or modal window name.Â
Q: Not clear which browsers we should be testing in and what should be done with bugs specific to non-supported browsers (e.g. anything but Chrome). For example: UIIN-429
A: FireFox is not officially supported. Therefore this issue should be ignored at the moment.
Q: What to do with bugs that repro on BugFest environment but not in snapshot stable (e.g. UIREQ-193)?
A: It could be due to data size. In this case a developer should take a look at the BugFest system.
Q: How do we determine which team gets what bugs? Is it the team that originally implemented the feature? If this is the case, I assume the Core Functional team will get everything in Inventory, Codex, Users (except password management and fees/fines), Check in, Check out, Loan policies, Requests, most of Settings etc... That's a lot.
A: Yes, it is a lot. But we don't have a "sustaining" team, therefore these defects have to be assigned to the Core Functional team.