Categorising the Periodic Table of Testing to help scope projects

Why categorise?

There are several reasons, some more personal than others.  Entering my 52nd year of visiting Planet Earth my mind needs as much help as it can get.  I’m not saying I’m over the hill, but hills can be steep!  I have noticed the odd occasion where words escape me so best not to take chances on forgetting vital information. 

The Periodic Table of Testing has elements.  But not all elements are created equal!  Elements can be useful for specific projects but not appropriate in some cases for lots of different reasons.  Therefore it’s not going to be something that comes into consideration when thinking about project scope or test strategies too often but could be considered depending on the project and context.  Things like accessibility, test data and access however are areas that must be primary considerations whenever you start something new.  There are others that should be considered and that’s why I wanted to categorise the table both to help start those conversations and act as a bit of a guide without dictating. 

I’ve always believed that mnemonics and heuristics are excellent helpers for tasks in general and more so for repetitive ones.  Things we do over and over again have an annoying tendency to become brittle.  We forget one little step or thing and then it quickly becomes ingrained as if we always did it that way.  Having useful reminders around is helpful and especially ones that look cool when put up on a wall. 

What’s in each category?

So below is the first draft of Scoping Categories which I have classed as considerations.  It’s important to say that everything done on both the table and these categories are my opinion from my context.  I don’t expect everyone or indeed anyone to share my opinions so, as with the table itself, you may look at this and think, ‘that’s so wrong’ and you would be right! – In your context.  While I feel this can be a useful reminder and tool, I believe the power is in its ability as a useful guideline and being that reminder to help start conversations by prompting questions such as: 

·         What does Security mean to us in this situation?

·         How can we achieve living documentation for our project?

·         Are our risks defined enough to prioritise testing?

·         How can we use automation for testing?

·         Do Digital technologies apply?

·         How do I start testing for accessibility?

I’ve used a Must, Should, Could category definition in an attempt to reinforce the thought that these are considerations, not instructions.  While I have considered each item carefully and where I think they fit, I don’t think it would be useful to go through them all and explain why they are where they are.  For one you would be bored to death and this blog piece would be far too long!  But I do think I should try to explain a little why I believe you must consider those under that category.  I’ll (try to) make it brief, I promise.

Accessibility – Number one consideration from design principles to user base and the most overlooked.  Of course it’s there!

End to end – Focused testing is vital but if you don’t test end to end (whatever that means to your project) you can’t be confident everything ties together.

Discovery – It’s important in any plan or strategy to remember you will discover things that change your plans (put in Oscar Wilde quote, life is what happens when you’re busy making plans, for talk)

Exploring – I extolled the virtues of exploratory testing in this post so won’t go on again but this also covers general exploring of the system you will be testing.  Things that were not apparent from your up front information will be discovered. 

User Access / Permissions / Roles – If you think about how users will be managed you can’t help but think of the different states for your testing.  This will also give you an early indication of whether Personas will be useful.

Security – Linked to the above, even purely internal applications have potential security issues that need considering.

Analytics – From usage statistics, usability analysis and many others understanding how your system is being used and working will help direct your testing focus and efforts. 

Living Documentation – Lets face it, on one hand you have to document, on the other automated tests can be really valuable.  Living documentation gives you the best of both done well.  Lightweight but always up to date documentation.  Focused automated tests on the most valuable functions your system performs.  Win-Win!

Unit Tests – Almost goes without saying.

Testability – Of course! Even in the most technical builds we must ask, how will we test this?  Harnesses, scripts to reset data, fake services, it doesn’t matter what you use or how you apply it, it has to be testable or you have no idea what your releasing.  (in the talk point to Ash’s blog and other good sources)

Test Data – In context (yes I said it again) possible one of the most vital ingredients for testing.  Whether it’s unusual, short or long names (link to a cool article), different statuses or variants in information test data can be your best friend.  Just remember to scramble it if it’s a copy of live!

Monitors / Logs / Audit trails – We all love a good audit… don’t we?  Having logs and audit trails makes audit easy but having access to what your system is up to can help identify the strangest of behaviours.  Logs have so much value, find them, understand them and make sure your team gives them the priority (in context!) they need.

Risk Based Testing – aligning test plans to risk is a way of ensuring your testing is adding the most value to the project at any given time.

I excluded personal elements and methodologies on the basis that those are related to ways of working rather than tools to use in plans or strategies.  I’m happy to hear a different opinion though. For those who are eagle eyed yes the ‘first’ is version 1.1 as I made a number of formatting changes and tweaks while writing up and it’s for my own tracking.  

Note: The categorisation above is based on the latest version of the table, 1.7 which is below and on the Current Periodic Table of Testing and Archive