I need your help please to make my idea better - Periodic Table of Testing

Hello all,
I’m working on an idea to give a view of the testing world. It’s called the Periodic Table of Testing (as much because I’ve used the Periodic Tables styling) to try to show ‘all’ the different types of testing types/techniques/areas of influence there are. As you can see below I’ve grouped them generally and with sub categories.

I’d really like your help in understanding from others points of view
~Do the main and sub categories make sense? Anything major missing?
~Do the sub categories make sense?
~Are the elements too simple?
~Are the scoping categories (second image) useful using Must, Should, Could?
~Any other feedback.

I don’t see this being finished anytime soon or maybe ever as we learn things everyday but as a view of testing, a prompt for potential career paths and as a tool for scoping (see second image) I think it has lots of potential. I’ve written about the origins of the idea on my blog The Periodic Table of Testing, an introduction and history — The Big Test Theory

Sorry to go on so long. I’ve had some generally positive feedback so far but if there’s any talented group that will be honest open and hopefully gentle then that’s you great folks here.

Thanks, Ady


Hi Ady,

Firstly, well done. It’s obvious that you’ve put a lot of time and effort into this. I hope you’re feeling positive about how it’s shaping up?

As a first impression, I can see many people finding this useful, especially as a reference point if running out of test ideas or looking for other areas to explore. At first glance, the categories seem to make sense, although I, personally, find things like this a bit difficult to look at because there’s so much going on. I have the same thing with mind maps, which are really popular, so I think I’m in the minority there. That being said, I can perhaps see myself referring to this with a specific purpose, as opposed to looking at the whole thing. For example, if I wanted to check something under a particular element, or that all the “must consider” items have been covered.

You’re probably unlikely to cover “all” testing topics not just because of the nature of the task, but also because if you’re modelling it against a certain shape, there’s a temptation to add some things here and remove others there to make it fit.

Are the sub-categories in any particular order? Perhaps to get around the shape and coverage problem, you could order them according to your perception of most to least essential, and include only the top 5 / 6 so there is no expectation that everything is included? But I suppose it depends on whether that fits your goal / purpose, and you’d need to state that somewhere.

Oh, it also wasn’t immediately obvious to me that the “headings” were actually at the bottom and everything stemmed bottom up. But once I saw that, it seemed okay.

How did you come up with the scoping categories? I can definitely see some debate around those groupings, especially amongst less mature teams or those with very limited resources who feel they cannot cover everything under “must consider”. I think the idea is good in principle, but if they’re presented - or interpreted - as fixed, then that might put some people off using it. If, however, it is well aligned, this would be great to have in a shared space for teams to refer to during the product lifecycle, and to spark discussion.

I hope that feedback is helpful to you and very best of luck for continuing this project.



Hi @adrian.stokes

Perhaps these two similar tables below can inspire you. Perhaps you haven’t seem them before - that’s quite understandable. (It took me some digging to remember where I had seen them previously) Nice to see #ministry-of-testing:the-testing-planet articles popping back up too. I’m certain good models are spotted by many in our industry. Share and cross-reference. Do continue to create something that has your viewpoint :+1:.


1 Like

Hi Cassandra, firstly thank you very much for your feedback it is very helpful. I do think these can be useful to people and I hope in time to create a site where people can play around with them and make their own views.

This is very much ‘my’ view of testing, which I hope others will get some value from, but over time I hope to make it a more general view which is why I’m asking for help. The elements are not in any particular order as I feel it would be down to individual context to make one more valuable (at a particular time) than another. I also don’t see everything being included but as terms and understanding change it can be updated or amended. I added versions to track it’s changes and as someone might find a previous one more in tune with their thinking. All the versions so far are available on my blog.

I must stress the use of the table for scoping is as a guideline for consideration. There’s no expectation, certainly from me, but hopefully in general that all the must elements should be covered. I believe they should be considered but again it’s an individuals circumstances and context that would determine what’s most important.

