Performance testing sounds like a good idea to management and users alike — but where to begin? A QA engineer rarely walks into a project in the very beginning with a fresh start to not only the technological approach but also the business and product plans… so how does a QA performance effort in the midst of the madness?
The first step is not to throw tools and best practices at the project, but rather to understand the technology stack. What web layer is used, what application layer is in place, what database system? The caching system is important: how does the HTTP layer cache, the database cache, the application server cache? And don’t forget about the crontab — what jobs are running in the background on your system to administer and update the data feeds? And oh by the way — what about the other projects running on your systems that your team doesn’t know about? See a system suck between midnight-thirty and 1am that you can’t explain? Check with other projects — someone else may be bogarting your resources. You’d be shocked at the resource sharing that infrastructure decides to try out without telling you.
Where do you sit as the QA organization? You sit in the middle of it all. Your fingers have to be in everybody’s pies. Make it your business to poke a curious nose into people’s business — not in an invasive way, but in a curious way. People are usually willing to talk about what they do if you simply ask them for help. “Georgie, I’m dying over here, can you help me understand the HTTP proxy?” Georgie will reply back probably asking you what exactly you need to understand. Ask him what you should be asking. More often than not, people will respond when you approach them with humility and a genuine desire to do your job better. This is the key to crafting a quality performance approach. Tools and infrastructure come later.