Test All the Things with the Periodic Table of Testing - Ady Stokes

13th January 2023
  • Locked
Ady Stokes's profile
Ady Stokes

Quality Engineering Architect

Test All the Things with the Periodic Table of Testing - Ady Stokes image
Talk Description

Ever wanted to test all the things but forgot something along the way? 

Ever wanted to look at the vast testing universe and plan what direction you want to go or what you want to learn next?

Ever wondered how much you know or wanted to measure or evidence this to someone? 

Well now there’s a one-stop shop to help you remember, plan your learning or show someone what you know.  A resource that will not only inform your decisions but hopefully inspire them!  A source so awesome it will let you look at your project from not just a test but from a manual, technical and a personal perspective too.  A visual heuristic that can help shape your learning, show the value testing brings and can assist in identifying the ‘what and how’ of a testing strategy or approach.

Introducing the Periodic Table of Testing.  A visual heuristic of the testing universe covering everything from manual to technical testing, from personal drivers to work methodologies.  In the beginning, I was a business user who did some testing.   It intrigued me and became my career.  I was ok, I tested what it should do.  The more I got into testing the more I read and learned, the more sophisticated I thought my testing became.  But essentially, the more things I uncovered lead to even more things I didn’t know I didn’t really know! The more I read the more confused I became about what there was, how it all connected and what paths of learning I could/should follow.  When to use what, how much of something should you be aware of, particularly specialisms like security.  There seemed to be multiple opinions, often contradictory, about what I should and shouldn’t be learning.  So I started making my own ‘list’ which grew and grew.  I tried various ways to visualise the information until I tried the table and that seemed to work well.

As well as highlighting how the table can be used I’ll share some of my experiences such as; the first time I had to do some testing on user access I thought I’d done well, thinking of different scenarios… until there was a production issue!  I’d covered user access but not all the roles.  From the investigation I found there were individual and service account permissions that were not taken into consideration.  That was when the ‘UA – User Access / Permissions / Roles’ element was born.  This led me on to thinking about penetration testing and looking at possible attacks.  Had the table been around then, I would have been able to at least ask questions that might have helped identify our test environment was set up quite differently to live.  

The long term goal of the table is severalfold.

  • To make the viewer aware of the possibilities available to new, current and potential testers
  • To help shape learning paths
  • To help people show their current development
  • As a reminder or prompt when creating tests
  • As a support for test advocacy showing the multi-dimensional range of testing
  • To use as a basis to identify the potential scope of testing in projects 
  • To start conversations and provoke thought

In creating the table and developing it to the point where it adds value to the above I’ve also been able to categorise the table into three distinct areas.  Those that really must be considered for every project, fundamentals, accessibility, data, etc. Those that should be considered dependent on the project, operating systems, capacity etc.  As well as those that could be considered. As part of the session you will also learn that no technique or ‘element’ lives in isolation.  Personas, for example, expose user journeys and tours. Accessibility testing exposes poor design and usability.  I’ll work through the table's sections explaining their aim, why they are split in that way and looking forward, what possible inclusions or changes are under consideration.  I’ll show how I think the table can be used to scope projects, direct your learning, help you gather evidence for your end of year reviews and even create better job descriptions and advertisements.

I’m not looking to make money by selling this.  I don’t even have advertisements on my blog, I just want to share my ideas to help people and keep improving it so it can be of more value to more people.  

What you’ll learn

By the end of this talk, you'll be able to:

  • TBA
Ady Stokes's profile'

Ady Stokes

Quality Engineering Architect

@A11y_Ady on Twitter (X). Passionate about accessibility, exploring and testing as part of the creation and development of software. I help teams build better software and I strongly believe in collaborative methods and using different thought techniques and people perspectives to look at things from many angles. Accessibility is about inclusion, not just disability. In my career I’ve been a Director. Test, BI and Logistics Manager. Tester, Test Engineer, QA, Site Lead Tester, Quality Engineering Architect and any other value adding role required at the time. I have also taught, coached and mentored people throughout my career. My career highlight is creating the Software Tester Apprenticeship for the Coders Guild and training people to get their first role in IT through government sponsored free training courses based on my apprenticeship. I have my own blog at The Big Test Theory.com sharing my thoughts, occasional poetry and my Periodic Table of Testing, a visual heuristic showing the breadth of the testing universe.
Suggested Content
Explore MoT
Test Exchange
A skills and knowledge exchange to enhance your testing, QA and quality engineering life
Cognitive Biases In Software Testing
Learn how to recognise cognitive biases, explain what they are and use them to your advantage in your testing
This Week in Testing
Debrief the week in Testing via a community radio show hosted by Simon Tomes and members of the community