They are both intended to be helpers on our journey. A helpful reminder of ‘things’. But perhaps most importantly as you suggest, to prompt discussion.

1 Like

Hi Jesper, thank you very much for these. I am aware and have a copy of the heuristic cheat sheet but had not see those elements from QualiTest. I’ve commented on the post to ask if they have done anything else with their model or developed it in any way. They have an earlier version from 2014 but I need to review the differences between them to see how it has developed.

Looking at the one from your link, on first review their elements feel as through they come from a different perspective to my table. Their description of ‘essential’ elements doesn’t feel right to me and I’ll call out Defect Reports as an example. I don’t feel they are essential to good testing.

They feel a little in isolation from a team perspective with no reference to collaboration type activities. I don’t want to sound as though this doesn’t have value, it definitely does and I’ll review it against mine. I do have an as yet unpublished list of definitions for each element and I’ll be comparing the two for inspiration. I wonder if it was written from a waterfall type perspective which is why there’s a large focus on stages and documents? Lots to ponder. Thanks again, Ady


Saw this and thought of this forum post - https://twitter.com/scienmag/status/893056356403556352 :smiley:


Very impressive and can definitely see how this would be useful to people but a couple of questions I have.

Is Team Foundation Server too specific, maybe something more generic like Source Code Control?
What do you mean by Chaos Monkey? As my first thought is of the Netflix tool which doesn’t really seem to fit as a Manual Test Element or is there something you were meaning?
Why not include waterfall in the methodologies? I know it is seen as a thing of the past but the reality is that there are still a large number of companies that use it.

That’s awesome, I’ll find somewhere to use it! Thank you :smiley:

Thanks for the feedback Gordon, very useful. Like the idea re source control. I’ve changed a few to be more generic such as removing BDD and TDD for PDD - Practice Driven Development to be more inclusive of other practices such as design or feature driven development.
Chaos Monkey (to me) means going mad at the keyboard and seeing what the system under test does with the input. For clarity I should really drop the ‘chaos’ to remove confusion with the Netflix tool. Possibly add randomisation somewhere?
Excellent point re Waterfall. I’ve not ‘officially’ released version 1.7 yet as I’m working on a new website. Blogger is great but I want to do more with this so moving before I went to far makes sense. I’ll definitely put it in there. Again thank you so much for your help. If you want to see where it goes check out my blog (new one will still have the domain) or check me out on twitter where I’m @cricketrulz (applies to everyone who reads :wink:)

I’d really love to hear some more feedback on these. I’ve released the next version of the table based on the feedback so far.

And a post on the scoping categories. Hopefully these will provide more context and help you awesome people help me some more? Thank you

1 Like

Hello There Cassandrahl…you discribe all ur thought’s abt the periodic table which he created…
Indeed I read it…you almost expressed all my thoughts through ur comment…I personally feel…that this logical table ll definitely help a lot to improve & grow knowledgewise
It’s very deep Technology & u hav to find every possible way to remember ur logic through any aspect…It’s such a nice to see n discuss Technical things as by sharing our thoughts & experience ll definitely help us to improve technically.

Great Job…
It’s very deep Technology & u hav to find every possible way to remember ur logic through any aspect…It’s such a nice to see n discuss Technical things as by sharing our thoughts & experience ll definitely help us to improve technically.

1 Like

Have you performed Exhaustive Testing Practically?

It’s taken a little while but there’s a new version of the table available. Version 1.9 includes a new column under Testing Elements for Phases/Types of testing and some other adjustments. Please use the link to view and let me have your feedback. Without your help I can’t keep improving it and making it more useful. Thanks, Ady

1 Like

New Year, New Table! Apologies for not updating this sooner. A brand new formatting version of the table and scoping categories is available which is easier to print. I’m presenting at TestBash Brighton on the evolution of the table and how it can be used at the brand new Essentials Conference (https://www.ministryoftesting.com/events/testbash-essentials-brighton-2019).

So if you have any more thoughts or stories of how you have used it this is a great time to share. Thanks.