Paul Grizzaffi is a conference veteran and makes his way to the stage now.
(loving the standing ovation for every presenter btw)
Adviceā¦ writing your own framework. Donāt. (seriouslyā¦ donāt) Butā¦ if you have to, how to stack the deck to succeed is what this talk is all about. That and also, treat your automation stack as a product and as software. Not a tool.
So I just learned that Paul is from Louisiana. I need to pay more attention to my friends. Okay, back to his talk. He is walking us through some context about how he built an automation infrastructure for a telcom company (omg I am so happy I am out of that space). This was 1994, and no real alternatives to building a testing framework was available.
Dotcom bubble burst and so did this company. Paul then headed to an e-commerce company. Found himself building a similar stack. I will be honest, this is a story that needs watching. Paul is a wonderful story teller and am butchering his path here. I will pick up when he gets to his learnings
And I am back.
Conceptual Stack. What is this?
- Script - How we push this through and structure it for logical meaning
- Behaviours - Reusable groups of actions. (eg. log me in)
- Actions - These are domain specific. The actions we intend to use and check within our area of focus
- Abstraction/Encapsulation - provides protection to the upper layers from changes in the lower layers
- Raw Tools - often the tools we build upon that we purchase
This conceptual stack is a maintenance control activity. By using this as a mental model for how you design your test stack and organize within, it can help build a strategy designed with dramatic change and flux expected and anticipated. Paul makes it clear that this is not just for UI and his main point is that a stack is far more resilient and reusable than a framework.
Note: Some things to consider. Each layer in a stack needs to log and considerable design needs to consider how to plan these to be complimentary and appropriate. Also know that building a stack requires proper stewardship that the right things go in the right layers and needs to be treated as an appropriate software project, or your stack becomes a house of cards.
General guidance: Abstractions and Raw tools can be used/reused across product lines. Script/Behaviours/Actions are domain specific, but differ in granularity.
Also, remember, thinking about this as a software project. Every line of code YOU write is a line of code you should be testing and maintaining.
