Archive for May, 2010

Who Am I? – The Uncertainty of the Laid Off Software Tester


I was perusing the blog and came across the interview “Testing the Limits with Lanette Creamer”. Lanette talks about the uncertainty of a pending lay off from her software testing role asking the questions “Who am I if I’m not a tester? Are testing skills relevant in the marketplace? Is talent at finding bugs totally obsolete?”

Earlier this year I found myself in a similar mindset after having been laid off after 12 years in a tester/test management role. Questions circled in my head as well. “Did I stay at one place too long?” “Am I stale and therefore irrelevant in my field?” “What now?”

My first reaction was to find a job, any job and quickly. I applied for just about every position that was available even if I wasn’t sure I’d be happy working for the company. It was panic mode and in hindsight it was not helpful to my mental well-being.

One thing I had going for me was networking. I had been an early adopter of and my professional network contact list was fairly large. I could find out more about the companies I was applying to before hitting the submit button by talking to my contacts and making new contacts at that very company.

The other thing that helped was that I knew that I didn’t know what I didn’t know. All those questions about my relevance as a tester needed to be answered. So I started searching for them. I search the Google Tech Talk videos and watched every video that had to do with Software Testing.

I found James Bach’s tech talk and found it very inspiring. He held many of the same beliefs about testing and who a tester is that I did. “And look he’s successful! I can be too.” So sent him an email explaining my situation and asked him for a direction to follow. There’s so much diversity in software testing that I couldn’t possibly study it all before my first job interview. James was very helpful in getting me on my own path and providing me support.

One of the first things he did for me (besides run me through a Test Challenge over Skype!) was introduce me to Matt Heusser who lived in my regional area. The next day I was talking with Matt on the phone about my situation (Matt also set up a Test Challenge for me).

Between the two of them and a bit of time the fear of uncertainty that came with the layoff subsided and I built my “way forward”. I still don’t have a full-time job, but I’ve managed to get work through crowdsourcing companies and other opportunities. I’m not making as much as I was, but I’m making enough to be happy and also to be selective with the companies posting jobs.

So to Lanette and any other software tester who may be in a similar situation I offer this advice. Know who you are. Know that your skills are relevant. Lean on your community for support and direction and make your own direction.

Who am I? I’m a software tester and I’m a damn good one.


Competitive Testing: The Good, The Bad and The Ugly


The notion of competitive testing has been spinning around in my brain for the past few days and I’m not sure how I feel about it. Maybe putting it in writing will help.

I’m naturally adverse to competition as a catalyst for self-importance. While I may feel good having done well in a competition, I feel the results don’t define me as a person. I think this goes back to high-school where a B was just as good as an A in my opinion. “So what if I didn’t know the date of <insert historical event>, at least I understood the concept of what happened and why it’s important!”

I suppose we should start with “The Good”. Competitive testing in the form of bug battles is a great way to sharpen your skills, meet other testers and maybe learn a thing or two along the way. I have no problem with this.

So we move on to “The Bad” and, of course, this is completely subjective depending on the person.

Recently I’ve been involved in a crowdsourcing movement where most of the pay is based on finding bugs through exploratory testing. Basically throw a bunch of testers into an arena with a thin test plan and broad scope and say “Go find bugs”. While I believe this is a great way for a company to find problems with its software for a much cheaper price than having a salaried QA department I’m looking at it from the other side.

Now, I don’t want to come across as being against the crowdsourcing movement. Quite the contrary in fact, it has been a boon to my personal finances and networking connections in a time when I truly needed it. I was able to navigate the system successfully in a short time and make it work for me. But I have concerns for those truly skilled testers that may be in a similar position that may not possess the ability to navigate as successfully as I did.

The problem I see is that the client will pay for the bug, but the tester needs to be the first to find the bug and report it to get paid. All others may also find the bug but they weren’t quick enough, or their internet speed wasn’t fast enough. Miss by a millisecond and you get nothing for the effort and in some cases will be reprimanded for entering a duplicate bug.  Does this mean that the tester who was faster is a better tester? I don’t think so and I can’t help but wonder how many testers take this situation as a hit to their credibility?

Now for “The Ugly”. I am a firm believer of being clear and concise in reporting a bug, building a test case, etc. Reporting “Got an error” doesn’t cut it for me. In my opinion a tester needs to give the maximum possible information about an issue that he/she can find within the time constraints forced upon them by the scope.

I have seen many bugs reported in these crowdsourcing projects where the first bug reported did not contain quality information about the problem. I’m sure the client or PM had to go back and request more information. But still this bug is accepted where someone else may have found the same bug but submitted it later with quality information that can be acted upon. Yet, this tester gets nothing for the effort of creating a quality bug report.

Now, of course these are the extreme examples and the exception to the rule. For the most part I’ve seen crowdsourcing work very well when it’s well-executed, witnessed the community self-regulate and provide an overall quality report on the maturity and market-readiness of an application. It’s these edge cases that have had me thinking.

Additionally, I should also mention that I’ve only been involved with this type of crowdsourced movement for just under two months now. And as I had suspected, more and more “high profile” projects are being made available based on my performance here. Even for a veteran tester, it’s great to have such exposure to a diverse set of projects (for example, I’m about to get a taste of mobile testing in the coming week).

I have raised my concerns with managers in the crowdsourced testing company I am working with prior to posting this blog entry and I’m pleased that they recognize the need for continued improvement, and have concrete plans to level the playing field for all testers, allow for quality testing to rise to the top thus improving the overall quality of the service they are selling. I truly believe that they care about quality and, just as importantly, fairness between testers and customers.  It’s refreshing to know that they genuinely strive to raise the bar.