In my previous post on building an internal performance testing team we talked about how to find the right people to build a great performance testing capability. In this second instalment we cover some of the ways you can get the best out of that team.
The value of knowledge
Every time we work on an engagement we pick up invaluable knowledge about business domains, processes, technologies, and tools. Two things often happen to this information:
- It stays in one person’s head and is lost when that person moves on
- It gets forgotten and has to be re-learned in the future (even by the same person)
To avoid this situation we need to get this information out of our heads and recorded somewhere. Perhaps the biggest challenge is to build a culture where taking the time to write this knowledge down is valued.
How you go about implementing this depends on your organisation. The important thing is that the information is easy to store and easy to access.
On the job we often write our own scripts or tools to do simple jobs. This could be anything from parsing a particular kind of log file, to monitoring a particular kind of resource.
It may not seem like it at the time but these spur of the moment tools can add huge value to your organisation. If one person finds a particular need to write a script, the chances are someone else will have that same need in the future. The secret is to aim to build these tools as generically as possible so they can be applied in many situations.
As you build up this collection of internally developed tools you end up improving the efficiency and effectiveness of your team.
Performance testing is a specialist field which takes many years to build self sufficiency and confidence. It’s not the kind of thing you can pick up on your own just by Googling around. Most of the content out there focuses on tools which is only a tiny slice of the bigger picture.
The simplest option is to build your team around one or more senior performance specialists, and to give them the time and resources to up-skill the team sufficiently. Again, it’s about building a culture that values investing in people so that they can become self-sufficient (to provide maximum value to the business).
Keep them specialised
It makes sense in an organisation implementing a flavour of agile to have smaller teams of multi-disciplinary people. For performance testing, this is counter-productive. Someone who dabbles in performance testing on the side of their other work (maybe other kinds of testing or development) is unlikely to have the depth to really understand the performance of your systems or be able to diagnose issues.
I’m seeing performance test teams who operate across multiple sprint/scrum teams but only part time – and I think that’s a good way to go about it. It means you get that specialist knowledge and skill when you need it and the performance testing team themselves get to establish the depth of skill and experience they need to thrive.
Software performance is more important than ever, but it is also more challenging than ever. As we develop software faster our performance testing capability has to work smarter to keep up. Taking the the time to invest in a smart and adaptable team will pay dividends in the long run.