The role of a tester is – for lack of a term that ties it too closely to engineering parlance – a multifaceted one. Testers from all disciplines, including those who don’t necessarily have the role in their job description, benefit from exposure to multiple areas of software development. It’s a learning role, an adaptation role. A role that requires many fingers in many proverbial pies.

It’s a tough discipline to get to grips with at first and can often feel overwhelming when you’re faced with so many changing targets and moving parts.

During my 4 years in test, all of which have been spent at BookingGo, I have evolved a style of learning that links closely to my personal pursuits in the realm of fitness.

What is periodisation?

Periodisation is an age-old method of physical training, which focuses on prolonged adaptation to new stimuli. Take a look at the theory behind general adaptation syndrome for the human body:

  • Alarm: The initial shock of a stimulus.
  • Resistance: The adaptation to the stimulus; where we begin to get better at handling the workload and go on to progress.
  • Exhaustion: The decrease from overstimulation; an example of this would be overtraining, or overreaching.

Periodisation focuses on prolonging the ‘resistance’ phase, to promote continuous adaptation and prepare for new stimuli.

Linear periodisation is the most popular form of periodisation – and in its simplest form, is designed for incremental progress. Gradually increasing volume and intensity over time, and also modulating to relieve periods of stress.

The linear model is keyed towards gradual increases in strength, at a steady rate. It is also generally about creating a solid foundation. One of my favourite forms of linear periodisation is the pyramid. Testers love pyramids and I am no exception.

Pyramids

Building on that analogy (trust me, I’m going to start talking about testing any minute now), consider a pyramid.

The pyramid is you. It’s divided into several layers, each one representing the structure of your particular set of skills.

The bottom layer is the foundation, made up of a large collection of frequently maintained tools (in this renegade of a metaphor, ‘tool’ can mean anything from an actual tool to a language or a way of working) that the pyramid needs to stay resolutely standing.

The next layer of tools should build upon the support offered by the bottom layer, but its presence further up the pyramid means there is a lower volume of tools to focus on.

The pyramid can have as many layers as you like (it is you, after all), but let’s keep it at three for the purposes of this example.

The top layer of the pyramid is the crowning piece (a.k.a. the ‘pyramidion’, if you like fancy words from the past) and is focused on the fewest tools.

In strength training, the pyramid layers represent different exercise movements, with smaller, supportive movements making up the bottom layer and the top layer comprising large and intense movements, to be performed with less volume.

The tester pyramid

Now, how does any of this relate to testing, or being a tester? That might be pertinent to mention in a post about becoming a stronger tester.

Let’s look at an example:

This is a rough, simplified version of my pyramid. The bottom layer consists of skills that give me a good foundation of knowledge to bolster my role. Knowing things like Java and Android development isn’t essential for a software tester, but your ‘base’ becomes stronger when it consists of a solid collection of tools to support you in your day-to-day role. They can also help you weather changes and shifts in priority.

The middle layer is predominantly ways of working, ideologies that build upon the base layer of skills, creating a sturdy middle that marries your toolset with your peak.

This peak is testing. Just testing. I personally endeavour to focus most of my intensity on the crucial elements of my role. Exploring software, communicating with my team and others, identifying risk, finding new ways to use things.

Bringing it all together (Building the pyramid)

Once the pyramid is created, we can employ the periodisation techniques I mentioned at the start of this post. Iterate your learning path, using the structure of the pyramid as your guide. If you have chosen to learn Javascript as a supportive skill in the foundation layer, moderate the intensity of this learning so that it doesn’t become overwhelming, but keep the volume to a level that allows you to retain knowledge.

The tools in the bottom layer should never be overemphasised because then the middle and top layers falter. Conversely, if you constantly focus on your general day-to-day activities, ignoring personal skill growth outside of that, you've become less of a majestic pyramid and more of a little triangular brick. Sat at your keyboard; how funny is that?

To use an exaggerated example, what if you spent all your free time learning Python, causing the knowledge of your team’s project work to fade into obscurity. Or you only ever just tested stuff and never tried to learn from it, thereby reducing your ability to communicate with your team. These are drastic examples, but the main point is to always moderate and iterate.

Like most learning practices, repetition is key – and this model is a structured form of repetition that is designed to encompass many different subjects. As I mentioned, the role of a tester is multifaceted and often demands impromptu exposure to new subjects and ideas.

In closing, it’s important to note that this particular analogy is completely flexible. In fact, a pyramid suggests that by the very nature of the shape, some tools should be de-emphasised in favour of others. How about an apartment block? A nice, uniform shape that allows you to even out your learning, while still structuring it into segments of priority.

How you structure your progression as a tester is entirely up to you – this model is something I accidentally started to adhere to and it allowed me to get a grip on my development. Slowly but surely making me a stronger tester.