From the dark ages, to test automation

Some days inspiration comes so thick that all your ideas begin to stick together in one melding like pancakes with butter, maple syrup, and strawberries.  What follows is a second post, that begin inside my earlier posting: Where in the world are all the software testers?  So if some ideas from that post are also found mixed in here, that is why, but I did my best to refactor my initially 2,500 some odd words from the initial post to create what I feel are two very distinct posts.  While the first one is my thinking about Alan Pages blog on forward thinking, this one is a bit of an experience report, all be it a bit of a history about my first experience in software, and a bit about some of my more recent challenges.  I describe the trial of working with out a source code repository, and even describe some of my frustrations at having to build using clearly out dated technology.  Sometimes it is hard to realize how valuable any given tool is, unless you have ever had to try to work on a project without that tool.  This is where I began, and to forget how I first tread foot into the industry, would be to forget how far I've come, how much I've learned, and how much more there is to learn and do...


When I first started in Software, testing was seen as something I did when the time and necessity called for it.  Though initially I was hired as an integration developer, focusing on piecing module code from one place into another in the stable product line, testing was something that seemed as if it was just part of the job, but not necessarily the most important.  Maybe its the way software engineering is glamorized in the courses I took at WVU, I'm really not sure; nevertheless, as I began to grow understanding around the product, its structure, and purpose, It was not long before I found myself in a "Test First, Test Often" mindset.  

The reality of my first professional Job seems almost barbaric compared to recent projects I worked on.  There was no source code repository, no Visual Source Safe, Subversion, or CVS in general use, so this meant that when new modules were being developed they were always in what was deemed as the last stable development build.  Many times the build that the features were added to comprised a number of new features and bug fixes, so the porting of that code had to be done laboriously by hand.  If I had not been so green as a Developer at the time, and had scene the value of source code repositories before my professional time, maybe we could have changed how things worked.

In any case, it was my job to kick the tires on these features by porting them into the latest and greatest build, and then seeing what the new additions actually did.  Suffice it to say, I highly recommend a source code repository for projects, especially when you have people working remotely or on different sites.  However, this was the situation I found myself in as a young software practitioner.   Finding all the right bits of code, initially was not easy.  Sometimes I would get complete source, and have to scour every class for changes (And really, with little background on the project before, It is quite possible some of those changes had been changed not by that module, but in previous bug fixes in the new build.)  So I began pushing back to have some way of seeing and marking what areas they had changed, so I could focus there, and not on other parts of the code.  The wrap around comment with tags for each module became the first thing I searched for when integrating.

That's how the process was initially described to me, so that's how I went about my tasks early in that assignment.  This turned out to be a harder more time consuming method though.  With developers deployed overseas, sometimes on different operating system setups, even the code they wrote that worked on their systems did not always work correctly on hours.  Were these Regression errors that crept in as features kept being added?  Or were these simply the result of the different platforms we were using?  To this day I am still not certain, but the obvious solution came that we began requiring a demonstration build of each feature.  First it would allow us to see if the build actually worked on our production systems which were perhaps closer to what our customers actually used, and secondly it would also allow us to see whether the feature worked as expected before putting the time consuming 'monkey work' of copying code A to class B.    So I found myself doing about 50% more testing than actual clerical/coding work on our project, and found a lot of bugs in the process.  Suffice it to say, I look back on those first steps as very raw, hard ones in my development professionally, and am thankful that I have learned and moved beyond such outdated techniques.

So it has been just over five years that I have been on this latest assignment, and one area that I have found myself thrust into has been testing.  What others on our team realized, though I couldn't see it from my eagerness to help out the team in any way, was that I was actually a pretty good tester.  I'm not sure where this skill, or perceived confidence in me as a tester came from, but as a Colleague said to me just this past week, "He's a testing Wiz."  I smiled and accepted the compliment graciously, but deep down, while others think I have it all figured out, I know that I have a long way to go before I consider myself to be any kind of expert, at Testing or Software Development.   Truthfully I wonder if it is even possible to be an expert in anything software related given how fast the state of the art moves in some areas.

So what does this have to do about forward thinking?  Before the last year I had not seen myself as a tester, just a software developer, eager of doing whatever the team required to succeed on our projects.  I stepped up to an offering of a different role as a developer of test automation, and also testing in general, and I embraced the chance to learn and do something new.  I did so not enter this assignment knowing how long I would be kept on the project, and I did so, having done perhaps more coding work than actual testing on recent assignments, but I didn't let that stop me.  As I had recently learned from the classic book from Spencer Johnson, M.D. "Who Moved My Cheese?" to not only anticipate change, but to embrace it, and relish it, I plunged into what initially seemed like a rather dull engagement, and not to mention highly time consuming, but I could see why they needed someone to focus on test automation, it just frankly took too much time to have the regular testers doing it.  

So I embraced the change, challenge, and at times boredom of test automation, and learned how to string together tests in a version of the test tool we used.  While I looked for and anticipated change, I had set my mind to get 'comfortable' in performing these tasks the way they were demonstrated to me.  I didn't know at that time that anyone else had tried and given up on the effort in the past, nor did I have any prior experience or research to back me up in finding a better way, but it was a start.

As I pushed forward through these challenges, I took time when I could to research the certain unique problems I encountered along the way, and at some point I stumbled onto a blog.  I don't recall which blog it was that I first read, but I began reading this blog and using the challenges to learn more about testing in general.  Then one blog linked to another, Google Reader began suggest some other similar blogs, and suddenly a new world of testing was open to me, and as I learned, read, and absorbed new ideas, and techniques, and it transformed my understanding and view of the field.

Now I am engaged on a new project, one where I am not constrained to a particular tool set, rather constrained to doing the best job I can in testing the application to find bugs, to learn, and to apply as never before new found technology.  Some of my tasks have afforded me the chance and need to develop a test harness, utilizing both C# and Selenium.  Perhaps later I shall try to bring some examples of the generic process  I went through to create and build a test harness for some of the automation tasks that make sense for this project.  For now, it feels good to no longer be back in the dark ages, but to be in the present ever living moment, applying new ideas as I encounter them, learning and building both my knowledge, as well as wisdom on when and where to use certain testing ideas.