Currently, “test automation pyramid” – also known as “automatic test pyramid” (Examples can be mentioned as this article , or this article ) are quite common ideas, but can see serious problems with them. The things mentioned in this article are another way of thinking about how to use the useful aspects of “pyramid”, while minimizing the problems that this strategy brings:
- Instead of modeling as a pyramid, modeling the situation as a concentric sphere, because the “outer surface” of a complex system often has a lot of “areas” to pay attention to.
- Try building it by referring to a special sphere called “Earth”, so familiar to all of us, because we live on its “friendly” and “hospitable” surface. ;
- Next, illustrate this “Earth” with an inverted pyramid shape that focuses all of our attention and attention on the surface of the product, “Everyone’s habitat” to indicates the opposition to the pyramid shape of “Automatic test pyramid” (Model less interested in user experience).
- Combine dynamic (static) as well as static elements into data, not just code.
- We have to admit that maybe we haven’t tested directly at the lowest level of technologies (such as Chrome, or Node.js, or Android OS). In fact, we are often encouraged to believe in these technologies, because we cannot influence it much.
- We use the geographic aspect to explain more visibly why a good tooling strategy can access and test products at the underground level, though not necessarily at the lower levels of the platforms we are relying on. to enter.
Good interoperability answers deep-level arguments
The original pyramid (a triangular shape) is a non-contextual geometrical support. Basically, it is explained that: “It is just a triangle with more areas below it than the top, so we should do more automated tests at lower levels than levels. higher.” This is not a debate. Nothing in the nature of a triangle can tell us how it relates to the problems of technology. This is simply a shape that matches a statement that authors want to convey. Is learning symbols with weak semantics.
And of course, it is not wrong to use semantically arbitrary shapes to convey information (the shapes of the “W” and the “M” are opposite, in some way, and not who cares that the things they represent are not antagonistic. After all, this is a weak form of semantic transmission. A more powerful form is to use all forms that can respond to deeper arguments about existing topics.
The Round Earth – The Round Earth is trying to show it. By visualizing technology as a concentric sphere, we can understand that the volume of capabilities, the state space of the product tends to increase significantly with each layer – layer. Of course, this may not be necessary, because there will be many complex issues that can be “locked up” at higher levels by the lower levels themselves. However, these are real dangers that exist in our own technology repositories. An example of this risk actually found that HTML email defeated the security of PGP Email. Sorry. The more bells, sirens and layers, the more likely it is to leak information.
When speakers give people a round Earth model, people often start talking about caves, sinkholes, landslides and some volcanic jokes and how their companies live on a “hot spots” on “Earth”. Although these are just jokes, they also show that support is useful, and involves real problems in technology.
Round Reath model points out problems in testing at multiple levels
The original pyramid model has a Unit test at the bottom. At the end of the Round Earth model is the application framework, the environment is still working, and the development environment – in other words, the Platform – that we – not – test. Maybe someone will test, maybe they won’t. But you may not know and don’t even think about this. A practical example: The article author has written code compilers for video games in 16,384 bytes of memory. He needs to manage every byte of memory. Now that day is no longer available, the author writes Perl code and almost doesn’t care about memory.
Practically speaking, all developments are based on an assumption of “Bedrock”. These assumptions are usually safe, like lava or radon gas or groundwater “bedrock” poisoning. We can see that the lower technology level undermines our design. We must be aware of those risks, but we don’t mean that we test our platform completely.
At a higher level, we can test unit code itself. More specifically, Devs can do this. Although it is possible to let non-Dev check unit tests, this is a much simpler task for team Dev. But, realize that Devs work “underground” when they test at a low level. Think in terms of users living at the top, under the light, when Devs buried themselves in their own Spec details. Devs have difficulty seeing products from the perspective of Users.
While geography may be disastrous, it may also be quieter on a surface full of thunderstorms. Unit tests often allow for an overall look at inputs, and often there are not too many worrying input inputs. Entering the system at a higher level – interacting with the sub systems – still means that we are testing through controlled APIs or commands, instead of the graphical interfaces designed specifically for Interaction between hands and eyes. This is where the tools have a chance to shine. Think of test tools as submarines under attack, because the tools actually provide significant results if not operated through the GUI.
The circular Earth model reminds us of data
Data appearing in this model, figuratively, is the energy flow. The flow of energy on the surface (sunlight, wind and water) and even underground energy flows (groundwater, lava, earthquake). Data is extremely important. When we test, we face data that exists in databases and on micro-services, some cloud data. These are the data built into the code, automatically. So data is not user-type things or how they click buttons. It can be seen that unit-level and sub-system-level tests often ignore the size of the data, and this can be better reflected on the circular Earth concept.
The Round Earth model reminds us of testability
A complex product can be designed with testing while thinking. A test product is, in many functions, one of which can be decoupled (separate and test each module and this small function), can observe and control the behavior of modules , this function. This often requires allowing the tester to access more deeply into each part of the product via command-line interface (Or some APIs) and log back in a comprehensive way.
Satirical aspects
- The quality above requires less quality
- This quality reduces dependence on expensive high-level test models.
- An inexpensive low-level test model will reduce dependence on expensive high-level test models.
- Risks increase with users