Datasheet
10
Chapter 1: Preliminary Concerns
A developer who is experienced in writing tests will find that they are more productive actually writ-
ing 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 .
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 man-
agers 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.
96640c01.indd 10 9/25/09 7:18:28 AM