Should Testers Learn Automation?

 I have read various articles that debate this topic, but I never really have formed my own opinion.  The more I think about the future of testing, I conclude the answer is yes.  Testers should learn automation.

One of the most influential testers today is James Bach.  He knows code.  His brother admitted in an article recently that code is not is forte, but if pressed I bet he knows code.  Writing code might not be absolutely necessary to be a great tester, but I think it provides context.

I did a reflection on my career as a tester. 

Stan Taylor hired me at Excite@Home.  Stan gave me the start in the field and was a terrific mentor.  At first I learned how to set up multiple test environments, which gave me context about operating systems and browsers.  Next challenge was performance testing with Silk Performer.  I learned a proprietary language, 4Test and dabbled in regular expressions.  I was then able to extend the 4test language to functional testing, Silk Test.  The next phase was interesting when I got moved to a development team to do UI work.  Sad part is again I learned a proprietary language called Dynamic Content Generation, DCG.   My current boss, Jack Yang, was my development mentor.  He educated me on development basics: loops, logical statements, repository branching, tagging, & command line executions.  He gave me coding assignments that would challenge my skills, pushing me beyond my comfort zone.  Soon I was making production ready changes.

Next job was at a start up again with Stan Taylor.  Stan had built a beautiful JavaScript library and leveraged Webload for functional test execution.  Not only did I learn JavaScript, but also refactoring and reusable methods became important.  Code reviews and collaboration were great practices.  One important lesson to share about this experience was it was the first time I got to do “white box” testing.  I got to pair with developers and inspect java code. I was permitted to make suggestions on how to enhance the unit tests.  The ability for me to understand code structure made this possible.

Next adventure I got to learn some sound testing processes with a company that build complex telecom oriented software.  Guy Lipof and Joseph Griffin leveraged efficient testing techniques and I was exposed to collaborative testing in the form of test fests..  Eventually I ended up leading seven remote testers.  All of the testing was manual and it took the eight of us five business days to execute 1500 regression tests.  I came into work one day and I was informed that we had to let the seven testers go for budgetary reasons.  Holy cow, this is a great team how can I regression test this by myself.  We are talking eight weeks of busting hump.  The conclusion was automation.  I turned to WATIR and ruby.  WATIR Library was very education friendly.  The forums and people were amazing.  The result was in one month I had automated 70% of the existing tests, tossed out 20%, and the remaining tests were manual.  In the end I could do the complete regression plus test new features in five business days.  Was it the prettiest code in the world?  It definitely was not.  I was able to refactor some common methods and modules.  I attended AWTA(2007) where I met an amazing group of testers.  I met Brett Pettichord, Paul Rogers, Elisabeth Hendrickson, Brian Marick, Chris McMahon, Charley Baker, Andy Tinkham, Bob Cotton, Jim Mathews and many more great testing minds.  It was at this conference I learned the power of pair programming and collaborative thinking.  I was inspired to learn more by all of these people sharing their expertise.

In 2009, I moved to my current company.  The mission was to help set up an automation framework.  We settled on Ruby, because it was the language I was most comfortable with and there were tons of examples available.  We selected Selenium for the potential of cross-browser automation.  Building out automation is definitely a fun adventure from my point of view.  Some things I learned during this adventure were paired programming, factory patterns, page object patterns, mocks, and test driven development.

Now as a Director of Testing, I do not find myself writing much code.  Recently I recognized how valuable this journey has been.  I also learned that if you do not practice you get left behind a bit.  So I am now trying to learn some new aspects of software development during my copious spare time.

I did not share this short journey to highlight myself.  I wanted to share the experiences because I think some aspects of this journey are important to learning as a tester to constantly improve.  So my message to any tester that happens to stumble on this blog post.  Reach for the stars and add an understanding of code to your tool kit.  The majority of the lessons are at your fingertips free or at a very low cost.  You never know what you might learn reviewing someone else’s code and once others review your code you learn even more.

Happy Testing!