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.

Where in the world are all the Software Testers?

One of the blogs I read on a regular basis is Alan Page's Tooth of the Weasel Blog.  Recently I have been particularly engaged in thought on the question of forward thinking as it relates to software testing.  There have been discussions on Twitter recently about just these sorts of things, and as Alan wonders on his blog entry Careers In Test:  "What are the new ideas in testing? What is our role in the future of quality software? How do we advance the state of the art in testing?"

These are interesting questions, and initially a lot of this discussion focused on some of the concepts other authors have been writing about for years. The problem seems that in many places testing doesn't has the appearance that it hasn't changed, that it isn't any different than it was twenty years ago.   Now I have only been in the technical field of software professionally for about eight or nine years now, so I do not have much first hand experience to go on about what was the common practices in testing fifteen or twenty years ago.   However, I have been able to get a peak back by reading every morsel I could get my mind's fork into as I gobble up old software test articles, or books written that give some shading and hue to the background of the field I now find myself thoroughly engaged.

Once upon a time, testing was just one sliver of what I did in my role on a software project, but now testing is very much a key and important part of everything I do, for it is by testing that we learn about the projects that we build.  Which brings me back to Alan Page's recent entry.  Where are the forward thinkers? I don't know if I qualify as a forward thinker just yet, but I am certainly more aware and active in my role in testing than I was before.  But Alan raises an interesting question, why don't we see more Forward thinkers.  I personally believe they are out there, but where I could not guess, and there certainly are some forward thinking minds that are now practically famous in the testing community now, too many for me to list them by name.  However, it got me to thinking about why things may have been different twenty years ago and one word came into my head:  the net.  

Twenty years ago even dial up service was hard to find in some areas, and the so-called "Information Super Highway" had not yet materialized as a tangible valuable asset that it now is today.  When I think about testing, and the norms of any work place, I can't help but picture that many are just working in their current area to earn a buck, to put food on the table, to continue to exist with some level of lifestyle familiar unto them. 

I find that many people are developers or testers by day, but by night they put off that cloak and become something else, a husband, a wife, a father, a mother, a friend, a sportsman, a couch potato, a bachelor, whatever.  Many of these people are very bright in technical areas, and people I hold a great deal of respect for.  I imagine there are many Joe or Melissa, average testers out there striving to make their little corner of the software world cleaner, like a broom trying to get the last few kernels out of a corner.  So I found myself this morning commenting on Alan's blog and found inspiration for my first Blog of December.  (Thanks Alan!)  So here is the crust of what my thinking was this morning: my original comment is here.

After writing some more this morning I had more thoughts on this, so I'd like to even take it one step further than that, to issue a challenge to my fellow testers out there, some may have already done this, but earlier in the year I put out a question on twitter for any testing societies within my home state.  As of right now, there are none, none that I can find, so this is something of a troubling thing for me.  One of my hopes, and goals should I continue to do as I have here in West Virginia is to find a way to establish a community of testers either within just my corner of southern West Virginia or perhaps the entire state.  The problem is how to start it.

The first is to reach out to testers that you know.  On my hand, I can think of four people at work who are testers on other projects, and there may be others.  The challenge I think is to find a way to network with those we know, those we may come in contact them, and invite them into this world that is growing online.  My challenge is this, what can you as a Tester do to grow our reach as a community?  I challenge you to invite one person, one possible tester into this world.  Invite them to check out at least one part of our growing community.  Whether it is the articles and blogs on Software Test Pro or show them the site for the Association of Software Testing.  Link them to blogs and sites for other testers like Michael Bolton, Lanette Creamer, James and Jon Bach, Matt Heusser, Alan Page, or maybe some other site or part of our community.  Let's do our part to build the community of testing up, and through that maybe we may find out where in the World are All the Software testers?

Edit:

(I forgot to link to Alan Page's Blog post, Thanks Michael Bolton for catching me on that, I will try to do better on my citations in the future.)