Saturday, October 3, 2015

Test Early, to not Fail often

It was one of those usual yet unusual meetings. The product ownership team had summoned together a team of versatile experts. There was deep representation of the user base. There was sales and marketing. There was half of the development team, all "disciplines" represented with the project manager, the coding architect, the user interface specialist and the testing specialist. It was labeled "Concept" and little did we know what was coming.

It was a meeting to start something new, perhaps only a year later. It was an early chance of testing. And it taught me how important it is, yet again, to be testing early on.

As the meeting unfolded, I learned that the product we've been creating isn't optimal (easy to sell, hard to find market for) based on a marketing research done on one target market. And that something else would be more optimal. Something we did not have. At all. Something that would land in the same rough business neighborhood but that was not what we had been creating for the past three years.

It wasn't that we were told we had spent three years with features they did not want. There was a strong internal customer too, and they had significant competitive advantage with what we had created. It was great. But the other customers we would dream of did not see it as something they need. And we wanted to learn to create things others wanted too.

Clearly, something failed with how we had been testing our assumptions about the business opportunity. These kinds of failures of testing are in scales more expensive than any other mistakes we could do. The result of late testing can be that we will recreate everything, if we even get a second chance.

These kinds of experiences have made me a big fan of lean startup. The idea that you should test your business model's built in assumptions with smart approaches, going to the real customers and not taking their word for it when their money speaks volumes more to the truth. You can politely say something is interesting, but when you're asked to buy it, your actions will say if you were serious or not. In software, we should sell earlier - a major lesson I've learned over the years.

The same idea that I keep failing with at work in scale and practicing to handle better with suggestions of how we could test our business assumptions applies to my side projects. I'm pretty proud of myself for the agreed action items yesterday, that will dispel some of our illusions. I'm extremely happy to be testing early in great collaboration with people who never tell me that I'm "Just a Tester" because they've seen that testers like me are helpful finding good ideas of how we could know more of what's real and what's illusion

With my side project, the European Testing Conference, I don't want to fail in the same way I do with my work. I want to do what I do for my work: early testing. What we need to test is something others too consider valuable. We believe it is, in the organizer group. We are passionate in our belief that extending the learning we've already had between testers by profession and developers by profession within the organizer group, that will create a great conference. That there should be a space, a conference, in which we bring together the different worlds of developer testing and tester testing, build bridges and co-create cross-functionally.

We're inviting you to test with us. A Super Early Bird ticket I like to call "validate-the-need" ticket is now available for ridiculously low price until Oct 20th. We're creating a great conference that will teach you practical stuff. Will you trust us on that and be there with us?