Have you ever talked to someone who’s not listening to you?
Just because you’re in the game doesn’t mean you’re playing the right one.
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).