Like many technologies, test automation comes with a lot of promise about what can “easily” be done. These tools generally take more effort than guaranteed during the sales presentation and typically yield less than desirable results, considering the time invested. The biggest reason for this problem is the disparity between what we’re told to use these tools for versus what their true capabilities are.
This is a perception I’d like to change.
Beyond Automating Tests and Test Cases
A number of years ago I was working for a large retail company in Plano, Texas. We developed a testing center of excellence and I was part of the test automation team. While we had developed dozens of automated testing solutions, it seemed our HP tool set was capable of so much more. Then an opportunity presented itself: An in-house project needed a number of transactions put through it on a regular basis. It dawned on me that we could use our test automation tool to perform the mindless task of entering dozens of transactions as needed for our development team. Because no validation was necessary, the automation was fairly quick to build and turned out to be extremely helpful. Additionally, it gave me a glimpse of what was possible if we simply removed the word test from test automation.
To read more on taking “test” out of test automation, click here.
If you are a software tester and have been in this field for a while then you might have run into situations (let me call them traps and hurdles) that limit your efficiency and effectiveness. It could be a common problem like not enough time and/or resources to finish testing or could be because you are surrounded by coworkers and colleagues who don’t realize the importance of your work. But if you’re like me who cannot work on projects and with people unless you have credibility, respect and their confidence in the work you do, then you must be aware of these pitfalls, mistakes, traps and hurdles that any tester can face in their life.
I started writing this blog when I began my software testing career (exactly 9 years from today) and I don’t know about you but I have run into plenty such software testing traps while working on various testing projects at various stages of my career. And every time I ran into them, it gave me a chance to look for magic spells, ways, methods, techniques, tricks, tips and anything and everything that could help me come out of such situations. And today’s article is a compilation of some of those top 5 traps that I’ve ever run into in my software testing career and some of the ways that helped me overcome them, in my context. The following case points and suggested solutions can help you overcome many common real-life software testing problems, read more here.
We don’t just live in the present world. ‘Counterfactuals’ are the ways we could have lived in the past, and all the ways the world could be in the future (‘the woulda-coulda-shouldas of life’). Scientists have thought it puzzling that humans would think about those alternate worlds rather than focusing on the present. Alison Gopnik has answered this and similar questions by studying small children . Rather than opposing concepts of fact/fiction, science/fantasy, ‘the same abilities that let children learn, allow them to imagine alternate worlds.’
“Children’s brains create causal theories of the world, maps of how the world works. And these theories allow children to envisage new possibilities, and to imagine and pretend that the world is different,” Gopnik explains.
Counterfactual thinking is an important part of our lives. In experiments psychologists have found that barely missing a flight has a greater impact on a person than missing a flight by a large margin. The evolutionary answer why this matters is that counterfactuals let us change our lives. Considering alternatives allows us to ‘intervene’ in the future.
To read more on how counterfactual testing relates to software testing, click here.
In this TechWell interview, Andreas Grabner explains why it’s best to test throughout the entire development process. He discusses the severe impact small changes can have on performance and scalability, as well as a few key metrics that will surprise software professionals.
Sticky Minds: Why do you think that people tend to ignore the impact small changes can have on performance and scalability?
Andreas: Developers like to build new features. Obviously, they’re on this big pressure to come out with new features more frequently. I think there’s still the thought, “Hey! In the end, there’s somebody who is testing my software anyway. I’d rather spend my time in focusing on what I’m paid for, that’s basically building new features and somebody later down the pipe will take care of load testing and then tell me if anything is wrong.”
To read more of Andreas’s responses, click here.