WOPR21

WOPR21 was held in San Francisco on October 17-19, 2013, and was hosted by Salesforce. Mais Tawfik Al-Khoury Ashkar was the Content Owner.

Attendees

Goranka Bjedov, Mahesh Dathrika, Dan Downing, Jane Fraser, Thomas Frasher, Matt Geis, Andy Hohenner, Paul Holland, Dave Holt, Pam Holt, Felipe Knorr Kuhn, Reena Mathew, Jude McQuaid, John Meza, Ashok Murthy, Eric Proegler, Keith Stobie, Mais Tawfik Al-Khoury Ashkar

Theme

Technical Debt and its Impact on Performance and Reliability Testing

Technical Debt is widely defined as engineering work that has been deferred for a variety of reasons, usually as a compromise to meet business pressures and delivery deadlines. This compromise may be the result of “requirements re-engineering” – redefining success late in a project.

Technical debt is not limited to deferred work in engineering; debt can be incurred in testing practice. So far, we are calling this “Technical Test Debt”. Some clear examples are overemphasis of positive test cases, insufficient depth/breadth of test coverage, and deferred test automation/performance test coverage. Less obvious effects are unresolved or poorly escalated performance, scale and reliability vulnerabilities that do not get properly addressed due to lack of exploration and advocacy. Activities like training and test environment maintenance are often the first to be abandoned when schedules become compressed.

In engineering, the interest on technical debt is immediate compromises to engineering quality, including increased risks and issues with performance, scalability, reliability, stability, and security. Second order effects include delayed delivery of newer features, higher maintenance and support costs, and more time spent firefighting. Cultural effects like lower confidence in the system among users and program members, mutual mistrust, increased cynicism, and lowered engineering standards are rarely considered.

This workshop will explore the circumstances and negotiations around incurring technical debt, the consequences of incurring it, and working with existing technical debt.

Contexts For Experience Reports

We are interested in your experiences relating to technical debt decisions that jeopardized testability, performance, scale and reliability, the failures encountered, the extent of damage, efforts to resolve, and the lessons you learned from these failures.

Here are questions to consider as you explore this theme and your relevant experiences:

1. How did technical debt impact the performance and reliability testing of the system?
2. How did technical debt compromise the architecture of your application?
3. How did technical debt impact performance troubleshooting, diagnosis and tuning efforts of your system? 
4. Did technical debt impact scalability & reliability KPIs?  What type of failures did you encounter and what were the consequences? 
5. How did technical debt impact instrumentation, monitoring, alerting and reporting practices targeted for revealing performance and reliability bottlenecks? 
6. How did technical debt impact maintenance and extensibility of your tests? 
7. Did you adapt your testing practices to include “testing for debt” to continue alerting on vulnerabilities? 
8. When compromises have already been made, how do you engage with your context to work with Technical Debt? 
9. What type of Debt mitigation techniques do you practice? For example:
   • Are you involved in reviewing architectural design and integrity? 
   • Do you facilitate communicating impact of debt on testability, performance & reliability of the system? 
   • How do you propagate awareness upstream and downstream (e.g.  Do you measure, alert and report on impact to those areas)?

Work Products

Blog entries on this site and elsewhere to come(?)

Private workshop collaboration space here.