I’m a big fan of Dungeons and Dragons, having blogged and spoken about it and how it’s affected my testing. I thought it’d be fun to share what types of tester each Dungeons and Dragons class might be. Your Dungeons and Dragons class is the role that you fit within an adventuring party and impacts what skills and spells you might have or gain access to.
The Artificer
Artificers are builders and tinkerers, creating and maintaining testing frameworks and working with the most modern tech stacks. They have the right tool for any testing job and are always happy to run a proof of concept for something new the team might want to try.
Whilst the Artificer is highly technical and can solve your pipeline testing needs, they need to be cognisant that automation might not work for 100% of all testing.
The Barbarian
Barbarians are intuitive, using their instincts and trusting their gut which means they get the “feel” for where bugs are. They like to get stuck into the fight and would rather do something than talk about it, making them excellent at ad hoc activities.
Whilst the barbarian can use their primal instincts to get started on testing quickly, they need to not be blinded to the project’s overall plan.
The Bard
Bards are charismatic people people, they use their influence to inspire others and share information about testing. They like to command an audience and perform, whether that’s running a demo, workshops or even talking to someone about the details of a bug that’s been found.
Whilst the bard makes for a great leader and can take people on a journey, they need to remember to put others in the limelight and not hog all the glory too.
The Blood Hunter
The Blood Hunter tracks down the monsters that other testers can’t find, the complicated issues that only show up when the system is running. They follow the trail through logs and traces, marking faults with monitoring and alerting so they can’t hide again. They can even turn the code against itself using mutation testing (yes, I’ve mentioned mutation testing!) to find the gaps where bugs slip through.
Whilst the Blood Hunter can help the team with debugging and thrives in production, they need to be careful to also look to shift testing left and prevent bugs… not just find them late.
The Cleric
Clerics are wise, bringing in a lot of experience that gives them the ability to be pragmatic. They’re the quality coach of the party, using guidance to help teams find their own answers rather than doing the testing for them. Their support levels up the testing skills of the whole team (a bit like casting bless on the party).
Whilst the cleric can teach others about the craft of testing, they must be careful to not become dogmatic.
The Druid
The Druid is a shapeshifter, able to change their testing into whatever form is needed by the team. To complement this, they are the quintessential generalist and able to turn their hand to many types of testing for a holistic approach.
The Druid will look to promote harmony by picking up glue work and tasks to support the team, they must remember to not let this overwhelm them and prevent them from testing.
The Fighter
Strong and powerful, the Fighter makes for a great leader as they have the force of will to say what needs to be done. A great tactician and strategist, the Fighter is the one to draw up the battle plan through strategies and approaches and communicates them to their team.
The Fighter is a great champion of testing and waves the banner, but must remember that a brute force approach can alienate others.
The Monk
The monk is agile, their testing style and skills let them work fast and reduce feedback loops within short sprints. They’re disciplined with a strong focus on where the risk is highest and what information they need right now; allowing them to avoid distractions and do the work that the team cares about.
Whilst going fast can help the team to get to production, the Monk has to remember to try and elevate quality and not just test the bare minimum.
The Paladin
Lawful and order are the ways to describe the Paladin, they like to have a clear way of working and structure to their testing to ensure that it’s done right. Having clear structure about their testing means they can speak to the core truths about testing, being trusted to give advice on the quality of something.
Able to clearly work with the certainty of standards making them a great tester for regulated environments, the Paladin may struggle in a more uncertain environment.
The Ranger
An explorer, suited to the unknown, the Ranger has the exploratory testing skills to thrive within uncertainty and tame it. They chase after their chosen prey (whether that be bugs or information) and don’t rest until they find it and share it with the rest of their team.
Whilst the Ranger is highly independent and can set their own testing scope, they must remember to be pragmatic and keep the whole team’s needs in mind when exploring.
The Rogue
The Rogue works as an ethical hacker who works to disarm the traps of a system and break through the security of an organisation. Working from a position of stealth they can test in the areas where nobody is expecting to find weaknesses in the system.
The Rogue has a deep specialism and can be called upon to deal with a specific problem, they also need to know how to work with a wider team for solving other problems.
The Sorcerer
Sorcerers are wild and powerful, they deliberately try to break the system to see how it copes. Using chaos engineering to force failures and stress tests to hit systems harder, they find the limits of what a system can take and check that it recovers when things go wrong (like a service falling over mid transaction).
Although great at finding all sorts of deep issues, the Sorcerer must remember to adopt a more planned approach to allow for reproduction of issues.
The Warlock
The Warlock serves a higher power, their patron is the customer and they act as their voice in the team. They understand the use of personas to see the system through the eyes of different people (strongly supporting UAT and usability testing) and can use their own experiences and differences to have empathy for the people who use the product.
Whilst being strong at the human side of testing, the Warlock can sometimes fall into the trap of business process and forget to question a “we’ve always done it that way” mentality.
The Wizard
A learned scholar, the Wizard brings the skills from their studies into their work. They read books and blogs (probably the release notes too) in order to keep up to date on the latest software development and testing. They value proven techniques and doing things the right way, usually thriving when they can plan out their test cases before they start.
Whilst the Wizard has many certifications and knows a lot about things in theory, they must not lose sight of what practical hands-on experience can give them.
A Party Full of Testers
Adventurers don’t always go alone, they take a group of friends and allies with them to slay beasts and gather treasure. In the same way testers can work together to form a party of different classes to overcome the challenges that they face.
When looking to create a testing team, much like an adventuring party, we should look at the classes we have to spot any gaps and bring in somebody who fills the need we have (that’s culture add, not culture fit). If we have a party of all Bards, maybe we need an Artificer or a Fighter to balance things out and bring in some skills that we’re missing.
Plus by having a more well rounded party means we can learn from each other and multiclass by picking up each other’s skills!
BONUS: The Dungeon Master
The creator of worlds and people who tells stories and sends parties out on adventures. This is the AI testing specialist, who build out groups of agents that play testing roles and documents the lore and world building through context and standards.
The Dungeon Master brings a party, but must remember to sometimes roll their sleeves up and play the part of a character themselves and do the testing hands on (not just pull the strings behind the scenes using AI).
So what’s your testing class? Do you have a single or a multiclass specialism?