Additional checks for a Bug
...
Complete an Fault Slip-through Analysis (FSA) and add as a comment in Jira
Agree with Customer the FSA especially if there are any follow-up actions needed BEFORE closing the bug
| Expand | ||
|---|---|---|
| ||
Fault Slip Through Analysis
|
...
| title | FSA Fields and Options |
|---|
...
3PP
Critical Vulnerability
Documentation
Functional
High Availability
Install
Logging
Performance
Robustness
Rollback
Scalability
Security
Testware/CI
- Upgrade
...
- Insufficient test coverage
- Intermittent Fault/Timing Issue
- Missed impact
- Missed in code review
- Missed in design analysis
- Missed in document review
- Missing requirement
- Unrealistic Development timeframe
- Late requirement: insufficient analysis
- Environment
...
- Design
- Review
- Automated (unit) Test
- Microservice CI (CIST)
- Release
...
- Unit
- Integration Test
- Performance
...
FSA Introduction
Fault Slip Through Analysis is a tool designed to improve team processes and test scopes, specifically targeting the detection and prevention of faults that might otherwise be overlooked or discovered too late in the development cycle.
This approach acknowledges the inevitability of bugs in software development but focuses on learning from these occurrences. By analyzing why bugs happen, teams can identify and rectify gaps in areas like experience, domain knowledge, planning, understanding requirements, documentation, and testing. This reflective process, is not merely procedural but a critical learning opportunity aimed at enhancing overall quality. When embraced fully, it leads to continuous improvement, evidenced by fewer bugs, earlier detection, and better alignment with the appropriate testing phases.
This approach is most effective when integrated with comprehensive retrospectives, shifting the perspective from a routine task to a vital component of quality assurance and team development
FSA Expectations on Developers/Teams
Accurate completion of fields in Jira Bugs/TRs is crucial for identifying trends and formulating improvement actions. Recent Fault Slip Through Analysis (FSA) indicates a need for clarity in team responsibilities and the distinction between Corrective and Preventive actions. Below are further details on Preventive action:
- The developer who answers the JIRA should be filling in the Fault Slipthrough Analysis
- Fill in the relevant fields. See descriptions of the fields below.
- Discuss (if needed) with other team members what the preventive action should be if unsure. Don't just put the first thing that occurs to you. Take time to ensure you understand the main reason for the fault and the reason for slipthrough and ensure we have good preventive action as this is the key learning from the activity.
- Examine the fault from both CPS test perspective. Why did the fault slip through our design process and why did the verification activities not catch the faults. Both areas are important to consider. (CPS & EIC)
- The preventive action should ideally be included in the team improvement plan if appropriate. if an action in that plan already covers the improvement, just refer to that improvement.
- Review the FSA fields with relevant team members and PO. The review should cover all the relevant fault slip through fields in the Jira.
- If an improvement is identified, Create the improvement JIRA and label them as per guidelines so it will appear on Dashboards/Confluence tracking FSA improvements here. Reference this improvement Jira in the bug preventive action field.
- The developer/Team should indicate Team review of FSA has been completed and request/inform PO/Tech Lead the FSA is ready for review by labelling the Jira as per guidelines
It is recommended to hold a proper meeting and the team can take ownership to approve any improvement/suggestion proposed in preventive action.