Notes : Improve your Automated Test Design with S.A.C.R.E.D

From the recent talk by Richard Bradshaw on LinkedIn, I would like to highlight my learnings/ takeaway from the event.

In his talk, Richard Bradshaw talked about the S.A.C.R.E.D Model of testing to improve the Automated Test Design.


S.A.C.R.E.D is a model used for testing that enables freshers to understand how manual and exploratory testing skills can be converted to automation to a certain extent.

Let’s understand S.A.C.R.E.D mnemonics in detail,

S stands for – State Management

To automate your system, you must first determine the state in which it is ready to be automated. 


Data is needed to make the system prepared in the state to automate it, so you need data to use, digest, and work with.

It is also necessary to complete the System configuration and feature flag along with the data. In order for the test to be run in an isolated manner, system settings need to be set accordingly.


 People who get involved in testability is not 1 individual job it takes a lot of people in the organization, it is a whole team approach.

Testability is the ability to test and  Automatability is the ability to automate.

It would be best if you had the Hooks and the DB hooks ready to make the system prepared in the state to automate.


You need to Spin Up the machine and configure the machine to give access which is done by the Ops.

Developers help to create data programmatically. 

PO and BAs to set the priorities, to share the challenges we will face in the estimates.

A stands for – Actions


What are the steps, Actions, and Behavior we need to do, basically how do we interact with the system?


What are the steps we take for action, the flow we follow for the system, and the decisions we make in the Automated test?


We do these actions with Code, the Framework that we build.

Modeling a system can help you be aware of what is happening on the screen. It makes it easy to know what action you are performing.

Observing is also important, if you don’t observe how the system is performing the action the test can be flaky and brittle.


The dev and especially the UX team can help you with what changes or how the UI is built which makes it easy to understand how to handle wait/ loaders etc. 

C stands for – Codified Oracles

Oracles can change, but if we codify them, they won’t change.


It’s the assertions that we use.


Tacit Knowledge: the knowledge which is there in the head and not documented

Explicit Knowledge: the knowledge which is given to you.

Communication: Knowledge is derived while talking to your peer and you realized that these are the good things.

Test and Framework limit your ability, we should avoid binding and changing the oracle to fit the tool we use.


 Everyone can help you get an idea/knowledge that you can imply.

R stands for – Reporting

Reporting is the sharing of results with a required detail of what the report is about.


There are two aspects of Reporting :

1) Reporting to the team

2) When a test fails what do you need to know?

1) Reporting to the team :

When reporting to the team we might have to understand how we need to do it.

  • Whom to inform?
  • Do I need to Integrate with CI?
  • Do I need to send an email?
  • Do I need to send it on slack?
  • Do I need to integrate with the Test Management tool?

 2) When a test fails what you need to know :

  • Logs when proper message and exception logged.
  • If a UI test did we take screenshots
  • For Unit Test do we have a proper message?
  • Do I have enough information for an investigation?
  • Is the failed test a bug or a flaky test?


Using a framework with have integrated report. Modeling. Having a dashboard for results. Or Integrating it with a CI.

Evidence helps to examine the results. The Sooner we know the problem the sooner we fix it.



E stands for – Execution

 It usually happens, when the test perfectly works on my machine and doesn’t work on the pipeline. We need to be conscious of how we design test cases to run on.


Is the test need to be run on the development environment?

Is the test need to be run on the testing environment?

Is the test need to be run on the production environment?

Do we need to run it in pipeline CI?

Do the test need to run on schedule or to be triggered? 


Many ways to do it like Can you config, Can you have properties, with build tools, CI/CD tools, and Docker. 

If using a certain tool License can affect your run, take that into consideration. 


People who can be involved in Testers, Ops, and developers.

D stands for – Deterministic

It is often missed.

You should think that is your automated tests deterministic.


We need to accept that the automation test written is deterministic because we know how the system works and have seen it in past. The test should be reliable and speedy. It’s the goal.


By testing, state, and maintenance.



Leave a Comment

Your email address will not be published. Required fields are marked *