What is a Scream Test

If you work in IT, then you will know that there is the ever-present spectre of zombie systems, which remain active and running, but not actually doing anything. These can be servers that were implemented for a project that got cancelled, file shares that are no longer accessed, databases that were provisioned for a dev-test-prod lifecycle that have never been used, Intranet sites of stagnant content, or even entire stacks of systems that are barely touched. When the business is asked if these systems can be removed, no-one wants to take the responsibility of removing these systems – “just in case” it is needed by someone. Unfortunately, the only way to resolve this is to do a scream test. But, what is a scream test? What is scream test meaning?

What is a scream test?

To find out if these systems are really in use or needed, and when no-one is willing to make the decision to remove them, the scream test is needed to find out if it really was needed. In simple summary, a scream test is to stop the service and see who screams. The important part is that the scream test must have a simple and rapid way to return service, if someone actually screams and complains.

The Scream Test is simple – remove it and wait for the screams. If someone screams, put it back. The Scream Test can be applied to any product, service or capability – particularly when there is poor ownership or understanding of it’s importance.

Preparations for a scream test

Of course, you can’t just go around hitting power switches, as there may be unknown affects. Doing a little bit of due diligence can help your scream test be successful – which is, to have no-one scream and to be able to get rid of an unwanted system or service.

1. Look for documentation or other reference information that will tell you who the owner is, who interested parties are, or what the system is used by
2. Disable monitoring and alerting for the system
3. Do a soft disable – rename the shared folder, pause the Windows service, take the system offline – for just an hour or so. Then return it to service. Wait for people to react and have time to raise a support call.
4. Then, for a server, restart the entire system during the day. Again wait for support tickets, but this is different to the previous step because it will ensure that there is no in-memory configuration that is unknown.
5. Disable the system or service completely – depending on the nature of the system, you may want to ensure this is down during month-end (if it was for financial or reporting uses) or for a few weeks. You want to be able to bring it all back online if someone complains.
6. Before deleting or re-purposing the system, you may want to archive the data, migrate it to a data lake or document the configuration, so that if you get a delayed scream, you can still get the data.

Scream test meaning

At the most simple, the scream test meaning is that you can only find out if people will miss something if you take it away – everyone resists losing something, and will insist it needs to remain, but the scream test meaning is to find out if it really is needed or used.