SFIA and the Test Academy

How do you improve testing excellence in a large technical business unit where there are only 27 test professionals amongst 300 developers? That was the challenge for the Test Service Manager at a large government department I’ve been working with over the last few months. The organisation has adopted a (more-or-less) Scrum approach to development over the last five years and that has proved relatively successful, but one result of this has been a shift to promoting the idea of  the generalist ‘developer’, the jack-of-all-trades Agile developer who can turn their hand to whatever task is needed, including testing tasks. Without going in to the rights of wrongs of this view (which is perhaps one for another blog), the specific result for this organisation has been a reluctance for employees to pursue testing as a career and the existing testers feeling demoralized about the value they have to add.

Our initial focus was on helping the test professionals improve their testing skills. A number of the testers will be taking the Certified Agile Tester training course with us next month, which should help them start to understand the value they can bring, as an Agile software engineer with a testing specialism. However, a 5-day training course can only go so far and so I’ve been working with the Test Manager to create an in-house learning programme based on agile testing skills, something he termed a ‘Test Academy’.

One of the key aspects of the Test Academy was that it needed to be tied into the Skills Framework for the Information Age (SFIA5. http://www.sfia-online.org/). This framework is widely used and provided a tool for communicating the benefits of the Test Academy to the business unit, i.e. once someone is assessed for a certain testing skill it can easily be traced to a SFIA skill level associated with specific roles in the organisation.

I was a little concerned about the value of assigning test skills to different levels. Testing as an activity can be a very creative and individualistic ‘art’ and I can (still) see a danger in categorising someone as a ‘Level 2 tester’, for example. However, when I grappled with the SFIA levels further, I felt that there could be a lot of value in assigning test skills to the lower levels (1 – 4). I believe generic testing skills can be taught at this level. Level 5 upwards, I see as being very much up to the individual to develop their own domain specific skills, which would be far harder to compare from one tester to another.

By using the SFIA levels, we were able to move testing skills from being associated with the role of ‘tester’ and instead put them on a same platform as other development skills. The organisation already accepted this idea in theory, but in practice the focus had been on testers needing to develop technical skills to be more generalist developers. The SFIA levels highlighted that there were a lot of basic development (test) skills that all generalist developers should be expected to possess (up to level 3) and that those who wanted to pursue testing as a specialism, should be at least at level 4. This clarification not only makes it easier to assess where people are and what they need to do to take on new skills, but also created an urgent business case to ensure all developers were developing the basic testing skills.

It is early days for the Test Academy idea and it remains to be seen how effective it will be in helping developers (including testers) take on new skills, but the use of the SFIA Levels has already created an impetus which bodes well for the future.