Re: Records of the results of action taken (8.5.2e)
I'll chime in on the disagree side, especially since this question was asked in a quality-oriented forum. When a software organization has to respond to a defect that was found outside the organization, they have responsibilities that go beyond just fixing the "bug". While they may not look like the traditional definition of root-cause analysis, corrective actions and preventive actions, that's exactly what they are from a software development perspective. Those responsibilities include:
- An approach to the defect that verifies that not only was the symptom addressed, but that any underlying root-cause was considered and targeted in the process.
- Regression testing of the rest of the software to prove that the fix to this defect didn't introduce other defects.
- A review of the original design process for the affected area of the software to determine how the bug was introduced.
- A review of the validation process for the affected area of the software to determine how the bug escaped detection.
Those aren't academic nice-to-haves... they're just being professional about software development. The fact that the organization in question only has two software developers makes this kind of professionalism even more important, because losing one person can result in an enormous loss of institutional memory.
For what it's worth, our software development is done by only two individuals (using pair programming). In the rare case that a defect finds its way into the product, our process is:
- Document one or more "acceptance criteria" to describe the behavior that should have succeeded but failed.
- Add a high-level automated acceptance test to duplicate the defect, with the acceptance criteria directly annotated as attributes on the test code (for traceability from the description of the problem to the testing of the effectiveness of the resolution).
- Run the acceptance test to ensure that it correctly fails for the existing version of the software.
- Examine the existing unit tests for the affected software area to determine why there wasn't a test to catch this defect.
- Examine the affected software area to determine any underlying root causes for the defect.
- Execute our normal test-driven development process to implement the fix for the defect.
- Run the automated acceptance test to verify that the fix correct the defect as described.
- Refactor the existing test suite as necessary to make it more difficult to miss those tests in the future.
- Refactor the existing application code as necessary to make it more difficult to introduce this type of defect.
- Run the entire test suite to ensure that no regressions were introduced.
Corrective actions. Preventive actions. Continuous improvement.
This isn't rocket science... it's just being professional about developing a product for a customer, and being able to look them in the eye and tell them you did everything possible to produce a quality product.
I would suggest that your software developers consider educating themselves on where the industry has evolved over the past two decades, and adopting agile software development practices that ensure a more professional relationship with both internal and external customers. It's an investment that will pay dividends both in the short-term and long-term. I've been developing software for 25 years now, and I'll never go to work for an organization that doesn't invest in a process like this.
For what it's worth, everyone involved in our process loves it, especially the customers. And given that we develop quality system software for medical device companies, that's a hard audience to satisfy.
Good luck, and feel free to ping me with questions about the devil in the details.
Jim Ivey
Grand Avenue Software
I'll chime in on the disagree side, especially since this question was asked in a quality-oriented forum. When a software organization has to respond to a defect that was found outside the organization, they have responsibilities that go beyond just fixing the "bug". While they may not look like the traditional definition of root-cause analysis, corrective actions and preventive actions, that's exactly what they are from a software development perspective. Those responsibilities include:
- An approach to the defect that verifies that not only was the symptom addressed, but that any underlying root-cause was considered and targeted in the process.
- Regression testing of the rest of the software to prove that the fix to this defect didn't introduce other defects.
- A review of the original design process for the affected area of the software to determine how the bug was introduced.
- A review of the validation process for the affected area of the software to determine how the bug escaped detection.
Those aren't academic nice-to-haves... they're just being professional about software development. The fact that the organization in question only has two software developers makes this kind of professionalism even more important, because losing one person can result in an enormous loss of institutional memory.
For what it's worth, our software development is done by only two individuals (using pair programming). In the rare case that a defect finds its way into the product, our process is:
- Document one or more "acceptance criteria" to describe the behavior that should have succeeded but failed.
- Add a high-level automated acceptance test to duplicate the defect, with the acceptance criteria directly annotated as attributes on the test code (for traceability from the description of the problem to the testing of the effectiveness of the resolution).
- Run the acceptance test to ensure that it correctly fails for the existing version of the software.
- Examine the existing unit tests for the affected software area to determine why there wasn't a test to catch this defect.
- Examine the affected software area to determine any underlying root causes for the defect.
- Execute our normal test-driven development process to implement the fix for the defect.
- Run the automated acceptance test to verify that the fix correct the defect as described.
- Refactor the existing test suite as necessary to make it more difficult to miss those tests in the future.
- Refactor the existing application code as necessary to make it more difficult to introduce this type of defect.
- Run the entire test suite to ensure that no regressions were introduced.
Corrective actions. Preventive actions. Continuous improvement.
This isn't rocket science... it's just being professional about developing a product for a customer, and being able to look them in the eye and tell them you did everything possible to produce a quality product.
I would suggest that your software developers consider educating themselves on where the industry has evolved over the past two decades, and adopting agile software development practices that ensure a more professional relationship with both internal and external customers. It's an investment that will pay dividends both in the short-term and long-term. I've been developing software for 25 years now, and I'll never go to work for an organization that doesn't invest in a process like this.
For what it's worth, everyone involved in our process loves it, especially the customers. And given that we develop quality system software for medical device companies, that's a hard audience to satisfy.
Good luck, and feel free to ping me with questions about the devil in the details.
Jim Ivey
Grand Avenue Software
