After years of quality management and web development, I always had the feeling that there is something wrong with the way we are testing. It was not like we had no idea what we were doing. The team and I were experts in functional testing with Codeception, unit testing with PhpUnit, performance testing with JMeter and we wrote our own testing tools.
We tested all new features the dev teams wrote. Minor features, major features, proof of concepts or user wishes. We were proud to have a high coverage for unit and functional tests. When we released a product you could be sure it was built the right way.
Then there was the 2011 Google test automation conference with Alberto Savoia. The topic was “Test is dead”. It was my eye-opener and the inspiration for the lean testing methodology we invented shortly after.
Let’s have a look at modern web projects. There is that idea we are sure it will be the next success story. We take our best developers and build a product everybody agrees on in terms of functionality, quality, architecture, and performance. The standards were very high in those days.
But in most cases this approach is wrong.
When creating new software one thing is very important. Building the right thing. Although it sounds similar it is something completely different from building that thing right.
Reid Hoffman, the founder of LinkedIn, once said
“If you are not embarrassed by the first version of your product, you’ve launched too late.”
And that is so true. The first thing you have to validate is the market. Will the product be a success? In most cases NO, but that is another story. Having that in mind the new feature or product should be hacked as dirty and fast as possible. It should only look like there were high standards in mind. Doing so there will be a prototype users can use in a very short period of time.
After this first version is live we can begin to learn. Learn what the user really wants and see if the product can be popular. If not, it is much easier to throw away a crappy piece of software than a well-designed masterpiece.
Sounds easy? But there is still one tricky part. What if the idea was good and people are really using it? That is the moment where the product owner has to trust the development team. They have to decide what to do. Refactor the code, rewrite it or keep it. Everything is possible. Just trust the team.
