Categorising the Periodic Table of Testing to help scope projects using MoSCow

First published on The Big Test Theory.com in August 2017 

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 Testinghas 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, especially ones that look cool when put up on a wall. 

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 is 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 as 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?

Using elements from the 1.3 version from 5th January 2019 of the table, different elements have been put in columns labelled, must consider, should consider, and could consider

I’ve used a Must, Should, Could (MoSCow) 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 – There are virtues of exploratory testing, 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 – Let's face it. On one hand, you have to document. On the other hand, 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 you're releasing. (in the talk point to Ash’s blog and other good sources)

Test Data – In context (yes, I said it again), possibly one of the most vital ingredients for testing. Whether it’s unusual, short or long names, 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.