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.