As we've seen, estimation of the tasks has always been considered one of the fundamental principles of how the delivery path of a project is scheduled. This is especially valid in agile methodologies, as they use fixed time iterations and compute the amount of features and tasks that can be fitted in the given sprint and adjusted at each iteration using tools such as the burn down chart.

Unfortunately, with all the importance estimation has, it seems like nobody really looked deeper into it: there are plenty of articles that warn how much software development task estimations are always off by a factor of 2 or 3. So, should we just swallow the fact that we won't get better at estimating or is there something more to it?

The "estimations do not work" argument is probably not correct either, and recently the hashtag #NoEstimates has sparked a bit of discussion online, which is probably worth including here.

As a matter of fact, estimations do work. The only detail that is normally overlooked is that the estimation is nearing the actual time spent on it depending on how much knowledge the developer has and how much controllable the environment is.

In fact, the reality is twofold: from one side, we will get better at estimating the greater our experience is, and, on the other side, our estimation will be closer to reality if there are less unknowns in our path.

This is well-known in project management as the Cone of Uncertainty.

What we really need to do is admit and expose all the aspects that would increase the risk and the uncertainty of our estimations, while trying to isolate what we know is going to take a specific amount of time.

As an example, having a fixed time investigation period to create working prototypes of the features we are going to implement sets a precedent for future computations, while human factors will need to be factored in.

While estimations are particularly important from the business perspective of software development and project management, we won't be touching them again in this book. I'd rather focus on more practical aspects of the development work flow.

Extreme Programming tries to stress the investment in defect reduction. In order to do so, it introduces two basic principles: double-checking and Defect Cost Increase (DCI).

Double-checking is software testing. We know how a particular feature should be working, which can be represented through a test. When implementing such a feature, we know in a quasi-deterministic way that what we've done is actually correct.

The other principle of DCI can be used to increase the cost-effectiveness of testing. What DCI states is the following:

To make this even more clearer with an example, if you find a defect after years of development, it could take a lot of time to investigate both what the code was originally meant to be doing and what was the context it was developed in the first place. If, instead, you find the defect the minute it's being implemented, the cost to fix it will be minimal. This, clearly, doesn't even take into consideration all the hidden costs and risks that a severe bug can cause to critical sections of our code base; think about security and privacy for instance.

Not only the longer we wait the more difficult the defects will be to be amended, but also their cost will increase and have the potential to leave many residual defects.

This means that by adhering to DCI, firstly, we need to have shorter feedback cycles so that we can continuously find as many defects as possible, and, secondly, we will have to adopt different practices that can help us keep the cost and the quality untouched as much as we can.

The idea of finding defects rapidly and often has been formalized as Continuous Integration (CI) and requires bringing automated testing into play to avoid the costs spiraling out of control. This practice has gained a lot of momentum outside XP and it's currently used widely in many organizations regardless of the project management methodology adopted. We will see how CI and automation can be introduced in our work flow and development in more detail in Chapter 9, Eliminating Stress with the Help of Automation.

These practices defy entirely the idea of working in a waterfall way, as shown in the following figure:

The delivery path in a waterfall work flow

In waterfall, we have a combination of factors that could impact the quality of the work we're doing: in most of the situations where this was the norm, the specifications are not set at the beginning nor frozen at any time. This means that it's very likely we might not produce what the business is asking.

In other words, you would begin testing only after development, which is way too late, as you can see from the preceding figure: you will be unable to actually catch any of the defects in time for the release date. Unfortunately, as much as waterfall might feel natural, its effectiveness has been disproved multiple times and I won't invest more time on this topic.

Since the advent of agile methodologies, which XP is part of, there has been a great effort to bring testing as early as possible.

Remember that testing is as important as development, so it should be quite clear that we need to treat it as a first-class citizen.

One of the common situations you might find yourself in is that even if you start testing right at the beginning while the code base is being developed, it could potentially raise more issues than those that are needed or can be addressed. The resulting situation will still generate a good amount of problems and technical debt that won't fit within the delivery path, as you can see in the following figure:

The delivery path in an agile environment

The team's goal is to eliminate all post-development testing and shift testing resources to the beginning. If you have forms of testing such as stress or load testing that highlight defects at the end of the development, try to bring them into the development cycle. Try to run these tests continuously and automatically.

Transitioning into a work flow that has testing at the beginning brings to the surface two main problems: the accumulation of technical debt and the inherent problem that developers and testers are considered two separate entities. Don't forget that there will be still some testing that will happen after development and will clearly need to be performed by third parties, but, nonetheless, let's stress the fact that our efforts are to reduce it as much as we can.

