Blog

go back to the blog

Testing with the End in Mind

  • 15/10/2010
  • 7511 Views
  • no comments
  • Posted by EuroSTAR
-->

In his masterpiece “The 7 habits of Highly Effective People”, Stephen R. Covey  gives a lot of advice that can readily be applied to testing.
Here, I’d like to single out “Begin with the End in Mind”.

Whenever I am asked to test something that will be built using iterative methods, I want to foresee the complexity as it will be at the end of the project. Thus, I will try to automate simple stuff, and set up a testing framework when there is still some time to do so. In terms of test environments, accounts, and the like, I make an inventory at the start of how I foresee my needs at the end. With that list in hand (and probably, in a test plan), the actual arrangements can be delegated.

It goes further than this. I want to Be Proactive in assuring that designs are testable. That means designing them with testing in mind, doing work in the right order, reducing unnecessary complexity. I once saw a team trying to make a sketch on a whiteboard of a screen with dozens of options. For testing, there would be millions of combinations. They had considered splitting the screen up in a wizard-style format, but had not pursued it yet because the customer had asked for a single screen. I told them to discuss it with the customer anyway. One phonecall later they needed three whiteboards. But the team was all smiles, as the work would be easier to test, and easier to divide over the team.

A team can take a further step, by annotating each user story with a short answer of how it will be tested and demonstrated. Hopefully, the customer can give valuable input on this, leading to examples which can readily be converted into automated tests checks. The point here is that filling in the “How to Test” section should be common practice. Alarm bells should rinkle if no-one on the team can think of a simple test approach for a particular story. Some teams will even put it in their ‘Definition of Ready‘: before deciding that a story can be picked up in a sprint, the team must understand what needs to be build and also how it should be tested. And sometimes, all that needs to be documented (and discussed with the customer) is the extent to which tests can be executed.

For example, I frequently face links to external systems that are unavailable in any of the test environments. If the customer understands and accepts the risk of going ‘live’ with components that could only be tested with mock objects, then it is his decision. [I’m not at liberty to give a juicy example here. In situations where the customer took such a risk, I have certainly been in the “told you so”-situation.]

Another aspect of “Testing with the End in Mind”, is the notion that someone else might have to take over your tests, to maintain and repeat them long after you are gone. I think most us have had experience with poorly documented testware that was hard to interpret, or hard to get it running. It does not have to be like that. For example, if a team has coding standards that also encompass testware, if testware is reviewed and put into source control, then those measures ought to ensure that the testware remains usable.

A team that treats testware in the fashion outlined above, is well on its way to implement Acceptance Test Driven Development ( ATDD) and Collective Test Ownership. The remaining components are team commitment and knowledge sharing. Testing knowledge needs to be shared actively, to enable team members to maintain each other’s testware. Team commitment is needed to ensure that maintainance and execution of tests is actually done, even if it means tedious work on tests that were not automated.

The team will benefit from this sharing of knowledge, in several ways. Team members learn from eachother, understand eachother’s work better, and become more quality aware. If something bad happens, such as a team member becoming unavailable for the rest of the iteration, then it is far easier for others to fill the gap. If a new member joins the team, it is far more clear which knowledge needs to be shared to bring them up to speed, and how.

That brings me to end of this series of posts, for now. It’s been fun. Let’s all test and post with the End in Mind.

Blog post by

go back to the blog

eurostar

Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery