By Didac López (ERNI Spain)
Introduction
When automating tests against a human interface, it is common to start by wondering which tools to use. It is easy to get lost among the many frameworks and tools that the market provides.
Teams begin to question their technical knowledge and the technological challenges each tool covers, such as element manipulation, integration with other systems, or reporting.
This guides decision-making towards a weighted calculation between reducing the learning curve, minimising the cost of licences (if any), and finding sufficient technological power to meet testing needs.
In this article, I will discuss another fundamental aspect in the development of a test solution for functional testing—aspects that are independent of the programming language, tools, or frameworks chosen and that provide answers to questions such as:
What point of view do we approach testing?
- What is the architecture of the automation framework?
- How are we going to organise our code?
- What software design patterns are we going to incorporate?
For more details, this topic is explained in depth in the e-book, which can be found here:
The code illustrating everything discussed in the article can be found at https://github.com/ERNI-Academy/guideline-screenplay-pattern.
Sophistication
At the dawn of digitisation, there was no wide variety of tools, no communities, and not even a culture of testing, as there is today. All this has come from a process of sophistication that accompanied increasingly complex software developments.
While the software was simple, with few points of failure, the companies’ strategy was limited to hiring staff (with domain knowledge at best) who manually tested applications. This practice is still partially maintained today and has some benefits.
However, there is one key factor that led to the first step of sophistication in testing: cost. In a context where most projects were done following a waterfall, the cost of discovering a bug in the final testing phase and reversing the whole development process was very high. The development of unit test frameworks, the first e2e automation frameworks for regression testing, alleviated this cost by allowing more stable versions to reach the testing phase.
Back when there little programming knowledge in the ranks of the testers, many approaches were implemented using what is known as linear scripting. In this approach, each tester manages the automation tools and implements the interactions explicitly, reaching a point of high maintenance cost and being a very susceptible solution to changes in the system under test.
This growing trend of programmers entering into test automation tasks and the high cost of maintaining the linear script led to a second step of sophistication: best practices and design patterns, almost unanimously represented in the Page Object Model (POM).
Each POM represents a page of the application we are testing, taking responsibility for locating and interacting with its elements. This sophistication is much more resilient to changes in the application as we have a single POM to maintain while the tests remain intact.
While POM has many advantages, it could be better and has some problems with modern, large applications full of reusable components.
With all this, we have reached a point where there is no longer a technological barrier between the testing and development worlds. Software architects are working on sophisticating how we do test automation. This brings us to one of the latest proposals for sophistication: the Screenplay Pattern. A paradigm shift, we stop looking at the application we want to test and put the actor who will use it at the centre.
Screenplay Pattern
Screenplay Pattern is a test design pattern inspired by film scripts. In it, one (or more) actor(s) interacts with the environment around them by using their skills.
Screenplay defines four main entities:
- The actor: Who or what interacts with the application? What attributes does it have? What permissions? Each actor centralises the action and, in some implementations, can serve as a fixture, bringing with it everything necessary to run tests on our system.
- The skill: What can you do: browse the web, write to a database, listen to a Broker Message? Each skill manages an automation tool or framework and acts as a wrapper, allowing the actor to have as many skills as needed.
- Interaction: What minimum action can the actor perform using a particular skill? In the case of the web, good examples would be Click, Fill, and Drag-and-Drop. Each interaction implements the generic logic needed to execute it using a compatible skill. The actor will perform the interaction using the appropriate skill among all the skills he/she has.
- The task: What are the domain actions, and what is the user behaviour in a business sense? Each task is composed of multiple interactions, which are grouped together to give them a sense of mastery.
- The question: What information does the actor need to know about its context? Is the application on the page we expect? How many selected rows are there in a table? Each question defines the logic needed to extract information from the system we are evaluating or from the test environment.
Finally, in a Screenplay, we also need to define how we are going to find the elements we have to interact with. Unlike POM, this order can obey different criteria than the structure of the pages.
Conclusions
Screenplay makes the design of automatic tests more sophisticated. On the one hand, it improves Page Object Model by optimising design time and reducing maintenance costs. On the other hand, the complexity of the automation solution is higher, requires more seniority to perform, and has less community support.
LinearScript | POM | ScreenPlay |
Complexity | Minimum | Medium |
Maintainability | High | Medium/low |
Orientation | Procedure | System Under Test |
Design Speed | High | Medium |
Community Popularity | Deprecated | Standard de Facto |
Happy Testing.