Have you ever thought about how much work your automated test actually help you do?
I mean real honest work. Don’t worry if it’s low, because for most teams it is. There can be a lot of waste in the automation creation process. Creating unnecessary automated test cases is a huge waste for Test teams. Multiple scripts that test the same thing, for example…
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.
What’s A Software Testing Ice Cream Cone
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 Is The Better Approach
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.
On September 9, 1947 the first instance of an actual computer but was found.
At 3:45 p.m., Grace Murray Hopper records the first computer bug in her log book as she worked on the Harvard Mark II. The problem was traced to a moth stuck between a relay in the machine, which Hopper duly taped into the Mark II’s log book with the explanation: “First actual case of bug being found.”
That’s over 65 years ago. Since then all kinds of problems have been found in computer hardware. The term bug continued to be used. With time it’s also transferred over to computer software. Now we call almost any mistake in any process a bug. Thankfully, I’ve never literally found a bug in software that I’ve ever tested (though I’m still looking).
Today I want to talk about 6 things you should do after finding a bug (the normal kind).
This is the final post in the types of software testing series. You can view the other 40 types of software testing in the following post: 20 Types of Software Testing, and 2o More Types Of Software Testing.
“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.
What do you do when you’re job is to break things.
To find the weakness in something and then point them out.
To push back on work that others believe is finished.
To be the voice for the customer, an evangelist.To be a skeptic and highly critical, never being brain washed by the hype. Being a tester means that you have to weigh both sides.
If being in software development was a movie role than sometimes it would feels like testers are both the hero and the villain.
In a previous post we talked about the 8 Benefits of a Test Automation Framework.
Now that you’re convinced that having a test automation framework is a good idea, today we’re going to cover the techniques you can use to build one.