Stepping in the shadow of a monument of process, or standing up?

Somewhere in an old and run down railroad boom town, stands a hundred churches.  Most of the churches were built nearly a century before the Americans with Disabilities Act was even contemplated on the floors of the US Congress.  Some have been updated with ramps or elevators, but most like this one old red brick church have only concrete stairs that lead up and into the hall where the people meet each Sunday morning.  Every Sunday a hundred people or more, women, men, children, and elderly walk up those old concrete steps before that service begins and then, retreats back down those stairs again after the service has concluded.

On this particular Sunday morning, many feet trod up and down those stairs. Each pair of feet appear only conscious of their forward motion, an attempt to keep things moving forward, progress, a process.   So one step after another and soon they reach the destination on another iteration of that Sunday morning hour or more of fellowship and learning.  These little feet may be blissfully unaware, or perhaps they know all too well  that the church is a hundred years old, and has stood tall for longer than those feet have been able to move.  Furthermore, it might seem to those feet, as the creep up those stairs in the shadow of that hundred year old steeple that those feet will continue to visit the same pattern of stairs until the trip can no longer be made.

Of course, then there will be other feet will take its place, and as many feet will continue this pattern to mark up and down those stairs, with their purpose focused on the zenith  where the door opens into the terrace of worship.  So common and repetitive might this routine become that these feet may pay little attention to anything except to each footfall after footfall.  While the conditions of the stairway may sometimes be traveled in the dry, the wet, or perhaps with salt or kitty litter spread about to enhance traction when snow or ice threaten the weekly ascent, but always these feet work their way upward, looking towards the doorway at the top, and yet despite the variety caused by the cycle of seasons, still these feet remain oblivious, giving less and less attention to the grind, the steps each foot falls upon as the habit of the process over takes the analysis and observation that once, during those first few trips up and down those stairs, where the mind noticed the grade, the hardness, and sound of those foot falls on their ascent.

Yet then one Sunday Morning, a half hour before the celebration of this years Scout Sunday a lone boy finds his way up these stairs.  He has walked these stairs before, but it has been months since he last made that climb.  While others around him may feel this is nothing but a normal routine, he takes in the moment, the smell of the cold snowy air, the feel of the chill wind against his cheeks, and the sound of each footfall as he climbs step by step, turning at its half way point to the side, and then up one more step to the doorway. That's when his senses detect it.  A sound altogether different from the sounds of all the previous steps he has heard ring out.

The sound catches his attention, and he lingers for a moment on that step, noting that it is different, but not so sure about it, he opens the door and enters the old church.   Others behind walk up the same step, and not one notices, or comments on the sound he heard as he stands back from the doorway and ponders, waiting for the latest bunch of congregational attendants to finish their ascent.   This boy doesn't attend this church regularly, he goes to another church nearby and across town.  He was only visiting on this occasion in support of the church that had graciously helped support his Cub Scout unit.  Yet a question forms in his mind, unlike all the other habitual comers and goers, going through the usual and traditional process of that weeks iteration that raises his curiosity.

Off on the trail of testing, but wait, I forgot this one thing

How many times in life, do we surrender to the habitual nature of our human psyche?  Do we capitulate and allow what seems to be an established routine, repetitive task, and in our minds we've got it down to an art, so why just flip a button, and cruise on through each step of the process, without giving much time to pause between steps to evaluate where we are going?

News flash, tester or not, we all do this! In fact, I did it twice today, without even realizing it.  Oh I wasn't 'testing' software at the time, but I allowed my inferred conviction of my own understanding of the early day's chores to not only lull me into a state of numbness, but introduced my own sort of performance speed bump that wasted hours of my time.

What started out today, as an early morning jaunt to accomplish to simple chore, turned into an exercise to remind me why falling into the assumption and autopilot trap are so dangerous.  It started simply enough, just two chores and then I'd be home for the rest of the day, became an afternoon of back tracking, acknowledging a flaw in my own understanding, correcting it, and then executing essentially the same process, but in a slightly varied way.   It started with a trip to the court house.

I was rather pleased with myself, because I thought I could complete two tasks in one visit.  I might have even boasted internally, that I was a genius to take care of these two tasks at the same time.  The first task, was to renew my license registration, at the Sherrif's office to bring my license plate current, and get the sticker to indicate to any law enforcement officer that might be checking my progress, that yes, I had paid my taxes and fees, and was not violating the registration laws for operating a vehicle in our state.

