There was one concept from the video that I found interesting. The idea is that software that’s complicated to test can’t maintain quality.
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.
If you’re like me, one of the first things you do in the morning is check the results of the previous nights automated test runs. You site at your desk, cross your fingers, open up Jenkins, and hope to see a bunch of blue dots (PASS).
When a build fails it’s time to go into debugging mode. Automated test can fail for a lot of reasons. Sometimes just knowing what to look for can help you avoid the problem in the first place.
“So what would you say you do?” It’s a common question when meeting someone new. However I was blind sided by the timing of this question.
You see, I was on the phone with a recruiter who was fairly new to the game. We where going over my resume when I told here about a recent job and title change. That’s when the recruiter asked this haymaker of a question. I was stunned.
I went from working as a Software Test Engineer. Where I was doing only manually black-box testing. Then changing to a Software Development Engineer in Test, after they found out I could write code. The titles do share a lot of words in common but have huge differences.
Here’s what I should have told the recruiter.
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.