Monday, December 24, 2012

Transitioning from Traditional Testing to Agile Testing with Automation

09-09-2012

For those of us who began our testing careers awhile ago, let’s not put a number on it, we have perhaps worked in a variety of domains using a variety software development practices.  The most popular we used was perhaps some form of Waterfall.  However, regardless of the methodology at hand, serious software testing often proved to be a collage of scientific, philosophical, highly analytical, genealogical, research-oriented and statistical practices.  Some of us have even watched our once purely analytical approaches embrace a more technical approach with the popularity of test automation tools.
If we were honest with ourselves, we all knew waterfall or any modified version was not working for testers.  We were one of the final phases in the process and almost 100% of the time our pre-planned timelines were robbed by under-estimated planning and development times.  We were often like neglected children not being afforded any early attention to help us combat our forever shrinking timelines to perform our job properly.  Being the dedicated professionals we were, we continued to use practices from the traditional testing toolkit to do our job.

Now we have Agile which promotes the idea of having team spirit with non-testing professionals to build better software at a faster rate.  Admittedly, I was a traditional testing professional who became suffocated the more companies embraced the idea of immediately responding to customer demands and then being so-called Agile.  This is when I began to realize all of my test automation innovations would prove to be a valuable asset to support the agile software development phase we are now in.

I have often worked for small development companies where we were often a very tiny team of QA professionals with a ratio of 1 QA per 8 developers.  Test automation was a way of life for me and helped me to become agile prior to the methodology being introduced to the development world.  I realized investing and designing test automation frameworks, regardless of the tool, provided me with a reliable virtual tester.  I began to strategically expand my automation efforts over time so with each short release cycle now called sprints, the Virtual Tester could provide greater and more thorough regression test coverage which often saved us many times from releasing embarrassing mistakes.

As agile gained in popularity, I adopted TDD methods before I even learned there was a methodology to support it.  With a robust framework, one could develop functional test cases that now could validate the software met the business requirements.  The mentality changed from the automation script should find bugs to the code is not ready until the script can pass without fail.  This method allowed us to be very proactive in our test efforts and to further find innovative ways to streamline the test management process, the test development process and of course the test execution process.  Exploratory became a process to learn the ins and outs of a feature which flushed out the early bugs and allowed for us to design and develop testing methods.  The framework grew and matured year after year allowing us to always add new functionality, refactor old functionality because the maintenance had become quite minimal.  The innovations even allowed us to reuse the framework across multiple applications.

Then companies began to mature their agile practices.  They were growing from quasi-agile practices to pure agile practices (Dancing With Pigs, Timothy Krosnan).  For the first time in my career, I realized, I had to completely let go of the quasi-traditional toolkit I had been using and develop and adopt an agile testing toolkit.

As I said earlier, we learned the waterfall and its many variations were not working for testers.  All the iterative approaches failed testers and the testing process.  I had believed so much that I was ahead of the curve and then I realized I was and yet I wasn’t.  I was still trying to use antiquated practices which were impossible to implement and maintain in a pure agile team.  Furthermore, there wasn’t a lot of guidance out there on how to make the transition and how do we perform the important tasks we believe needed to be done in these short time blocks with a collaborative team.  The only true reference was Lisa Crispin’s Agile Testing book.  Being a tester who has worked with a variety of domains within a variety of industries, believe me when I say, you always have to learn to use a toolkit to build your own methods and practices that fit the industry, the company and the team you are working in.  So I began a new adventure to learning how to leverage techniques and tools to streamline the test management process and marry it to the test development and execution process.

Believe me the tools are there!  I know many of you are not technical QA but you must learn how to use them (or collaborate with those who can use them) in order to make the job possible.  We still need time to be analytical, to research, to develop statistics and to be philosophical.  So we need to eliminate and streamline as much of the waste as possible.  We have to learn to master these tools to capture and maintain only what we vitally need.  I remember talking with my brother about the difference in how men and women communicate.  His analogy was “men only require the headlines while women require the story under the headlines.”  Using this analogy, we need to learn to capture only the required headlines that allow us to completely communicate the plan, allow us to make it readable and visual and furthermore re-usable!  How many times have you invested the time and energy developing tedious, long drawn out test plans that no one reads or reuses!?

It is not easy retraining the mind to see outside the box.  It is not easy for all of us to develop the technical capabilities to implement some of the changes.  So we collaborate, we leverage development and we make it so our test management process works seamlessly with our test case development and execution processes.
Some of us working in industries who are required to report to external governing entities or collaborate with them to provide solutions, like the financial industry, well we still need those tedious documents.  However, I would challenge to find ways to eliminate the waste by learning how to better capture the information and reuse the information provided within them.  The technical world is growing and evolving again and we must never be shy to grow and evolve with it.

Happy Automation!

No comments:

Post a Comment