1.5. Why Should I Learn about Testing?

You're reading a book about testing for the web, so you're heading in the correct direction.

1.5.1. For Developers

Developers tend to be busy people, what with new technology trends emerging and customers constantly demanding new features. At times, developing software is a very stressful profession. Worrying if the new feature you added this morning is going to break existing functionality should not be something developers are spending time thinking about. Having a test suite that spans from unit tests to customer acceptance tests will help a developer sleep better at night, at peace in the knowledge that the software is functioning as designed.

A well-written test suite will provide the proverbial safety net. With this safety net in place developers are more willing to refactor (changing the internal structure of how code works without modifying its external behavior or functionality) sections of code, experiment more often when getting ready to add more functionality into a system, and be more Agile. The end result is an improved code base and fewer areas within your code base that you are scared to make changes to.

One aspect of unit testing that new developers to automated testing often overlook is the fact that testable code in most circumstances is also well-designed code. Design patterns such as Inversion of Control (IoC), and simple development concepts such as Don't Repeat Yourself (DRY), together with a strict separation of concerns are needed to create testable code (concepts that will be discussed thoroughly in Chapter 2).

A developer who is experienced in writing tests will find that they are more productive actually writing a test as opposed to using the debugger to nail down an issue. Let's take a step back for a moment and think about this. How much time is wasted each day waiting for the browser to load a page just to test a simple change?

An informal study conducted by Web Ascender (http://www.webascender.com) found that web developers spend 15 minutes per day on average just waiting for web pages to load.

By investing time in load tests, it will enable developers to choose the correct server infrastructure such as web farms and caching services earlier in the lifecycle. This information is also useful to plan for fiscal year budgeting. Loading tests that are run frequently and appropriately defined will help identify bottlenecks and negate negative customer feedback of a poorly performing website.

The concept of acceptance testing reinforces the importance of communication between developers and customers. The end result of acceptance testing ensures that the customer was delivered what they expected for the system being developed. In most cases, many customers are just happy that a developer cares that they are delivering quality software that is on par with what the customer wanted.

Many web developers are unaware of the accessibility laws that their site must conform to. Countries such as the United States have laws that forbid discrimination against people with disabilities. Accessibility is not just for government websites and in many cases simple accessibility testing could have avoided lawsuits.

1.5.2. For Managers

Different projects and different managers will have different criteria for what they feel makes a project successful. Good managers will see the necessity for each discipline of testing discussed in this book.

• A project should be delivered on time. Many projects wait until the last possible minute to test an application to ensure it is working properly. One of us has been in a situation where waiting to the last minute to test has caused a project to be delayed because of performance, accessibility, and acceptance issues, all of which could have been avoided if testing was completed through the development process.

  This may make sense to many managers; surely you can't test until the system is completed? Plenty of projects have been delivered to customers with very little customer interaction.

• A project should be of high quality. Managers should put a great deal of time into defining metrics to measure if a project is of high quality. Having a suite of tests is a very strong metric to measure the quality of software. Having a full range of tests means that code is "exercised" often and has a far less chance of breaking because of neglect. How are you currently measuring the quality of the software being delivered? Many managers take the approach, "If it ain't broke, don't fix it," but in reality how do they know it's not broken?

• A project should have low risks. Managers often speak about the risks of projects. Great managers will manage risks to rewards and only take on projects that they know their team will have success with. In the real world, there is money to be made on projects that are higher risk and many times the highest risk is the delivery date.

  Having a range of testing will help lower project risk by ensuring software works correctly conforms to specifications; and in many cases, testing helps keep the customer in the loop of what is going on with a project.

• Have a happy client. A common measure of success is a happy client. Most clients are very happy when you spend the time with them to make sure you are developing the system they want, not the system you or a manager/developer want. Getting the customer involved early on in the testing is key. Customers should be involved in acceptance testing and can also be leveraged in running manual test plans.