Chapter 91. Why Test?
Once, I visited a US government official who had just experienced a big project failure. He had just tried to roll out a new application that had been in development for five years. The rollout would begin in a classroom, where he had invited about twenty senior application users to see and use the new software for the first time ever. After the course, these advanced users would be responsible for disseminating what they had learned to the remainder of his department’s roughly one thousand total application users.
But just a few minutes after the big unveiling, the sickening truth became clear: this system was so slow that it was unusable. It was supposed to serve a thousand users, but it couldn’t even handle its first twenty.
How can an application miss that badly? Inadequate testing. It’s two problems: one political and one technical.
The technical problem is that performance testing skills are rare. Certainly, if a feature’s performance is bad enough, a developer might be able to see the problem in that feature’s unit tests. For example, if a developer’s new feature takes ten minutes to execute, even on a system with miniature test data and no load, then there’s obviously a problem. But there are lots of performance problems you can’t detect without both (1) realistic data volumes and (2) realistic traffic intensities. Knowing how to simulate a production environment requires skills that many application developers don’t have.
The political problem is ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access