Rick Martin of Bearblu told me the other day that he had wrapped up a testing gig for one of top 3 Indian tech companies. Actually, his client was a U.S. Fortune 500 company that used the offshoring for development and testing. Rick is a highly skilled senior manager for QA, so he was providing the leadership for software testing on the project.
The interesting part of his story had to do with the lack of support for load testing. This was a very large, complex project. The impact of the web application is enormous. Yet, the powers that be were not excited about allocating resources to load testing. The tools were available, but the environment was “shared”.
The issue was that there was only a single “QA” environment that was being shared by Performance, System and UAT testing. Time for the QA team to build the test plans was not sufficient. Any type of web performance testing was just not a commitment from the overall project leadership.
That lack of commitment obviously rolled downhill and impacted Rick’s efforts. I empathize. This scenario is common, and I’ve been stuck holding the accountability without the authority to fix it. My pointy hair managers have thrown me under the bus when the app crashed under volume a few weeks after going live. And of course, they didn’t want to hear any excuses from me. Especially excuses that pointed the finger back at them.
Sometimes project teams get caught up in the frenzy of producing code, hitting deadlines, and euphoria of having the puzzle complete that they overlook the load testing. However, I submit that most times the snub to performance validation is a conscious decision.
Software engineers, product managers, CIOs, VPs of development, and even some QA leaders put load testing at the bottom of the priority list. I’ve heard several similar comments in meetings to the effect, “We just need the system working and available to the customer. We’ll worry about volume testing when we get complaints.”
Bad strategy. In the world of web applications, load testing is more important than ever. The reality of today’s users is that if one site is slow or showing errors, then they won’t come back. Tolerance with performance issues was expected in the captive internal audience of a company running client/server apps. Not so with web apps.
Keep fighting the good fight Rick. Better luck on your next consulting gig.