The second task, is one that maybe no one else will have experienced, but it required a trip to the County Clerk's office.  You see, as a member of our community at larger, I stepped up back in 2006 to serve the community as a Poll worker for a number of different election cycles within our county.  I do this as a service, because to be honest, the rate they pay for thirteen hours of open poll service, almost two additional hours of setup and tear down, is not a pay rate I'd accept for any of the professional work I do.   However, as a concerned member of my community, an Eagle Scout, and a person of faith, I value the integrity of elections, and believe that doing so is an important part in ensuring our elections are fair.   In order to participate after being selected, I have to fill out, sign, and return a form to the clerk's office. It was this task that I desired to complete today, because I had delayed sending it in earlier, due to uncertainty with my current job situation, and did not want to commit if I felt in good conscience that I would not be able to serve.

Those were the first two tasks of the day.  I stepped out the door with the letter in hand, and my registration as well, and drove to the court house.  I was pleased because I found a parking meter open within an easy walk, exited my car, added some time to the meter, and off I went, and that's when the first error dawned on me.  I had my insurance statement, the registration, and the signed form for the Clerk, but a nagging thing in the back of mind then came into focus.  'Does the Sheriff's office take check cards, for payment?'  Why I didn't ask this question before I left for the court house is unknown, but it proved to be the pivotal question, because they in fact did not take it.  I asked the Sheriff's Clerks whether they accepted it as a form of payment, knowing already in my mind that the answer was probably no, and received the confirmation that, no, they only accepted, cash, check, or potentially a money order.  I didn't have any of those options on my person, and truthfully I don't usually carry a check book with me unless I know I need it.

Now after reflecting I realize I could have potentially, walked over to the post office, paid the fee for a money order and then did it that way, but I'd have no record, no good one in my register to verify when it was paid.  So the first task of the day, I struck out.   I went ahead down to the County Clerk's office, handed the form to one of the workers, asked if it was yes, (it was), and was happy that I had at least one task done.   I would have to return home, find our only check book and return to complete the initial first part of the plan.

Have you as a tester ever started working through a problem, you jumped to some assumptions, maybe you feel they are good ideas about how it in theory should work in your own mind's eye, and proceed to work through the process of massaging through the interface.  Ever stop at some point to realize, you know, I wonder what would happen if I had done something differently that previous step, only to find that hitting the back button on your browser really isn't a good way to check this new test idea?  It happens to the best of us.  Sometimes a test that would make more sense to apply first, isn't, and has to be run again at the start of another iteration through the process.  That can seem frustrating, but it is part of the learning experience we go through as testers.


Well, this did not just happen to me once, it happened twice.  See I was also looking for information about a repair on my car.  I traveled to the mechanic's garage I have grown to trust, and proceeded to inquire about an estimate on how they might do it, how long it would take, and at what cost.   Surprisingly, they told me they couldn't do this kind of repair.  They had an idea of how the repair could be done, but there was something particular about my engine that required something that they lacked, something that did not give them confidence they could complete the repair in a timely fashion.

What a bummer that was.  However, I countered with a question.  "Okay, if you can't perform the repair, as I understand it, then is there another shop who you might recommend to perform this fix?  I know its not a critical issue on my car, but I would like to get this fixed just as soon as humanly possible."   They gave me a name of another shop, and I then asked, if they thought simply calling them would be enough to get an estimate.  They didn't really know, but suggested that maybe that would work, and it would save myself some money on gas driving out there unnecessarily.  I liked that idea, and returned home to eat lunch with my family.

After lunch, I began looking for the phone number of the shop, first in a few paper phone books, then turned to google, and superpages, but could not find it.  I found other shops, but not this one.  So later this afternoon, I hopped in my car, and drove out to where the shop was (having received directions earlier).  In hindsight, I wish I had pressed for a contact number before I left the first shop, but I honestly  didn't believe that finding it would be that much of a hassle.  That was my mistake, and yet another lesson learned.  

Ever start testing a piece of software, and then at some point just  stop because a question comes to the forefront, that you almost feel, man I wish I had asked that before I started?  Sure, it happens, maybe more often than we like.  We are creatures that learn and grow, and as Testers, we are many times going to develop ruts and habits.  Try to break those habits from time to time, maybe you'll discover a new way to flex the software, to bend and contort it to find a brand new class of defects.

Ultimately, we must try our best to avoid jumping to assumptions.  Never assume you already know the answer, if you've never even asked the question.  Never assume that the developer obviously must have done something a particular way if you've never had a conversation about it, and never assume that you've brought and used the right tool for a type of test.   Now this does not mean that we can never make assumptions, if we do, we need to realize that our testing is based on certain assumptions, maybe its a platform they are running on, or a particular style of device, that may be an educated enough of a guess to allow us to proceed, but we should remember that they are fallible assumptions, and present that as part of our test story when the time comes.

