Monday, December 24, 2012

Evolution of an Automated Tester

10-29-2012

Everything was so brand new to me.  Quality Assurance, testing and using tools to help run our tests.  The tool was called QA Partner and it proved quite difficult to figure out without training or proper time allocated to truly understand the tool’s potential.  I didn’t choose this tool.  It was thrusted upon me by my supervisor.   So I reviewed project requirements, the technical and conceptual specifications and any other information that would help me in the test effort.  I planned the test effort and wrote the test cases.  Then I recorded my actions as I executed my test.  I would multitask between executing/recording my tests and reporting any bugs I discovered.   When I tried to playback the scripts, they often failed during playback with the same build!  The playback was even worse when I got a new build.   It was so frustrating!  I was constantly creating and recreating scripts to the point I abandoned the effort.


With the test demand growing and having the opportunity to work with a developer, I braved using an automated test tool again.  This time, I learned how to identify objects more cleverly, wrap native methods to make them more robust and resilient, and utilize data driven techniques so we could reuse test functions.  This technique gave me improved regression tests but still, I spent a lot of time maintaining it and I still had a lot of other test-related tasks that were time consuming.  It didn’t matter if I used MS Test, QA Partner or WinRunner.

Then I began working with FX Trading applications.  Modified record and playback was no longer sufficient!  I required a test automation solution that required less maintenance, more resilient, support more than one application AND configurable.  I developed RATS which stood for Rapid Application Test System.  I was also trying to be humorous :).  My recorded scripts evolved into a TestFramework.  I spent tireless days breaking SilkTest’s testing strategy so it could allow me to configure a test run using a configured Excel spreadsheet and macros.  Record test cases as comma-delimited Excel files and a Framework that supported BDD methods which meant I could create as many positive and negative test cases as I desired to support an application feature.  This framework supported us for more than eight years and became a solution where with a simple configuration and a click of a button it would test any one of our trading applications, on any selected test machine, testing for static and real time rate changes, T+3 trading dates and as many permutations we could think of for each trade type.  Best of all, it evolved into a solution that required minimal maintenance and very easy to mature to support new functionality.


Now a new challenge came when I began at a new company.  A budget did not exist for expensive automated tools.  Bye bye SilkTest.  The mobile and wireless management system we were testing was a browser based client server application with a web service api.  So we went open source.  Using the same automation methodology that was used with SilkTest, I had to re-engineer the framework now using Actiwate with javascript and life was good until our products changed forcing us to upgrade our open source tool but no Actiwate upgrade existed.  So I was forced to learn Selenium.  Selenium introduced us to the developer’s world of using IntelliJ to write Java code and manage it using Subversion.  I advanced the test case data capture to completely replace defining tests using MS Word.  I added a reporting component that collected the results and list the steps that caused a failure.


Selenium introduced a world of opportunities.  My mind had been freed to see test automation as a solution to support both the tester as well as the defined test approach.  I had learned I could use test automation to support:
  • Advanced test automation configuration
  • Test case data management using a TestManagement or ALM
  • Test start up and tear down
  • Baseline management
  • Test dependency management
  • Test Results collection and management
  • Automatic bug reporting
  • Support various test types
  • Tracibility and reporting management
  • Leveraging maven to manage external dependencies to our java project
  • And the list went on as new and greater challenges presented themselves
Automation became the tester’s tool to help expand the horizons of normal manual testing and planning.  It doesn’t matter if it is a tester automating or a developer testing the reality is right now, technology demands we test better and faster so we must innovate methods, tools and solutions that will allow us to do this very thing we strive to do.  Deliver quality products.

Happy Automation!

No comments:

Post a Comment