Skip to main content

Scale Panic

Cast your mind back. 

The last time you were exposed to a new system how did you react? Was it a time of hope and excitement? Or of anxiousness and nagging dread? If it was the latter, you may have been suffering from something I like to call 'scale panic.'

First up, let me define what I mean by this in a testing context:
'When a tester first encounters a new system they need to understand and evaluate, the cognitive load from understanding the parts, interactions and boundaries is too intense. The tester often enters an agitated and slightly disgruntled state of paralysis for some time after scale panic has taken hold.'
The subsequent testing approach and effectiveness can suffer as the appreciation of the big picture means crucial context is often left undiscovered. So, why does this phenomena occur I hear you ask. Well, every situation is different of course but I believe it is centred around a key trait for a tester, awareness. To clarify, let's decompose:

  • People Awareness
    • Testers have many sources of information. Documentation, systems, financial reports, marketing information, the list is long. However, people generally generated this stuff and are worth getting to know. If your oracle gathering strategy doesn't include people, then you are most likely missing out on a crucial aspect of the system puzzle. If the majority of oracles were generated by people (or indeed are people), your questioning and communication skills are even more important than you probably think.
  • Technical Awareness 
    • I really don't want to disappear down the testers being technical rabbit hole. That argument is grey and for me, lacks clarity, and would need a whole other blog/book/mini series. Not what I'm after here. As a tester, do you understand the strengths, weaknesses and quirks of a given technology? What is a relational database good at? What is a document database terrible at? Without these relative basics, the cognitive load of a new system can be too much to bear. Learn the basics of technology and a new system? Big rocks to crack...
  • Depth Awareness
    • Man, I have a detail problem. Do I need to understand every little bit of every little thing before evaluating something? Sometimes. Does that get me into trouble? Oh yeah, but thankfully not like it/less often than it used to. I have learned that detail is useful, but when it is useful is the real kicker. One of the key habits for a tester is to put yourself on a leash. Whenever you feel yourself diving deeper than the situation demands or  deliverance distance from the beaten track, snap back to reality. Personally I use testing sessions with a timed leash, which I enable before going off road.
  • Temporal Awareness
    • Well, if testing is about shattering illusions, here's a biggy for pretty much everyone. Systems change over time. In fact, its pretty much the reason we are all in a job (and sometimes sadly out of a job), so when looking at the big picture of a system, accept that time will pass and it will change. Your understanding is an oracle, which is fallible and subject to entropy, as information erodes over time. This is natural, the key is to accept this cascading fallibility. When overcoming scale panic, accept you are taking a snapshot at a moment in time and question that accordingly as you test. 
  • Existential Awareness
    • When in the grip of scale panic, I see testers making small parts of systems move, which may give the illusion of progress in understanding but feeds an obsession. The obsession of how it works over what it is made up of and why it exists. I assert that how something works gives you a small insight into the scale of a system, but what it is made up of and why it exists give you a wider picture. Understanding the what and the why assists a tester to determine if the problem is solved at the same scale as the system and aligned with its purpose, rather than just what I see works in some way in an unknown context.

I've been thinking about this a lot. Mainly because as (mostly) a career consultant, I encounter new systems all the time. I have built a personal model, expressed above. Next time you encounter a new system, think awareness. Think about the people, technology, depth, time and existential aspects of the system. Then map that, a useful output for everyone, and a challenge to existing assumptions. 

Use it as a guide for your testing, always remembering that it's a model. It's wrong, but it's very useful.


  1. This is a truly enlightening post and i discovered it amazingly valuable. A debt of gratitude is in order for posting this and offering it to every one of us. It would be ideal if you keep up the great job. You are owning it !!


Post a Comment

Popular posts from this blog

Wheel of Testing Part 2 - Content

Thank you Reddit, while attempting to find pictures of the earths core, you surpass yourself.
Turns out Steve Buscemi is the centre of the world.

Anyway. Lets start with something I hold to be true. My testing career is mine to shape, it has many influences but only one driver. No one will do it for me. Organisations that offer a career (or even a vocation) are offering something that is not theirs to give. Too much of their own needs get in the way, plus morphing into a badass question-asker, assumption-challenger, claim-demolisher and illusion-breaker is a bit terrifying for most organisations. Therefore, I hope the wheel is a tool for possibilities not definitive answers, otherwise it would just be another tool trying to provide a path which is yours to define.

In part one, I discussed why I had thought about the wheel of testing in terms of my own motivations for creating it, plus applying the reasoning of a career in testing to it. As in, coming up with a sensible reflection of real…

Getting started with testability

At TestBash Netherlands, I said that, in my experience, a lot of testers don't really get testability. I would feel bad if I didn't follow that up with a starting point for expanding your mindset and explicitly thinking about testability day to day, and making your testing lives better! 

In large scale, high transaction systems testability really is critical, as compared to the vastness and variability of the world, testing done within organisations, before deployment, is limited by comparison. We need ways to see and learn from the systems we test where it matters, in Production.
Being able to observe, control and understand is central to testing effectively, and there are loads of resources and experience reports out there to help. I was/am inspired by James Bach, Seth Eliot, Matt Skelton, Sally Goble, Martin Fowler and a little bit of PerfBytes/Logchat, so lets see if it works for you! 

Overall Model:

Heuristics of Software Testability by James Bach…

The Team Test for Testability

You know what I see quite a lot. Really long-winded test maturity models. 

You know what I love to see? Really fast, meaningful ways to build a picture of your teams current state and provoke a conversation about improvement. The excellent test improvement card game by Huib Schoots and Joep Schuurkes is a great example. I also really like 'The Joel Test' by Joel Spolsky, a number of questions you can answer yes or no to to gain insight into their effectiveness as a software development team.

I thought something like this for testability might an interesting experiment, so here goes:

If you ask the team to change their codebase do they react positively?Does each member of the team have access to the system source control?Does the team know which parts of the codebase are subject to the most change?Does the team collaborate regularly with teams that maintain their dependencies?Does the team have regular contact with the users of the system?Can you set your system into a given state…