In the Wild West movies, the cowboys do not typically have a lot of friends; they follow no rules but their own, and their way of settling an issue is by shooting each other. In the wild world of software performance testing, without the support from people around and above you, it will be impossible to get anything done. You don’t have to be a lonely cowboy.
In a previous StickyMinds article, Getting Better at Performance Testing: Beyond Tools, I talked about how to approach a performance testing project: Always start from the simple, be a meticulous and active observer, and be diligent and prepared.
Software performance testing is not just about testing and how well an engineer knows about a specific tool; there is much more involved, including how the people you need to work with are engaged in the process. In this article, I’m going to cover more aspects of performance testing: getting involved and making friends with people around you, promoting awareness of performance testing, and being disciplined.
Get Involved and Make Friends
If you are not already doing so, consider presenting your test design to developers and asking for their input, keeping them updated with your progress on tests they are interested in, and going through test results with them face to face. After all, they are the ones who know the application the best and who are ultimately accountable for the performance of the code they wrote. Most of the time they are willing to offer their opinions, which will help us design more effective tests. The last thing you want to hear from them, after spending hours and hours running tests, is, “I don’t think your test is relevant!”
You will be amazed at how much information you can gather if you regularly take part in requirements analysis, software design, and Scrum teams’ daily standups. The information gained from these sessions can give you a better idea of the scope of testing, help you plan your tests earlier, and, above all, let you avoid surprises.
For planning purposes, the earlier you get involved in the software development lifecycle (SDLC), the better. Long before the testing is scheduled to start, you definitely should answer questions such as the following:
- Can my testing tool handle a new protocol?
- Can I generate the expected load?
- Do I have the infrastructure for the tests I am going to run?
- Do I have enough time for the work I am planning to do?
Of course, these are only examples. But it is important to understand that getting involved means not only that we performance testers should participate in other groups’ activities (e.g., software design), but also that other groups should be invited to participate in our activities (e.g., test design).
There is so much involved in performance testing; no one can possibly know everything. We have to rely on other people for domain knowledge, networking, setting up a testing system, and even things as simple as getting permission to access a file on a server.
Everyone has their own work to do, and everyone’s priorities are different. Having a good working relationship with people from other teams could mean our requests are given higher priority, so we don’t have to wait for hours—or even days—to carry out a test. We all know the costs for finding and fixing defects late in the software development lifecycle are much higher, but I daresay that not all the delayed discoveries are due to technical reasons—some could be the result of bad planning.
Promote Awareness of Performance Testing
It’s a common misconception that the performance testing team is responsible for an application’s performance. Wrong! Our responsibility is to find performance issues before they slip into production; the whole company is responsible for the performance of its software.
By the whole company I mean everyone involved in the SDLC. For example, business analysts must always keep nonfunctional requirements in mind during requirements gathering, developers must do their best to write the most efficient and secure code and perform unit testing before delivering the code to QA, and the production team should implement necessary monitoring and feed the information back to other teams.
The performance testing team should design pertinent tests, based on production usage data or projection, and execute them to validate nonfunctional requirements. And, if necessary, they should recommend changes to the design of the software or system.
The following diagram shows how different groups can contribute to an application’s performance.
As you can see, performance testing is about much more than finding issues. Sometimes we have to educate people around us, and sometimes it might even require a companywide culture change. Without the support and cooperation from other teams, it’s going to be very difficult for us to do the work.
During one release, we opened a performance defect for an area our customers use heavily, but no one from development was engaged to investigate it for three weeks.Even worse, someone decided to defer it without consulting the performance testing team. Once the QA director was made aware of the situation, he was quite upset that we did not follow up on the defect. This incident also revealed a common problem: Application performance is not given the attention it deserves.
Be Disciplined
All the testing tools I know of require some form of scripting or coding, which should be treated as software development. Therefore, test development should follow software development best practices. At the very minimum, you should consider code reuse, a naming convention, comments, and avoiding hard-coding test data.
These practices are regarded as common sense in IT, but as basic as they are, to what extent they are followed really depends on each individual’s training and whether they are enforced at work. I have seen many test scripts whose purpose could be understood only by their original creators due to inadequate comments.
At my last company we created scripting standards and implemented periodical code review as a means of assessing the quality of our scripts and to identify areas for improvement. The first few code reviews revealed many problems. After a few rounds, the quality of our scripts improved significantly.
In the Wild West movies, the cowboys do not typically have a lot of friends; they follow no rules but their own, and their way of settling an issue is by shooting each other. In the wild world of software performance testing, without the support from people around and above you, it will be impossible to get anything done. Do not become a lonely cowboy. Reach out to your team, make others aware of what your job means, and follow disciplined practices, and you can improve and secure the whole business of performance testing.
