Most companies only focus on manual testing at the start. Down the road they jumping head first into UI automation. This might seem like the best approach, but focusing on just one area of testing can lead you down the wrong path.
There’s a downside to only having Manual & UI automated test. You end up with an anti-pattern called the Software Testing Ice Cream Cone.
I first heard about software testing ice cream cones during a talk that referenced a diagram from Alister Scotts blog Waitrmelon. The original diagrams are in his post, Introducing the software testing ice-cream cone (anti-pattern). Thought I would share here.
With a software testing ice cream cones, the majority of testing is done manually. UI automated test are a close second, integration test in the middle, with unit testing lagging behind completely. This is not scalable.
What you want to end up with is the complete opposite, the Pyramid.
So you don’t want ice cream cones (well not these kinds anyway). Ice cream cones are fleeting. They feel good just for the moment. They never last long enough.
You want to build pyramids. I’ve talked about an agile testing pyramid when building an agile testing framework. Though pyramids are much harder to build they’re strong and last a long time.
Please check out WatirMelon it’s a great blog with a lot of useful post about software testing.
A test automation framework is an application that allows you to write a series of test without worrying about the constraints of the underlying test tools.
It’s a set of protocols, rules, standards and guidelines that can be followed as a whole so you can leverage the benefits of the scaffolding provided by the framework.
They’re rules, standards and guidelines to make the life of your test team more enjoyable.
An automation framework is not a tool to perform a specific task, but rather an infrastructure that provides the solution where different tools can do their job in a unified manner. It’s an Automation Engineers common platform.
There are multiple Layers Of An Automation Framework. The part we are talking about now holds everything together. When someone says they help build automated test (like myself) they’re normally talking about this middle layer.
Want to handle UI changes with ease, write more tests in less time, lower impact, reduce the lines of code, keep test logic isolated, & up your frameworks reusability?
If so, check out the page object pattern, AKA the Page Object Model.
This design pattern is used by most companies to build their test automation framework.
Last week was my 1 year wedding anniversary (Yes I’m taken, sorry). Part of the wedding tradition here in the U.S. is eating the top layer of the wedding cake. It wasn’t half bad.
It got me thinking about the different layers of an automation framework.
I’m a little weird like that.