Think you'd make a good Performance Tester?

“Some men aren't looking for anything logical, like money. They can't be bought, bullied, reasoned, or negotiated with. Some men just want to watch the world burn.” Alfred – The Dark Knight

Welcome to performance testing where we like to watch things burn.

Life generally requires two types of people. Those who create, and those who consume; the makers and the buyers; the writers and readers; the retailers and shoppers. You can't have one without the other. Ying and Yang; complementary and equal.

In IT, we make the systems, apps, websites and functions for people - our customers - to use. IT people make stuff for people to do things with. Without people to do things, use and consume what we've created IT systems have no reason to be.

This symbiotic relationship between IT creators and IT consumers isn’t purely black and white. There's more to it than just creation and consumption. Sometimes there are other, grey, non-standard, outlier roles. Performance testing is one of these outlier roles.

Performance testing is not about creating, nor is it about consuming. It takes what’s already been created and pushes it, pulls it, prods it, investigates and often breaks it.

Performance Testers test things, not just to verify they work or meet requirements, but intentionally do the opposite. We test things specifically with a view to breaking them. It is through this inherently destructive act, creators are able to create better, more robust, more reliable things for consumers to use. If we only test things to see if they work as expected then we learn little of value. It is when we test things to their point of failure (and beyond) and we examine how and why they fail, we can learn and improve.

Performance Testers are therefore, neither creator nor consumer, but a niche, specialist role that benefits both the primary roles.

I’m often asked what traits a good Performance Tester must have, and to me, they're different traits to the kind you'd look for in primary "creator" IT staff. So, following is my pick list of traits I'd look for in someone who expressed an interest in becoming a Performance Tester. Obviously this is my preferential list which won't be definitive and is completely subjective, but I believe their core traits must;

• Always look for boundaries. Do they always ask, what if? Have you tried..? Often Performance Testers actively seek out and play Devil’s Advocate when no one else does. They specifically look for ways to break things and think creatively as they do so to cause issues that are far from normal, expected behavior.
• Be “technical,” and a coder at heart. Regardless of their background, they must question things at a technical level. They may not necessarily be from a development background, but they'll often find themselves “coding” solutions to technical problems or finding better, automated, easier solutions. This might be using macros, scripts, spreadsheet formulae or other bits and pieces of technical wizardry they've picked up. They love to tinker and aren't afraid to try things out.
• Have a broad understanding and knowledge of IT. They might be from a particular background or specialisation area, but they need a good understanding of how things work and fit together. Even if this only schematic, but they can work most things out from what they do know. They might be a programmer, but have an understanding of networks, security, architecture, etc. Or maybe a functional automation tester with knowledge of system architectures and an interest in security. The key here is broad knowledge – deep in some specific areas – and enough to know how, why and when things interact as they do.
• Have a deep understanding in their area of specialty. Having said they need a broad understanding of most aspects of IT, a good Performance Tester must have deep understating in their area of speciality. In the OSI model, I’d expect specialisation in (at least one of) the physical, data, network, transport, session, presentation or application layers. If they're not specifically from a technical IT discipline, they might have a deep understanding of specific testing processes, automation, monitoring or programming.
• They aren’t afraid to look deeper. Even though they may not have complete information for a full solution, they know where and how to go about finding it. There may be gaps in their knowledge in places, but they’re not afraid to investigate and correct that. They recognise and acknowledge where these gaps are. They are able to quickly find out how things hang together, how they work and sometimes do so just out of curiosity. They’re not afraid to ask questions - not only why, but how.
• They are smart/ sharp/ quick. Often they see what the problem or solution may be very quickly. Often they will be able to quickly sort through a lot of noise and spot patterns. They find themselves picking up high-level concepts and broad-brush techniques quickly but they are are very much realists not theorists. Think street-smart, not necessarily book-smart. They are able to see the bigger picture without getting stuck in the detail.
• They are methodical. There’s little point in doing things haphazardly. If results can’t be recreated or documented systematically, then they are often worthless. Good Performance Testers work methodically towards a goal to prove something, never randomly. One thing builds on and leads to another, predictably.
• They think differently. When people think the same, results often match. To break things, Performance Testers often have to think creatively, negatively and destructively. They think not in terms of business users, customers, technical programming or technical infrastructure, but often they will think across or outside all of these. Performance Testers often are happy to be thought of as odd, unconventional trouble makers and breakers.
• They take ownership. Often Performance Testers work alone, using tools, skills and knowledge that cross technical boundaries within tight deadlines and at odd hours. Often this requires they “step up” and take accountability and ownership to get things completed. Being accountable for results, and taking ownership on behalf of the customer is key. Performance Testers often have to deliver bad news to clients that they don’t want to hear.
• They are clear and logical communicators. As Performance Testing crosses many architectural, business and technical boundaries, Performance Testers need skills to communicate extremely well verbally, in written form, and graphically/visually with stats/graphs/infographics. They need to be comfortable with and have the ability to present their results to technical, non-technical and management audiences. If no-one understands what the findings mean, the results and their findings and recommendations are worthless.
• They like it when they break things. Lastly in my list, which kind of brings things back full circle, as a Performance Tester ultimately they must enjoy doing what they do. And that means breaking things. Breaking them with ingenuity, with intent and sometimes, just because they can.

There are a lot of other skills and specific knowledge that would make good Performance Testers, lots are learnt and others are innate traits or behaviours. I’m sure there are loads I’ve missed, but I believe the ones I've listed are key traits regardless of seniority, experience, background or training.

Some come to Performance Testing from a Systems Administration background, some have been frustrated programmers, and some were functional testers that didn’t quite fit the normal mould. But all Performance Testers are to an extent, outliers, who are different to “normal” IT people. Some though, they just want to watch the world burn.

If you're not a Performance Tester, but a lot of those key traits sound like you, then maybe we should talk. I have a box of matches here you might like.

#performance #performancetest #performancetester #performancetesting #loadtest #stresstest #tester #testing #AccessHQ #HumanQuality #Quality #burn #load #loadrunner #neoload #stress #test #outlier