Evolve, Adapt and Build

[This is also the editorial in the Automated Software Testing Magazine, August 09 Issue]
http://www.astmagazine.automatedtestinginstitute.com

For anything to survive, it must be able to change itself by three different ways: evolving, adapting and building. This has been evident in the natural world, and it also holds true in the world of software. This reality should be especially clear for software testers and test automators, because the very mission and reason for their existence is to ensure systems are effectively evolving, adapting and being built. This conceptual trilogy is not confined, however, to only the systems tested using automation, but also applies to test automation itself.

Evolution is defined as a gradual process in which something changes into a different and usually more complex or better form. This change is normally an innate response to some measured environmental stimulus that occurs over time. Adaptation is the act of adjusting oneself to different conditions or a shifting environment. This type of change is typically marked by a deliberate and direct response to immediate modification in the environment. Building is the act of increasing or strengthening, and may be a response to some outside stimulus, but it could also be done based on a self-imposed decision to improve one’s situation.

The discipline of test automation has experienced and been shaped by each of these modes of change in the past, and continue to be defined by them even today. Understanding these three modes of change will help to better understand the current state of test automation, and will therefore help us all to chart a course forward. Therefore, to aid in this understanding, this Automated Software Testing Magazine issue is, dedicated to exploring each of these modes of change.

In the cover story, Linda Hayes delivers what is possibly one of the greatest articles ever on the topic of the test automation evolution. Titled “The Evolution of Automated Software Testing”, this article looks at software test automation from a macroscopic point of view and explores the gradual changes in software systems over the years. It takes us through a trip down software computing memory lane, moving us from the mainframe domination to Internet domination, and explaining how the test automation discipline has responded to each evolutionary shift by moving from text capture/playback tools to the wide use of commercial automation frameworks. In addition, Hayes describes where the automation evolutionary approach has come up wanting, and proposes what the next test automation evolutionary response should be.

Next, J.L. Perlin provides a featured perspective on a modern day test automation adaptation with a peek into a project’s encounter with contemporary environmental changes. In this article, an existing software application with a substantial suite of automated tests is faced with proposed changes to existing application controls. These changes threaten to render all existing automated tests useless as the automated test tool contends with problem communicating with the new controls. This is a problem that many automators have come across, and if you haven’t, there is a good chance that you will. So J.L. Perlin offers an approach for effectively navigating your test automation through such modern day technological changes.

Finally, Dion Johnson chimes in on the third mode of change, defined by building up your test automation framework. This change mode has no particular catalyst, but is instead unprovoked, requiring implementation by a project looking to improve their test automation return-on-investment. Dion provides a step-by-step approach for building an automated test framework that will ultimately help to sustain multiple automated tests over an extended period of time, therefore helping your automated tests proactively keep pace with application changes.
These articles, along with the department articles (focused on keyword driver script development, open source tool contributions, and automation blogging), will help you understand present day test automation, and help us all define the next phase in automation evolutionary development.

Scripting Calisthenics

Test automation is like a resistance training workout program; the more you do, the better and stronger you get. The dilemma with test automation projects, however, is that they are very often fleeting. When a test cycle ends, test automation often doesn’t resume until much later after a stable version of the next release comes to the test team. Other times, a project or contract ends, and the next contract does not utilize your test automation skills at all. Either of these situations could have an automator away from the test automation keyboard for an extended, even indeterminate period of time, which presents a serious challenge. Anyone that is used to weight training knows that if you stop for an extended period of time, your muscles begin to atrophy or waste away. Then, if you later attempt to resume working out with the same weight or intensity that you previously enjoyed, you risk injuring yourself. The same applies to test automation. If you stop using your test automation skills for an extended period of time, they begin to atrophy. You forget basic scripting syntax and techniques, and if you try to restart a vigorous test automation effort, you risk getting injured. Injury in the automation arena is seen in the form of failed test automation implementation, loss of credibility, loss of confidence, increased stress due to overwhelming expectations, or even job loss.

When recessing from an extremely intense automation effort, the best thing to do is go into maintenance mode, to maintain the knowledge and skill that you’ve attained. To support you in your maintenance, this article defines a program of Automation Calisthenics. Calisthenics in physical training are exercises consisting of a variety of simple movements, usually performed without equipment or with limited equipment (pull-up bar, small dumbbells, etc.), that are intended to increase body strength and flexibility using the weight of one’s own body for resistance. This will allow you to remain in shape, and maintain the physical gains that you’ve made. In the world of test automation, calisthenics are simple exercises that allow automators to maintain the automation skills that have been acquired.

To read the complete Scripting Calisthenics article, download a copy of the May 2009 issue of the Automated Software Testing Magazine at http://www.astmagazine.automatedtestinginstitute.com/. It's free!

The Future of Software Testing

Recently there was a question on a networking site about the future of software testing. While this is definitely worthy of a long dissertation, here is an attempt to provide a brief summary in blog format...

One could say that we operate on a pendulum in software testing. The 90s saw a swing of the pendulum in the very structured/documented approach to testing, and when that became too cumbersome, software testing began swinging towards the more "agile", less structured direction. It seems that the momentum of this current swing is slowing a bit, however, as people begin to abuse the term "agile" and that the testing discipline will soon begin to swing back in the other direction again.

In the broader sense, however, the future of software testing is strongly linked to automated testing, and how we deal with that. Development is changing and getting more streamlined, and is therefore getting done much faster. Testing will rely on automation to help keep up. If we don't grow the discipline of test automation, however, it won't be able to keep up. Dion Johnson has written a few articles about this, including an column at stickyminds.com called "Automation Déjà Vu...Again!" Check it out. In addition, be on the lookout for a symposium that the Automated Testing Institute is planning that will address the topic of the future of test automation. If you'd like to be kept up to date on the developing symposium, you can get on the mailing list by emailing events@automatedtestinginstitute.com.

The Automation of Love

It is the month of February, and love is in the air, and in many ways, love and other matters of the heart are a great metaphor for what often happens in the world of software test automation.

Relationships often start out with such promise only to find out later that the promise doesn’t necessarily match the reality. This is also true for relationships between testers and test automation. Testers and their stakeholders begin test automation initiatives with such lofty goals of shortened testing cycles, reduced budgets, and one-click test execution. Very often, however, testing cycles and budgets are not reduced without an accompanied reduction in test coverage. And one-click test execution - a term often inferred to mean automated tests that always run perfectly with little monitoring, maintenance and analysis - is not achieved without significantly building the robustness of the test automation framework (which still probably won't result in complete one-click test execution). Testers and stakeholders are seldom prepared to make such concessions which puts a strain on an automation relationship built on such high hopes and unrealistic expectations.

Have any thoughts about the automation relationship? Add a comment.

Want to hear more about the automation relationship? Visit www.automatedtestinginstitute.com. You can also view the Valentine's Edition of the 'This Week In Automation' video series found at the ATI site, and on YouTube at http://www.youtube.com/watch?v=tzgemxbLWGw.