The Curse of Knowledge suggests that when we know something we assume everyone knows it. Here I am talking about that in a 5 minute video.
My very first job out of University was with Andersen Consulting (now Accenture). I learnt all about programming (in COBOL, how antique) and testing then. Many years have passed since then, and the idea of a testing environment has just been a part of my world.
I’ve been working on change management in releasing software / SAP upgrades / apps for a few years now. I’m still surprised that people we ask to be UAT / User Acceptance Testers have no idea what a test environment is. I’m also surprised that the people working in IT don’t recognise their curse of knowledge on this subject. Rarely do we explain it, because we just assume that everyone knows.
Here’s an explanation I wrote recently to explain “the obvious” to the uninitiated.
Go Crazy, you can’t break it
Test environments are not “real world”.
They are a copy of the real world (production) environment, often a few months old. Nothing you do in a test environment impacts the real environment.
You cannot break a test environment, and if you do break it, that’s good news. Because you’re in a testing environment we can put it back together and work out how to stop that happening in the real world.
The great thing (and the discouraging thing sometimes) is that because you are testing things you will probably find that some things don’t work.
Be happy if it doesn’t work! That’s what testing is for – to find problems and fix them.
You’re in a restricted and selected cohort of people who are testing this, so that the wider user community can benefit from a working system.
Every time you find a “fail” on a test, rejoice. One more inconvenience you and our colleagues won’t have to suffer when the system goes live (They say “break it, or live with it”)! So thank you for taking your time to test, we all know you have important things to do, and this isn’t at all a normal part of your job.
As a side note: if you enter something (a purchase order, a supplier, an expense, a customer) in the test system it does not exist in the real world. Conversely, if you added something in the real (production) environment yesterday or a week ago, it will not be in the test environment.
If you’re ever confused about what’s happening in the test environment do put your hand up so we can help you.
I think of the working world as a “test” environment too. A laboratory where we can try things and see the results. And if we want different results we vary the test conditions.
You may be familiar with the concept of “test and learn” used in developing good data models. Life is a test and learn environment too. When we pay attention we discover what works, what doesn’t work and what could work better.
It only works if we’re paying attention to the right indicators.
Set up your human test environment for better performance
I coach and train exactly that to Data Teams everywhere – first we train your attention with what to look for, then we learn (together and apart) how to make things work better. Here’s what my clients say:
I have taken beta blockers before presenting major research results for more than 20 years (for the nervousness). Now I don’t.
Anne, World Class Researcher
After the presentation, my boss leaned over and said emphatically – ‘That was fantastic! I have never seen you present so well’
Mary, World Class Researcher
I can’t believe the changes that are coming out of a 90 minute meeting. I think it has had more impact than the sum of all meetings I have had in my professional life.
D, Senior Analyst, Research and Analytics department of a major bank
I found working with Cindy to be an engaging and extremely helpful experience, she was able to suggest specific techniques that assisted in building rapport with people, and in enabling me to present in potentially stressful or even hostile environments while maintaining effectiveness
Professor Chris Tinney, University of New South Wales.
