Naturally, test automation has come to the Software Development world from the need of saving time, money and the precious energy of the people executing over and over again countless hours of the same test scripts. As testers were thought to think like clients, like the end user, this came out to be reflecting into how this quality artifacts were actually designed and, finally, executed.
Are we really 100% automated?
Fast-forwarding that into the test automation era, we can see that most organizations think about automation in the exact same way that they were thinking about manual tests. Don’t get me wrong, any test automation is for sure much better than none. However, by just thinking like the client when automating our test scripts, we have outsourced the clicking part to the machines and have traded this off for more manual work in terms of maintenance, error investigation, execution coordination or fixing configuration. This has made us more technical, but it hasn’t reflected in the way we do our automation. At some point, the world already started to challenge this approach, and the famous Test Pyramid popped out. Finally, the future looked brighter: not everything needs to be executed like the client would do.
Beyond the Pyramid of Test
The benefits of the Test Pyramid have been seen quite fast by developers and QAs, but the concept it is still struggling in many organizations to prove itself in front of Business people, which has continued to believe and support just monolithic, all-in-one, complete End-to-End (or beyond :P) test automation solutions. In the last years, that situation thus has improved, the Pyramid becoming more and more reflected in the realities of many products because of the Business desire to go live faster. However, we are still expected to deliver most of our automation thinking like a client, which still keeps us with the same struggles of manual test: time, costs and your precious energy. We need to go beyond the Pyramid of Test at a system level, otherwise we will still be slow. Here’s why.
The Classical Approach
Let’s say we’re working on the development of a multi-component software solution, and we need to design how our test automation would look like. We’ll respect the layered approach of Martin Fowler, selecting just a couple of scenarios for the E2E layer. In our minds we’re creating a “risk-free” small test artifact, but with all the disadvantages of the previous approaches, which is not fast enough.
The Test Pipeline of Trust
Drawing this as simple as possible: given we’re respecting the pyramid in all of our components, why not divide & conquer? Each one of them has its own End-to-End, starting with an input from the client component, and ending up with receiving an answer from the component providing a specific service. Like this we’re:
- Decoupling even more the dependencies between different components, achieving even greener test results
- Removing redundancies and duplicated tests between layers, giving an extra boost of efficiency
- Leaving the earlier layers of the pyramid do even more heavy lifting, testing way earlier and receiving earlier feedback
- Opening up for test parallelization, removing the sequentiality of the classical approach and receiving faster test outcomes
We build a relationship based on trust by successfully applying the test pyramid for all of the components in our architecture.
Conclusion
Today, it’s not enough anymore for us to just think like our customers, we need to think also like developers. We need architect our testing artifacts to fit best the technical realities of our project for fast delivery, and involve business in the process to raise their understanding of the positive impact this has over their product.
How would you choose to design and architect your test automation artifacts to ensure a fast (and also low-risk) delivery?