Verify the World

I am a self-taught automation engineer for a major privately-held web company.  When I joined the organization, it was as a manual tester.  We had an automation engineer with one foot in the development department.  His automation framework was a custom mish-mash of C# and Java.  Code was duplicated everywhere.  Many of the tests (for a web application, mind you) were reliant on the specific [X,Y] coordinates of a link, button, etc.   Only one test would run at a time, and all input data was hard-coded.   Put simply, it was a mess.   When our lone automation engineer left for greener pastures, with no one who could maintain, read, or even execute his framework, we found ourselves releasing software riddled with issues that just didn’t come out in testing..

QA had very close and amicable ties to the developers, but often found ourselves speaking the language of the users, unable to translate to the language of the engineers (Java), so I went ahead and learned Java and design patterns.  They’d written unit tests using JUnit that were apparently run with every build, so I learned JUnit.  All that was fine, but QA’s testing was still being done manually, and often ad-hoc!

While hiring for automation and performance test engineers, I noticed a pattern in the resumes I received: the vast majority of candidates out there work almost exclusively in drag-and-drop tools like Quick Test Pro and LoadRunner.  These tools are prohibitively expensive, inflexible, and, frankly, serve mostly to separate the engineer from the code under test!  Frustrated by the lack of passion and quality in the resumes coming in, I pulled the postings from the job boards, and began an effort to bring this QA department up to modern using exclusively open-source tools.

It seemed like a good idea at the time.  It certainly didn’t seem like I’d be tripling my technical library and dedicating my nights and weekends to all the base topics I’d need even to get started! I’ve been endeavoring to build the entire system utilizing the same technologies as our development team, so that it can integrate most seamlessly with our continuous integration (CruiseControl) and deployment tools (Ant & Maven).  I’ve taught myself Perl, JDBC, XHTML & CSS, JavaScript, XML, SAX, DOM, TestNG(parallelism!), Selenium (IDE, RC, and Grid), JMeter, CVS, SVN, and git.

My new test automation framework is cranking out hundreds of tests in parallel and really helping the development cycle.   The tests are flexible to changes in the UI or in the activity flow.  Input data is validated against the database… it’s a beautiful thing.  The framework, though operable, is still far from complete.  Do I know everything?  Am I finished learning?  Are my opinions as good as law?  No!  Not by a long shot!  However, the true value of a project like this is that it never has to be finished.  You can always keep learning.

I urge my readers (both of you) to go open-source, become active in user communities, contribute where you can; be it in the reporting of bugs or the fixing of them, and to never ever let good knowledge go un-spread.

Reblog this post [with Zemanta]