AEIOU Model Explained 1 - Test Actors, Test Object, Participants, Layers and Points of Control
In this article, I will elaborate further on my concept of What is a Test? in light of the The Vowel Model (The AEIOU Model) of Pluralistic Testing.
Note: If you are someone who is caught up in caging of testing into types of testing, strict walls around words etc, you may not be able to understand this article fully. So, please keep an open mind or/and go through the previous relevant articles in #EmbracingInfinity series.
I am trying to create models which are able to explain my own experience about human role in testing, automation in testing, testing at various layers and evaluating functionality, performance, security and user's perceptions etc. Existing models do that only partially. You are welcome to join along in my journey.
I've given some draft names to various concepts. Remember always. Words are just doors to concepts. So focus on concepts. Call them what you like.
Let's have a relook at my Vowel model:
As one can see, interactions and observations part is at the heart of the model. Before we go deeper, let's relook at my undefinition of a test:
Test
As mentioned earlier, please keep your mind open. If you are thinking of test idea, test condition, test charter, test case etc. here, park that thought atleast temporarily.
This article focuses mostly on the part of my test "undefinition" highlighted in bold.
A test is a theoretically possible, mental or documented, standalone or subsequent instance of one or more expected or unexpected interactions, comprising of input & output variables and related protocols, with a test object and other participants - humans or non-human (real objects or doubles), in a combination of sequential and parallel steps, whose birth and life is controlled by the people, processes and technologies involved, further constrained by the time and budget availability, automating wherever it is necessary and feasible, in an attempt to observe all these objects to understand the test object, in the light of the assumptions and expectations of the people involved with a hope to determine confidence in Quality of the test object in terms of whether different targeted users will feel about it in the same way we intend them to and/or whether the targeted objects will find it fit for purpose with respect to the targeted Quality attributes, taking into account side-effects on other Quality attributes, conducted by one or more testers who are supposed to make sense of themselves in the midst of all these noises and contradictions, managing perceptions about risk and value about Quality in the overall context which is inherently non-determinable as theoretical infinity exists across all pieces of the puzzle.
Test Actor
Anyone or anything involved solely in testing for the purpose of a test.
Interaction
It's the communication between two entities. On either side of the interaction, there can be humans and/or objects and can be thought of as an exchange of input and output.
The purpose of interaction in the context of a test is open-ended. It could be about providing inputs, observing inputs, observing outputs etc.
Input
Anything going into the Test and/or Participant objects directly or indirectly governing behaviours relevant to the current test as a part of an interaction. It also includes the values of state variables of these objects.
Examples:
Output
Anything coming out of or within the Test and/or Participant objects relevant to the current test as a part on an interaction.
Examples:
Participants
The participants in a test are humans or non-human-objects that can be real or doubles. For now, you can think of them as non-human.
There are three types of participants:
The non-test objects and the way we handle them in a test is what makes way for deeper professional testing when the obvious, feasible testing is done.
Test Object
The Test Object is the key participant in a test.
Whatever is the object that is the subject of your test is the test object.
It must be a real object.
In the context of a software, it can be as small as an expression in programming and as big as the system of systems.
There should be one Test Object in a test. However, it helps to think in terms of test action and intent layers, which we discuss later in this article.
You don't need to be exact about what is a Test Object. For example, is the complete web application your test object for a test? Or the GUI is just a means to deliver the inputs to the actual target/subject which is a specific web-service which is the Test Object? When you enter a wrongly formatted text in the GUI of the app, is it the app which is the Test Object or the in-browser client-side JavaScript the Test Object? Or is a specific regular expression validator function there the Test Object? This is ambiguous. The irony I see is that professional testing is when we embrace this ambiguity rather than trying to over-categorise.
In my mind a test object can be a document, a person's skillset, a tech support call. Anything. In my mind review and testing are the same things (static vs dynamic testing, I know. The distinction only bothers me.).
However, here we focus on test objects as technology objects like software/devices.
Participant Objects
Whatever is not itself the subject of your test but needs to be controlled or observed for the purpose of a test. Theoretically, there are infinite participant objects.
These objects are a part of the software or device that you are testing.
A Participant Object can be real or a double.
A Test Object can contain a Participant Object.
A Participant Object can contain a Test Object.
A Participant Object can be outside of what you are building - a library which you consume, the device where your software runs, the operating system of the machine and so on.
The purpose of using doubles instead of real objects is to increase testability of the test object.
Test Actors at the Point of Action
This is the most complex piece to understand amongst participants.
At some point I will write a separate article on this.
For now, you can think of an object which is not a part of your software/device (think shipping) and excluding any test doubles, that you have created for the sole purpose of testability. Some examples include an automated slave to trigger testing related commands remotely, a monitoring component etc.
领英推荐
Test Intent
The purpose of conducting a test that governs the roles of test objects, participant objects, test actors, as well as determination of input and output variables and so on.
For example, in integration testing, two objects could switch roles of being a test object or a participant object depending on what you are testing. Another example is when you are conducting a test where the default point of control is at GUI layer but you want to see the impact on an internal component.
Point of Control
It is a locus of execution in a test with respect to interactions and observations.
For simple tests, it is the interface which is the primary point of input-output where you as a human or a tool/automated expression of a test is conducting the test.
I find keeping the idea open, more useful as compared to the above oversimplified approach.
A theoretical context-free answer to many such questions is a No. There is no perfect Point of Control. Each Point of Control is a compromise.
At a simple glance, you will be tempted to think about points of control as GUI/Web APIs/DB interface etc. for a web application, for example. At a deeper glance it is a more involved task.
Thinking in terms of a a single point of control puts severe limitations on the usefulness of tests.
Let's say you write a framework to do GUI test automation for a web application. Now, you automate a test to control a browser. You want to measure the impact of this interaction on the CPU usage on the corresponding web server. You'll need to ask yourself now whether your framework has the control over the system to let you interact in this way. This is where the concept of splitting the control between point of control vs point of action becomes necessary - you'll need to push some pieces of control to objects near to the place where the action is taking place. In AEIOU model, this splitting of control is where the Test Actors at Point of Action come into play as participant objects.
When you are doing the above scenario as a human, you'll need to ask yourself whether you have access to the said web server? Do you ask another human to observe the web server for you? This is where considering a human as a participant comes into play as a Test Actor at Point of Action.
For deeper, professional testing, a tester typically needs to decouple the idea of a test into various points of control across the test objects and participants and accept the plurality/multitude of these points for a single test. So, point of control can not be imagined as a single defined point rather as a lot of scatter points with one of the points as the primary control point.
Out of these infinite possible scattered points of control in the system, for a test, there is one point of primary control and a few other points of control that you choose.
There are various types of points of control.
Points of Control - Primary Point of Control
A test typically has a single primary point of control from where all the other points of control are controlled. Identifying this will have a huge impact when you think of automatability of a test.
Points of Control - Point of Interaction
This is the point in the system where a specific type of interaction can be triggered with the test object, a participant object or a test actor.
Points of Control - Point of Input Interaction
This is point where an input is taken by the test object or a real participant object.
When you login, for example, and provide credentials, one point of input is let's say the GUI of the web app, while another point of input is the authentication logic consuming the output of a DB query whether the credentials are valid.
Points of Control - Point of Observed Input Interaction
Often ignored, it is a point in a test object or participant objects or test actor objects where it is checked whether the expected interaction happened and whether the expected inputs were got, along with how many times it happened etc.
Points of Control - Point of Action
These are the points in the overall system at hand where the action takes place as a result of your interactions. This is where a tester's imagination takes a front seat. Action is not a simple single thing. It is the totality of a lot of sub-actions that take place. A tester typically creates a notion in his/her mind what part of this action currently matters and is the focus.
Points of Control - Point of Observed Output Interaction
It is the point where the output is got.
For simple test, this is assumed to be in the response to an interaction a tester did. However, for almost all tests, as the notion of output is expanded, this is never the case and what is seen in the response is a very minimal part of output. For example, when you see the result of a RESTful query and assert on the response, you consciously/sub-consciously are ignoring a possible insecure entry the system made in a log file somewhere as a result of this call.
Test Action Layer
It is a notional/logical/architectural grouping of participants.
It is the layer where different parts of the behaviour under test unfolds.
This layer might be in direct or indirect contact with the primary point of control. That's the reason you might need to embed test actors in one or more test action layers to conduct a test.
Test Intent Layer
It is the Test Action Layer which is the primary target of a given test. Hence, inherently it can also just be a notional layer.
Whether a given test hits the intended layer is where it calls for art and craft of testing.
Imagine a SQLi payload. The Test Intent Layer for it is the SQL interpreter running in an RDBMS. Are you sure that the database in use is an RDBMS? In the case it is, the payload will need to travel through a typical custom implementation from one web application to another till it reaches the intended layer. From offensive security perspective, are you sure that the payloads that you planned even hit the right layer? Is there a scope for tweaking the payloads to find one which could have bypassed the layers before the intended layer?
Food For Thought
I'd park rest of the discussion for further articles.
Meanwhile here are a few pointers for you. Think of the following contexts:
I have mentioned it earlier. Simplicity is good. But it will answer only simple questions for you. Embrace Complexity as engineers. Reserve simplicity for explaining solutions to those who don't know the subject.
I see technologists in testing getting irritated when discussions like the one in this article take place, or worse when even deeper philosophical discussions happen about the profession. A tool or coding is not a replacement for a philosophical thought. It's one of the ways to express a philosophical thought in work. So, those who care about any of the nodes - people, process, technology - the sane voices should come together rather than working to disrupt the other. Peace.
That's all for now.
Some related articles: