why testers and developers are not the same in practice, but are equally valuable. Over the last year Ole Lensmar has had the opportunity to attend a number of extremely interesting and mind-expanding conferences focusing on emerging and somewhat disruptive technologies and companies: APIs, mobile, cloud, big data � the works. Coming from a quality background, it has stricken him how little focus these companies give to testing. They talk plenty about continuous integration, agile methodologies, user groups and continuous deployment � but testing? Nope. Why is that? First he explains in his article what he means by testing. He doesn't mean unit tests. He doesn't mean BDD or TDD based on some cool-named framework using a custom DSL to describe scenarios. He doesn't mean recorded and automated scripts of your website or application. Much of this is being done by many of these companies � which is great, and he is positive it increases the quality of their products. What Ole does mean with "testing" is testers who try to break stuff; who do those things with your software that users weren't intended to do; who provoke the hardware hosting your application to behave like it usually doesn't; and who continuously challenge the design and architecture of your products by thinking outside the box and applying this in a methodological and structured way. When it comes to quality, these testers will be your greatest pain and your biggest gain. They take the quality of your products to the next level by doing all that crazy stuff your users do (and don't do), giving your team the opportunity to fix them first. So, back to the question: why is it that these oh-so-crucial testers and the art of testing are so absent from these companies and conferences? Ole Lensmar has three possible explanations in his mind |