Gil Zur
2 min readAug 8, 2023

--

Mirror Model — Example

Photo by Михаил Секацкий on Unsplash

In the previous post I first revealed the Mirror Model
This time I would like to give an example that better illustrates the advantages of the model.
We will return to the example given in the previous article but take a step back.

Let’s forget for a moment from Mirror Model and imagine how we would implement the following two manual tests:
1. Successful login
2. Login with wrong credentials

Most of the tests looks like this:

1.

Login(username, password)

Assert Is_main_page_visible(), “Log in failed , main page wasn’t found”

2.

Login(username, wrong_password)

Assert is_error_credetials_visible(),“Suitable error messages weren’t found

Seems pretty simple, but let’s notice the problems:
1. The expected system behavior appears in the test itself, one change in the UUT will lead to many tests to failure.

2. For two such basic requirements do we really need two tests?

3. The error messages are in the context of the current phase in which the test is located, so that several tests that test the same thing probably throw different and sometimes unclear messages (in most cases, not the same automation developer writes the test)

4. Today in the era of AI we would like to do exploratory testing with the help of automation. With this writing method it is very problematic.

Mirror Model

So what will happen to the tests in the case of new model?

1. Login (user_name, password)

Still looking for the second test? There is no second test…. Only one test covers both requirements.
The test can run twice on valid and invalid login details.
Where is the magic? Everything is defined in the infrastructure — the infrastructure of the automation is a mirror image of the UUT.

Because everything is defined as part of the infrastructure, the error messages are always on the right context and always uniform.
Now, with this model , exploratory testing is possible, we can perform randomization of different actions and examine the behavior of the system (the requirements are defined internally, so only randomize the high level actions).

I recommend now to go back to the first article for better understanding.

Stay tuned!

Interested in an additional information or advice?

gilz1407@gmail.com

--

--

Gil Zur

Imagine a world where QA & QA automation become an elite unit and central screw in the organization.