This is a cross post from the uTest blog. Â The original, with read comments, is available here.
One thing I’ve learned in life is that it’s important to test everything to prepare for worst-case scenarios — whether it’s software, emergency response, or simply your new snow tires in a desolate parking lot.
My in-laws are recent transplants to the New England area. I don’t think they were prepared for snowfall depths measured in Boston Celtics players, but they certainly got it. My father-in-law was reluctant to buy snow tires for his four-wheel-drive SUV, but after several convincing articles, he quickly purchased and installed them.
The next time I saw him I asked him if he had “tested†them yet. He gave me a quizzical look, and I knew I’d have to take him to an empty parking lot and pretend we were teenagers doing doughnuts all over again. My point was that he’d never know the capabilities and limitations unless he tested them in a (relatively) controlled environment.
The same goes for load testing.
Yesterday, we were hit with an unusually messy, two-part storm that involved precipitation in every liquid state. Morning commuters knew this would impact Boston’s public transportation system’s (the MBTA) train schedule. In an effort to avoid standing outside in rain/snow/sleet, everyone logged onto the MBTA’s website, which inconveniently wasn’t able to handle the demand and the site was brought to its knees.
In a most critical time when people needed updates the most, the site was unable to help. This is a prime example of why it’s important in the software testing world to test in controlled environments. Had the MBTA done more, they could have flushed out potential errors in advance and served their customers better.
(It’s worth noting that the Mass DOT & MBTA are far from strangers to technology and do a wonderful job utilizing Twitter. You can follow them @MassDOT & @mbtaGM.)