However, today's experience reminds me of something from earlier in my life.  It's funny in a way, since college, my first rule of life has always been to avoid making assumptions.  This was even before I considered, or even had a clue at all what it meant to test anything.   Western's Rule #1: "Assume nothing, for when you assume, you are usually wrong!"  At least that's how I wrote it as a freshman in college.  Today I'd transform that rule to read more like this.  "Make no assumption absent evidence, for assumptions are often based on illusions, that when that illusion is removed or proven false this can result in a great embarrassment to you in life."   Honestly, it isn't that our assumptions are wrong, or that they might be based on inaccurate intelligence of the situation in our projects, it's the false confidence, it can breed, and the blindness it can bestow that limits our ability to test accurately and effectively that are the risk. It's the shock and awe that an illusion the team may have held as true, once removed can cloud judgment on the value in the product.

To conclude, monitor yourself as you test from day to day.  Check to see if you feel yourself itching to turn on the autopilot.  Recognize it, take a step back, and find another way forward.  Use the pomodoro technique (Thank you Markus Gärtner), or some other focusing/de-focusing heuristic.  Be skeptical of even your own best ideas relating to testing, and always strive for one more thing to learn as you flex your testing muscles.  Try testing with a partner (Pair testing), so that you can keep each other from falling into a rut, or team with a developer and show him what you are doing to test the software.  Whatever it is you use to affect how you keep from falling into an zombie like coma while testing, do it as often as necessary, you'll thank yourself later.

Diary of a Soccer Coach: Week 1 - Getting the Players Attention

As I enter my fourth season as a Soccer coach, I can't help but reflect back on the previous three years.  There have been a lot of kids I've had the opportunity to work with.  The prior three years I coached the 'instructional division' as it was first called to me.  In essence I've had the honor of coaching up kids ranging from Pre-K  through Kindergarten age.   I've coached the same level for three years now, and again this year I am stepping up to do the same.

In some ways its hard to be a coach to the youngest in the league.  Some of them are already quite athletic, but lacking in coordination, some are squeamish about falling down, or running into someone else.   Some don't quite know what to expect from this their first athletic endeavor.   It isn't always easy on the coach either.  Sometimes we just barely get a season to get to know the kids before they begin to bloom and are ready to play up to the next level.  Some only get the one year, then are moved up with the other kids their age.   In essence each season is like starting over fresh.  There are always a few faces you remember from the previous years, and you may recognize the growing boys and girls practicing on a field not too far from your own teams, but your focus is now on the next group.

For companies like my current employer, where professionals might work on multiple projects, or bounce  between roles and wear different hats within or between teams as the needs become evident, to a team leader, it can seem quite a challenge to start from scratch with a team.  It can also be a challenge to get the new people involved and fully engaged and invested in the project.  

For the first session of the Soccer season as with any team, it is imperative to set the ground right.   The first practice always starts with a quick introduction and brief overview of the most basic rules of soccer.  Then we quickly transition into a couple of warm up exercises.  They aren't typically long exercises, but are designed to get the players moving, loosened up, and in the mind of being at practice.  Warm-up exercises could be great for team building, or for helping to transition a new team member into being part of the esprit de corps.    Having transitioned to several projects in my career, I feel that many of these warm up exercises did a lot to help smooth my transition into the team.

Of course, practice does not end with these warm-ups, nor should it be the end of the team building process either.  As Michael Larsen (@MKLTesthead) so eloquently put in describing the stages of team development in his emerging topics talk on teams and the EDGE method employed by the Boy Scouts of America - The team is still forming, here, it hasn't even begun to play soccer, nor has the new team or hire really progressed to a state of being fully in tune with the team's software development process.

So the next step of practice, is the first of many drills.  For soccer in the introductory division, the most basic of drills typically involves dribbling, around a pair or square of cones, emphasizing technique for controlling the motion, the tempo of the dribble.  For software teams, tempo, and pace are something that teams struggle to achieve, and hold once they have it.  The same is true for Soccer, and our instructional division is no different. The secret you see to these kids, and I'm betting many other youth organizations, is to keep the meeting or practice as active as possible.   

So we run them through a drill for five, maybe ten minutes, and then may start another.  This gets the players used to moving around, and focusing on one type of task or another.  However, at some point the kids need a break, so we give them a bit of time to run to the restroom, and get a drink before having our mid practice huddle.  More on these huddles in a later entry, but suffice it to say, the kids almost without fail come back refreshed, and ready to do more, but it is still the First practice, and i its important to temper our expectations with that in mind.  

With software teams, the same is true.  Each member needs down time to assimilate lessons learned, to rest from exertion of the mind, and for testers, to de-focus or refocus on whatever the next task may be.  Without this crucial down time, tasking begins to run right into the other so quickly that one may begin to lose sight of where one testing objective ends and the next begins.   It also presents a danger, because as creatures of habit establishing routines that are unhealthy will inadvertently result in inattention blindness, and as tempo and feel for how the project flows is learned, the risk increases that things move at a certain pace simply because they've always moved at that pace, whether the process or project are really at a achieving and sustainin velocity or not.

