On my way back from the Agile Practitioners Conference 2013 in Tel Aviv, Isreal I digest lots of information and bar discussion content. After attending Dan North‘s tutorial on Tuesday, I have six sheets of paper on notes with me, that will probably fill my writing buffer for the next half year. Time to get started. Here I connect Dan’s model of the Three Ages to Software Testing.

What are the Three Ages? The Three Ages describe a model of growth for a product. The three different ages in short are Explore, Stabilize, and Commoditize. In these three different ages, you have different gaps to fill.

Explore

In the first, Explore, you focus on learning and discovery. In a software product sense, you start to learn about the problem that your customer has, ie. by interviewing him, by running minimal viable products, or by working in his context. At this point you want to find out as much as possible to make sure that you understand the problem well enough to do something about it, to solve it. Here you optimize for discovery.

In software testing you do the same thing in different ways. When doing Exploratory Testing, you are learning a lot. According to Wikipedia Exploratory Testing can

concisely [be] described as simultaneous learning, test design and test execution.

After executing one test, you can take the outcome of that test, to inform your next step. That might be to dive deeper into the system, to find out more about that possible bug you just observed, or to continue with your current mission.

And there is more. When doing session-based test management, you can use a touring approach to learn as much about a product as possible in a given time-box, to plan out more sessions to dive deeper. Here, you do the same exploration and learning loop on a broader level. You explore the application to inform the next step, that is to plan your test strategy for the next couple of sessions.

The same holds true for backlog grooming meetings that many teams nowadays seem to do. Here you try to explore the technical and business constraints. Why is this relevant for testing? This is relevant for testing that particular piece of software later, as you are able to consider different constraints for all the variables that you can find. Variables in short are anything that you can vary in a product or product domain. There are technical limitations like the amount of bits stored internally that you may vary, and there are business and domain constraints that you might want to explore. The specification workshop and the backlog grooming meeting is the place to find out more about these.

Stabilize

In the stabilization age you aim for repeatability. So far, your learning has proven that you can do it – once. Now is the time to prove a repeatable success with your product. Arguing from the Lean Startup model, you have analyzed the problems your customers are having, and now you start to evaluate whether your product solves the problem for your customer.

With regards to software testing, at this point I would consider the parts that I want to automate to free myself time to learn more about the product later. Usually, I aim for a trade-off between learning and repetition – fully aware of my second-order ignorance: the things I don’t know that I don’t know them. The stuff that I know, I can automate – but only to be able to learn more about the things I don’t know. This is where test automation is more useful than using my spare brain cells at boring repetitious stuff.

Commoditize

In the third age, you try to make your product a commodity. You have reached the point to scale your customer base, and should be able to constantly grow. In the Lean Startup sense, you have developed your customer base, and can now aim for the big market. You have proven that your product solves the business problem. Now is the time to scale, and make your business model more efficient to fit the target market.

Unfortunately I see a lot of software testing projects failing to realize that they need to make their test automation more efficient. In the model, they fail to understand the need to make automated tests as fast as possible – and to refactor existing automation code structures to be flexible in the near future.

The model in action

In retrospect I realized that I had used the underlying thought-process a few years back. One of my colleagues and I were called into a project which was half a year late. There were three weeks left, and no automated tests. My colleague and I sat together and identified different test charters, and different tests to run in the short timeframe.

For the first week we started with completely manual tests. That was hard, as the test setup times were quite long. Our goal here though was to learn more about the new business domain which we didn’t know at that time. By re-testing the bugfixes, we were able to conduct that learning. We were tackling with the first age.

At the end of the first week, I became impatient. We were doing the same tests over and over again. On that Friday we sat together, and identified what to automate first. We had reached the point where we learned enough, and it became time to enter the stabilization age. We lay out a plan to tackle the different use cases and come up with automation for all the bits. We focused on repeatability of those tests. Two weeks later, we were done with that, and had been able to support the on-going UAT in that time.

After that, the project continued, and we were able to enter the third age as well. We started to make the automated tests more convenient. We started to make the whole flow more efficient, cleaned up the test automation code, and updated the commonly used library that we had grown over time. This is the third age in Dan North’s model.

To me, the Three Ages appear to be a useful model to understand where you currently are, and what your current focus probably should be.