A Collaborative Approach to Test Debt

Testing activities should neither end with the release of the product nor once test documentation is complete, but should continue with the reduction of any test debt. Test debt is essentially a form of technical debt. Like technical debt, test debt is incurred during a project when compromises are made in the creation of test assets for schedule or resource constraints. It is not always negative, and may be necessary to achieve testing goals for coverage, diversity, and other factors (e.g. automation). Often test debt is captured as a collection of suggestions gathered in retrospect to increase testing efficiency, quality, and coverage in subsequent versions and products. The testing process should include a collaborative approach, and should be planned and executed for maximum success.

Reducing recurring errors, increasing test efficiency, raising product confidence, and enabling team growth are all beneficial outcomes of having a process for reducing test debt. Reducing recurring errors can be accomplished by analyzing improvements within the testing scope of the past product. It heavily reduces the likelihood of repeating past mistakes. For example, test case templates could be created and published to mitigate readability issues and increase manual testing performance. Updating policies and increasing backend education might be other important implementations. Test debt elimination may need to be implemented in a testing lifecycle policy and backend education might include informal database classes or hardware familiarization. Another outcome, increased test efficiency, is integral to maintaining a demanding product schedule. Within a larger scope, it may allow more testing within the same amount of time or allow your company to release a better product in less time with greater product confidence and quality. Team cohesion is another beneficial attribute of test debt. Testing teams that assemble to coordinate and address possible shortfalls without blaming will increase in growth through productiveness and communication for future collaborations.

Even more benefits can be associated with the collaborative approach when compared with a test department debt elimination process. Examples of such benefits include interdepartmental cohesion, cross-team perspectives, transparency, and the opportunity to gather and eliminate more debt. Inviting engineers, software developers, and product managers to join the process will not only increase trust, but also open the lines of communication between departments. This can be crucial for future communication during the development lifecycle and offers opportunities to alleviate any prior tension between departments. Different perspectives from outside the test department are also important. It can be all too easy for test departments to have a blind spot toward their own practices and policies. It has long been known that independent testing is the most beneficial because it uncovers issues previously overlooked. This practice also applies to gathering test debt, whereas the ‘independent testers’ are interdepartmental peers. They may not share the same test perspective but rather offer a managerial or a developmental perspective that might help eliminate areas of weak or non-existent testing. A collaborative approach allows for greater transparency to achieve greater success. No one likes publicly admitting that their previous efforts can improve, therefore there is a natural tendency to hide test debt. Frequently this lack of acknowledgement is due to a stigma coupling transparency with failure in the test debt lifecycle. This stigma should not prevail because humans are not perfect and thus, everything can be improved upon. There is no shame in testing efforts constrained by time or limited personnel. The gathering and elimination of test debt needs to be open and transparent because transparency prevents surprises in all echelons. Many times, surprises cost time and money, and are generally frowned upon by superiors. Lastly, more debt will be accumulated through collaboration. Participation from other departments correlate directly with the amount of constructive debt collected. This benefit is closely related to differing perspectives.

The test debt elimination lifecycle should include three main phases: identification, comment, and execution. Test debt awareness should be prevalent throughout all stages and should ensure visibility and maximum participation between departments with regard to scheduling. Examples of the identification phase include scheduling test debt meetings, constructing formal test debt documents, prioritizing deliverables, and even refining current test debt elimination policies. The comment phase involves items such as sending emails to all applicable employees and ensuring high visibility. It should not be a simple invitation, but rather an encouragement of participation with ground rules and a preparation assignment. Preparation should be a stated individual responsibility so the scheduled meeting can flow smoothly and constructive debt can be collected from every department. Publicity also is important for accountability. All participants and supervisors should receive emails that display all debt gathered and the appropriate actions necessary. Execution follows planning and publicity and its result should complete the test debt lifecycle depending on the product and product lifecycle. The debt should be itemized, prioritized, and assigned to an individual for elimination and implementation. Execution should not only include the elimination of current test debt, but also involve the elimination of possible future test debt by updating policies and formal document submissions.

To continually improve, test debt reduction should be practiced always, regardless of one’s ability to coordinate collaboratively or individually, but for optimal results, a collaborative approach is required. It is important to understand that every product is unique, therefore many factors can affect the required compliance deliverables. Also important, is proper risk management planning that should guide the overall test debt plan. Even though considering risks and unique products seems burdensome, a plethora of benefits can be gained from applying test debt reduction to current processes which is applicable to each and every product. Take the first step to reducing test debt and include it in current testing processes.

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

TBD

 


 

Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: March 7 & 28, 2024

Virtual via Zoom

Registration Link:

Register Now

 


 

Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN, TX) and Canada.