For my players in their first practice of the season, I see them in the scrimmage we typically run at the end of each practice.  They chase the ball without any rhyme or reason, with out any strategy or objectivity.  They believe the goal is to get the ball, and that to do that they must run to the ball.  There's just one problem.  someone else has that ball, and is accelerating in a different direction. so each player changes their angle to try and chase the dribbler down often from behind.  

At times it can look like  a swarm of honey bees, buzzing to one corner of the field, then changing course and quickly buzzing to another all around and trying to catch the ball each time, and inevitably these kids will trip, fall, or bump into another.   We haven't yet taught these kids how to move laterally, or even backwards when necessary, nor have we shown them the strategy of picking a place between where the ball might go to cut it off, rather than trying to chase it as if chained to the player with the ball like a rail car.  Inevitably the first practice always looks like this.  The older kids may not run into this scenario, as many have years of soccer under them by the time the season has started again, but for these new boots to the field of play, or to their team in the software world, they're a blank slate practically and in need of mentoring and guidance.  

The question you have to ask, is how can I influence them for the better, and help them see their role as more than just chasing the ball, as chasing this bug or that bug, when they may be leaving square feet of the field uncovered that could give them an advantage?   For me, it is important to remember that this is the beginning of a long journey we take together, and for better or worse we are here as part of a team striving to create that which our client needs.  However, even us experienced software professionals can occasionally trip over someone else's toes and fall flat if we aren't careful.  So trod carefully in those first days on a team, until you have a good picture of the terrain you must climb.

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.)

An End, and a new Beginning...

A lot can happen in two months time, nations have fallen, court proceedings have been completed, and sports seasons are nearly done.   When I last posted in August, I wasn’t quite expecting to go all of September without a blog entry.  I knew that based on the schedule for our Cub Scout Pack, Soccer, and Work schedules that October could be a heck of a month, but that was still almost six weeks away. 

I had just completed a research project, and come to the determination that if we wanted test automation that was easier to maintain, and of long lasting value, that we would very likely have to move away from using the older tool that we were using on the project.   Then came the exploration of a slightly newer version of the tool, and yes it provided some new bells and whistles, but when it came down to it, I still felt that given the way our website worked, that tool was not meeting our needs.

It’s a shame that it took me nearly a year to come to that conclusion.  Oh I knew the tests I was capturing, building, and testing were brittle, and sometimes it’s not something that’s easily avoidable given development practices on any given team, but it had become crystal clear to me, that building and maintaining automation did not have to be so hard.   Well, it is shear irony that I came to this conclusion just a couple of weeks before I was told they would not be keeping me on for the next contract year.  I thanked the project manager for allowing me to learn so much from the time I spent with their team, but realized that shifting gears at this point was not a logical possibility.  So I resolved to capture as many tests as I could in the short span of time I had left, and to leave behind documentation of the struggles, and conclusions I had come to so that in the future better solutions could be chosen for their team.  I am hopeful that work was not done in vain.

It was an interesting project, and I am thankful for every moment, every topic that came up in the pursuit of becoming better at testing, and specifically test automation as I worked to test for that project.  I really enjoyed working with the great group of people that comprised that team, and I hope I may one day be able to work with some of them again, but it was good to move on.   

When I took the step of faith to step out of my cushy box as a software developer, to walk on the other side of the cube so to speak, it was a bit of a risk.  I had done some testing off and on before, it seemed to always be something I would be called on to perform now and then, but without any formal training, or much relevant experience to fall back upon, I did not know if I was equal to that task.  However, I was eager to learn new things about software development, and was determined to become as solid as possible as a tester on this project.  In hindsight, I believe I achieved that goal, and as a result opened a vault of untapped knowledge relating not just to software development, but testing as well. 

The experience truly has transformed my thinking, although I now feel somewhat like a software development mutt, caring both about increasing my skills as a developer and tester.  The new project I am on promises to permit me to grow, and apply some of the techniques and skills I learned about testing, even some that were not applicable to the kinds of testing I was required to do before.  Plus, as a bonus I may get to learn more about a new technical area of which I have always had a small interest in, but little time to really dig into it until now.  

So the old project is done, a new one is on my plate, and I couldn’t be happier for the change, change truly is good, and I thank God for the opportunity to continue to build knowledge related to testing, even as I find myself straddling a fine line between being a pure developer, and a pure tester.   There will be more posts coming about lessons I’ve already learned and applied on this new project, but for now I am happy to be where I am professionally right now, and I can’t wait to see what’s around the next corner.  So while I’ve come to an end, I’ve discovered that it’s really just a new beginning.