Since I started getting into quality assurance and testing in a professional way, I've never faced myself with the question of "what is testing?"
I have to be honest, but during my time at university, testing wasn't part of any course. I don't really know if this has changed recently, nor if what's being taught is of any importance or relevance to the business world.
In this book, I've tried to combine the practicality of development and testing using a great PHP framework, Yii at its version 2, and the testing suite of Codeception. I will present each topic with a keen eye on the actual benefit for the team, while showing from a higher perspective the planning and the organization of the work. Throughout the chapters in this book, I'll shift back and forth, trying to give a clear understanding of the details you will be working on and the scope of the work, the overall aim from a testing perspective.
But, before we venture into this journey, what effectively is testing? Google engineering director James Whittaker's words make a very good answer to that:
"Although it is true that quality cannot be tested in, it is equally evident that without testing, it is impossible to develop anything of quality."
There are aspects of testing that are so completely fused with development that the two end up being practically indistinguishable from each other, and at other times it is so independent that developers are not even aware that this is happening.
In the whole project lifespan, you start with ideas and transform them into features or stories, breaking them down into tasks. From there you move into the execution of each of these tasks that will hopefully grant you, at the end of them all, a finished product.
At any point in our development process, we have tried to put some level of quality in it, either by "checking" the page loaded or by doing some more smart and deep, if not automated, testing.
Atlassian's QA team lead Penny Wyatt points out that teams where quality assurance was not performed or left alone to perform small automation tasks, with unit tests for instance, had the highest story rejection rate, which is when a story will have to be re-opened after being completed because of wrong or missing functionality. We are talking about a 100 percent of rejection rate.
When such a situation occurs, we are left in a state where we have to go back into development and fix what we've done. This is not the only case: together with it, late discovered bugs and defects, and fixing them, are possibly some of the most expensive tasks in software development. In most cases, it has been shown that their cost is also way higher than it would have been to prevent them in the first place. Unfortunately, software development is rarely devoid of defects, and this should always be kept in mind.
As developers and managers, one of the goals we should have is to reduce the occurrence of defects to an economically acceptable level, and doing this also reduces the resulting risk associated with it.
As a practical example, a large website might have thousands of software errors but still be economically viable due to the fact that 99 percent of the website is displayed correctly. For a Falcon rocket or a Formula 1 car, a defect rate that high is not acceptable: the risk of having a single one in the wrong place might also cost the lives of people.
The other implicit aim for defect reduction is an investment in teamwork. An error introduced by one developer can have a ripple effect on the work of other team members and, overall, trust in the code base and other colleagues' work. In this chapter, and the later chapters, we are going to discuss this aspect in more detail by introducing some concepts of project management and how it can cooperate in ensuring that quality is ensured on many levels.
The last and possibly an equally important aspect is how testing can be used to document the code by example. This is rarely discussed or brought to the attention of developers, but we will see how tests can describe the functionality of our implementations in a way more precise manner than what PHP documentation comments can provide. I'm not saying documentation comments are useless, quite the contrary: in modern integrated development environments (IDE) such as NetBeans or PHPStorm, auto-completion and code hinting are a great way to improve the time to discover the underlying framework without having the need to search through a reference manual. Tests can and should in fact provide the much needed help a developer might need when trying to combine and use yet unknown interfaces.
When working with open source software that is a result of the work of a small self-organized team, having the ability to provide documentation without an extensive effort might be the key to rapid and continuous delivery.
But how do we ensure a delivery can be met within constraints that are imposed on the team? In order to explain this, we will have to take a quick detour into project management, from where some of the practices that are discussed and used in this book have been originating.