As I'll constantly remind you, testing is not someone else's problem. Instead, with this book I'm aiming at giving the developers all the tools that can make him/her a tester first. There are different approaches to this problem, and we'll address them shortly at the end of this chapter, when talking about the testing mentality.

Planning is, hence, critical when stepping into testing from a software development point of view, and in not-so-recent years, there have been several solutions to improve testing from a planning perspective that give a more detailed and compact way to define the so-called test plan.

In a testing-oriented environment, test plans should give you the direction and the indications of what and how much to test at any level. Moreover, the test plan is something that should be exposed to the various stakeholders and its visibility shouldn't live within the walls of development. Due to this, it's our responsibility to maintain and let this document live throughout the life of the project.

In practice, I've seen this rarely happening because test plans are never formalized or, if they are, they are too long and hard to maintain, suffering from a very short lifespan since their initial conception.

As an example, Attributes-Components-Capabilities (ACC) has been created by Google in order to solve some of the main problems that test plans have always suffered, especially their maintainability. You can find more information about ACC and Google Test Analytics software at https://code.google.com/p/test-analytics/.

ACC test plans are short and compact, and the whole project tries to aim to test plans that could be created in minutes and that are self-describing and valuable to anyone close to the project.

For each component, you have a series of capabilities, which can be described with one or more attributes; think, for instance, "secure", "fast", or "user-friendly". On top of this, each capability and component has a relative risk level associated with it. These two things together allow you to understand what is most important to test and how thorough your testing should be.

Clearly, planning tests is just the beginning. Once you get into the implementation side, you can pick up this book, which provides the knowledge of how to use the tools available to create tests.

There isn't much more I can tell you about this aspect. You probably just need to read it all, but it should be stressed that there are some basic principles you must keep in mind when writing tests.

Good tests exhibit the following three important characteristics:

Once you've got a grip of how to approach a project, viewing it from the architectural point of view, and once you've understood how test plans work and what you really need to test, you can start implementing tests, discuss them, and improve the tools and the way you're using them with the help of your colleagues.

In this series of practical examples on how to introduce testing in a team or project, we are going to assume a couple of requirements that are indispensable in getting you somewhere.

In this specific instance, we're going to assume you're working in a team. The ideal situation is to have a team of at least three people.

First of all, you need support from the business and your direct managers; speaking of direct and indirect experience, without that you won't get anywhere. The business side of the company needs to understand what testing is, in the way that is has been described at the beginning of this chapter, the value of testing, and all the good things that this can bring. There is plenty of documentation online for you to build a business case.

Secondly, you need to have some skillsets in testing. This book should cover that part—hopefully quite well—and there are plenty of others that can teach you more theoretical aspects of testing for programmers and engineers, without considering the amount of online resources available on the topic.

Once you've got this, you can start moving into action.

One of the situations most might find themselves in is that there is no testing culture whatsoever. Here you have two choices: either take the bottom-up approach, and get yourself familiar with TDD as a starter, or take the top-down one, where you'll take the higher perspective.

Either way you need to start having a compact test plan to adhere to. Taking as an example the approach of ACC, you start by breaking down the application/project/library into modules (components), each of them will be composed of features (capabilities). Each feature will be denoted with a particular attribute. From there you should have a compact enough representation of what you're trying to achieve. On top of this, you can start assigning a relative risk level, which you will use to give priority for your testing approach defining what and how much to test.

The resulting test plan should be signed off by all the stakeholders and updated as frequently as possible, defining the aim of the project itself. The more this document is official the better it is, as it will be considered the business card of the project.

As highlighted by many, the immediate aim is to start planting the culture of testing in developers. Define the scope of your work, both in terms of testing and development, proceed with caution and evaluate both risks and costs, and leverage on those to take a decision on how to approach tests.

Thankfully, if you're finding yourself working with Yii and Codeception, you should be spared a bit of headaches putting together different frameworks and wasting a bit of time experimenting a working solution.

Team-wise, when the experience in testing is not widespread nor solid, additional practices can be introduced that can help avoid bottlenecks or have all the knowledge trapped in a single person, such as paired programming and code reviews.

Some companies, like Atlassian, introduced test engineers that could help the teams, both from a mentoring perspective and a mere quality assurance side. Their interventions in the development cycle ended up being confined to a more restricted participation, at the very beginning and before completing the task. Their role is, nonetheless, fundamental, as they became the guardians of the testing infrastructure, the tools, and the practices to be adopted, while the developer grew to become a fully fledged tester who can cover almost any aspect of testing without much support.