I’ve only had to quit two jobs to finally find the time to finish this blog series. Winning at life. If you need reminders (like I did) check out Part 1 and Part 2 before reading on…
After the first two blogs regarding the Wheel of Testing, I was delighted to receive a few requests for the wheel itself, which got me thinking about applications of it, beyond what its original intent was, which I’ve explored in detail in part 1 of this series of intermittent blogs. Most models need a little air time to show their value, in software development we crank out models all the time, but I’m not sure how many get used. I am inspired by models such as the “Heuristic Test Strategy Model” by James Marcus Bach, as I have used it and seen the benefits it has brought for my clients, particularly the ability to ask questions. So, I wanted to create a model which has a number of use cases, both real and imagined:
Helping to unlocking a career in testing which may be stuck
It is not uncommon to reach a point in a career where a tester (or anyone), may feel stuck in their role, or believe that testing has little to offer them. Using the Wheel of Testing in one to one meetings as a discussion point has proved effective for this purpose, triggering questions about previously unknown paths in testing. Tool assisted testing is one, triggered an interesting debate with a builder of automated tests. Might there be other ways to assist testing than scripted automation? This surfaced perceptions of what other testers in the organisation did and inspired the person to find out what repitition in system setup and state testers did, plus opened the door to mentoring those same testers. The wheel opened out that career in various directions.
Contributing to setting the direction for new starters in testing
Testers get into testing from all sorts of directions. From support roles, former developers, recruitment, many different ways to enter the craft. This makes testing kinda cool in my eyes, despite the bemoaning of the lack of professional testers. However, when one comes into testing you need a way in to developing yourself. The Wheel can work as an outside in type of tool in these contexts. Come from an operational role and you might decide that your way in is via your domain and advocacy skills, then fan out to the other areas. As a former developer, your route to the core skills might be through automation or performance testing. I think we would enhance the craft if we helped that journey from the outside in be a little more deliberate.
Building a training programme for testing
I see a lot of training programmes for testers (and developers) popping up. Some organisations are realising that having a multi faceted approach to hiring testers has potential. Also, I see a lot of academy programmes creating more of what organisations already have, as the expectations of what testing is and what a tester does are rarely balanced. I used the wheel to consider what such a programme might cover, given the amount of time you have to provide a grounding in certain skills. The benefit of the wheel here is that the skills radiate out from a set of core tenets. Choosing a balance from each of the 5 areas helps your training stay focused and what makes good testers. According to me at least.
Determining what skills you have (and don’t have) in your testing function
In my world, testers can tend to be alone on teams, or at most in pairs. Rarely working together in a silo, where many testers co-locate and perhaps an appreciation of the skills (and skills gaps) of many testers might be more prescient. The Wheel can be used as a living record of the skills within your team. In my former life the Wheel assisted us in recognising deficiencies in the performance and security areas, albeit a little too late as a result of a voluminous security bug bounty. Ouch. Keeping an eye on the balance of your approach and skill availability is one of the primary functions of test leadership in my eyes. Otherwise you are viewing your product through too few lenses, eventually you will feel the pain. Security and performance will likely become key product differentiators too, so lets keep our approach balanced.
Talking about how testers can be a valued in development teams
I really like this one. What are testers terrible at? Talking about testing, especially as an exciting, skilful and varied craft. The Wheel can be used as a guide to these conversations. The number of development teams I have walked into where testing is met with rolled eyes, described as “the bottleneck” and other thinly veiled ways of challenging the value of testing. For example, using the strategy part of the wheel to help the team think critically about what they are about to build, surface assumptions and reason around how observable a product is. That sounds much cooler than ‘poking around in the user interface’ or ‘doing endless browser testing’ to me, but its rarely phrased like that by testers.
Consultants crib sheet for new clients
From experience, many reviews of testing capability are context free, unbalanced recommendations to implement tools and techniques in organisations who don’t even have the questions to begin to talk about testing and quality. The bonus of the Wheel that it has layers and sections. It is perfectly possible that an organisation can be technically advanced but lack critical thinking and advocacy skills around testing. I also believe it to be true that an organisation needs to improve in a step by step manner, rather than zero to continuous deployment in one leap. Using the Wheel in this manner helps to traverse that leap. I was recently asked to create a load testing framework for a client. There had been no previous thought about testing and testability on the product, I used the wheel to build an approach to create a path from no previous thought, to meaningful load testing.
Guide for evaluating a product, especially when first getting started
There are loads of ways to evaluate a product for testers getting started on a new system or product. However I still observe a reasonable degree of freezing in the headlights of complexity when faced with the new. I think the Wheel could be used in two contexts here. Firstly, the system has so much information to expose to a tester its often hard to parse. The Wheel acknowledges this openly, it is about the breadth of scope that testing enjoys, so don’t be afraid. Secondly, it offers a number of places to get started. If its a mobile application, usuability might be a good place to get started, if its a high volume payment gateway application programming interface, perhaps start with the available application monitoring or analytics to gather insights.
A heuristic for giving feedback on a test strategy
Recently I had occasion to give feedback on a test strategy for a new product, which was being built on information gleaned from prototyping around a particular business problem. The system would use an ancient internal web service too, which stakeholders were nervous about. For me in a new product context, testers should be exploring with various lenses using a breadth of techniques to really enhance information flow to the team, providing light touch test automation while the architecture remains in flux, with adequate resilience testing around integrating with the service causing nervousness. I used the Wheel to assess the breadth of the strategy, plus how it gathered information about the key risk and provided feedback.
Like all models, it is useful in some circumstances, but less so in others. Its certainly not complete, everytime I look at it, there could be more. Also, its more about the testing that testers do, doesn’t really address in depth testing that other stakeholders might do, such as unit testing for example. However, I am a tester, so its got lots of me in there.
Really, its a whatever you want to use it for type of wheel. A few people have used and referenced it, so I hope its being used somewhere for weird and wonderful things that I never thought of. That would make me happy.