External reference

Managing Technical Test Debt

Testing Experience Magazine

Sometimes I want to leverage the blog as a means of sharing other content that I’ve developed. Sometimes it will be a magazine article, or a book excerpt or a set of Powerpoint slides.

Often the content will be much longer and richer than a single (or series) blog post. I hope that is not off-putting and that you’ll download the content and read it.

This is an article I wrote on for magazine in June 2012.

Spring boarding from the notion of Technical Debt, I extend the metaphor to include aspects of software testing and automation. I find it helps to think this broadly when considering technical debt.

I hope you find value in it. Stay agile my friends,

Bob.

Bob Galen

Bob Galen

Bob Galen is an Agile Methodologist, Practitioner & Coach based in Cary, NC. In this role he helps guide companies and teams in their pragmatic adoption and organizational shift towards Scrum and other agile methodologies and practices. He is a Principal Agile Evangelist at Velocity Partners. Contact: bgalen@velocitypartners.net

One Comment

  1. Oscar Mullin

    Hi Bob,

    Very interesting article. I agree with you in many of the categories listed. As you said, you didn’t try to show the full list of potential TTD cases, and I would like to add at least two to the list which I believe are very important and usually get overlooked becoming very fast in costly TTD:
    1. Adding new test cases to release regression test plans (this includes analysis, integration, deployment, etc)
    2. Re-testing defects that were not fixed in a couple of sprints (due to complexity, priority,release date, etc), that then got fixed but there is no time to test them in the sprint

    Regarding what you said about Testing Craftsmanship and Doing things right the first time, I think that testers (as well as the rest of the team) should stay motivated with their work (part of Emotional Intelligence) which in turn will end up being the catalyst to do things right from the very start. If people is not motivated, then usually this things happen.

    Regarding Developers not doing their part in keeping up with quality (unit testing, code review, etc), IMO this should be part of the DoD. As such, it should not ever be TTD because it should be tackled timely in order to close the story.

    Finally, I think that testers within the team should encourage / coach / help other team members to understand the right way to test things. The mindset of a tester and a developer is not the same, so the testers should work closely with developers to help them develop significant unit tests (and any other level of testing), with the product owner to make him/her understand the importance of well-defined acceptance criteria and so on.

    Very nice article :)

Leave a Comment