Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Playgrounds & a Thought on Testing

April 20th, 2007 · 14 Comments

My brother-in-law Russ is a professional playground installer who travels all over the country installing playgrounds. For the past three weeks he’s been building a playground in Indy, and I’ve been going over after work to help him. We finished it up last night and here are a few pictures of the finished product.

Playground
Playground

When I first met my wife and she told me her brother in law traveled all over doing his thing, I was a little skeptical. How hard can it be, right? Why did I think that? Because my initial image of playground building was a couple of guys installing a swingset at a school, or one of those metal outdoor slides that’s just a ladder and a slide. At first it seemed that anyone who could read directions could build one. If you could put together a kid’s bike, you could put together a playground.

That idea is complete crap. My brother-in-law built the playground you see above in three weeks, mostly alone. It would have taken me three months to do that, and I would have screwed it up in a big way. Building a play ground is much more complex than I imagined at first. Had his client tried to build the playground themselves, they would have made an enormous mess of it and wasted a lot of money. I understand that now because I have had several opportunities over the years to observe Russ’s work and to help him out a little bit.


My perception of software testing has taken a similar twist over the years. I admit, I once saw software testing the way many developers do – as an activity you delegated to team members who couldn’t cut it as developers. I don’t see it that way anymore, for the same reason I don’t have the same simplistic view of playground installation I once did. I’ve been exposed to some very fine work in testing, and I’ve been given the task of managing a few testing efforts that have proven to be extremely difficult systems to test effectively.

I wish more developers and project managers had the same experience I have had. Unfortunately, the perception of testing as being an “inferior” role in IT is a self-reinforcing one. Because we see it as a job “anyone can do”, we keep hiring “anyones” to do it. A lot of them. And they do it, although it usually doesn’t work out very well and wastes a lot of time and money. This build the perception that large testing efforts require large armies of “testers”, whose jobs are simply to follow written instructions and note where the application doesn’t do what the instructions say. The result is a large mass of testers in the industry where only a relatively small percentage of them are extremely gifted.

Like my perception of building playgrounds, this idea that testing is an inferior role is also complete crap. IT managers and developers who appreciate the complexity of testing will be at a distinct advantage over their biased peers because they will hire a few gifted testers to do the job of an army of unskilled ones. They will be more efficient at finding bugs, analyzing problems, and developing cost-effective ways of testing applications. As a result, the applications they build will be better. That’s what it’s all about.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Uncategorized

14 responses so far ↓

  • 1 John McConda // Apr 20, 2007 at 9:24 am

    Great analogy and great pics! This is also the perfect tool I need to get my 2 year old daughter interested in testing. She’s obsessed with playgrounds. :)

  • 2 Phil Kirkham // Apr 20, 2007 at 9:48 am

    Thats exactly the attitude I’m up against every day even though the evidence that anyone can test is proven wrong by all the bug reports coming in

    question is – how to change the perception of the mass of people out there with this idea ?

  • 3 JEDI » Blog Archive » links for 2007-04-21 // Apr 21, 2007 at 5:18 am

    […] Information Technology Dark Side » Blog Archive » Playgrounds & a Thought on Testing (tags: testing) […]

  • 4 vijay // Apr 21, 2007 at 11:44 pm

    Great Job!
    I always tell people how it is difficult to Test some projects. As I am doing this since last 3 years..
    You should be extremely careful while recruiting the testers..

  • 5 Howard Clark // Apr 23, 2007 at 10:31 am

    It’s absolutely refreshing to find someone who can recognize the inherent deficiencies of some testers as well as the benefits of others. Your point rings true that the age old “quality over quantity” axiom still rings true, and is desireable. More often than not when it comes to staffing the problem perpetuates itself due to a lack of understanding by the testing resources asked to do the staffing in the first place. If you create a situation where your testing effort is massive, and the obvious constraints of time are lurking, the average company is going to have a difficult time attracting a high number of talented testers. Instead what you get is warm bodies that contribute very little to the process, strategy, or approach both inside and outside of their given project. Essentially, you get the “human robot” that presses buttons. These personality types have little desire to become an asset and contribute anything more than what is printed on a test script, much less the skills too.
    So to mitigate all this you start with placing talent at the top, someone who can develop a relationship with the development team. I am a former full-time developer who switched over to testing so its easier, but anyone who invests in at least learning development and unit testing methods can have some success. The idea is to develop an appreciation for software development, and having a high level understanding of the architecture and it’s implementation. Lastly, working to understand the technical challenges and common pitfalls for that software architecture can help target the testing effort. All of this helps build credit in the eyes of both the development team and management.

    It only takes a few poorly written and incorrectly logged defects to put a tester behind the eight ball. Apathy towards the developer’s plight and demonstrated ignorance about software and systems is the nail in the coffin.

  • 6 Drew Kime // Apr 23, 2007 at 5:02 pm

    And a sure way to drive away any talent you *do* end up with is to allow developers with two years of experience to cop an attitude with the QO lead who did development for 9 years before getting into testing, which he’s been doing for the last 5 years.

    I had someone submit code to me that didn’t work. After three rounds of sending it back with detailed descriptions of the problem — and each new submission was broken in a different way — I looked at the code and the stored procedures behind it. Within five minutes I found the problem and sent back the new code that worked.

    He decided to redesign the whole report. My solution was clearly wrong, and only worked in the context of a “bad specification”. A specification that had been approved by the client. The response from the IT director was that I shouldn’t be “getting down in the weeds looking at code”; I should be submitting bug reports and letting the developers work it out. Then my DB access was revoked.

  • 7 Drew Kime // Apr 23, 2007 at 5:03 pm

    Bah, that should be “QA Lead” above, not “QO Lead”. And the teaching point is that you can never proof your own work. :-/

  • 8 Ben // Apr 27, 2007 at 10:05 am

    @Drew

    >> Within five minutes I found the problem and sent back the new code that worked.

    I’ve did that twice.

    Once I wrote code to fix a problem that the biggest single customer was griping about. Development was thrilled that I helped and shipped my code.

    Another time I wrote simple code to fix a long-standing bug in search code that resulted in complete word matches not showing up in results when partial matches were displayed. Everyone seemed to like the simplicity of my fix but some in development decided that it wasn’t my role to write code — it was the developers job. Last I heard, that bug was still in the code. (And that was many years ago.)

    I agree that it really wasn’t my job to be writing code for developers. However, in both cases, I was involved in testing the application and data and had a better view of how it all fit together than the realtively new development team that inherited the products. I worked with developers in both cases. I believe the difference was my relationship with the developers of the two appilcations. I had a good relationship built on trust and respect with one of the developers and a not so good relationship with the other.

    Developers often look down on testers as being less capable and don’t see testing as a skill independent of development. Testers often look down on developers as being incapable of writing good code. Rather than point fingers, we need to work together towards our shared goal of delivering good software on time.

    It is very important that developers and testers respect each other.

  • 9 Wayne M. // May 1, 2007 at 3:52 pm

    I guess I can commiserate with the divide between testing and development from a different angle. In introducing agile development practices, I have found great resistance from software developers, software architects, and software management when proposing that the developers and architects also create unit tests. The idea is not to replace traditional test, but to shift its focus from functional testing to higher level concerns such as performance testing, security testing, and usability testing.

    I will also attest to the fact that testing requires its own skillset and most developers need to be trained in basic testing skills. I hope we can continue to breakdown walls based on roles and share skills across team members.

  • 10 Frederic Torres // May 1, 2007 at 10:03 pm

    To answer Phil Kirkham question : how to change the perception of the mass of people out there with this idea ?

    Influenced by the reading of Mary and Tom Poppendieck’s book “Implementing Lean Software Development”
    I will say the following:

    The job of QA is not to find defect but to prevent defect and both developers and testers contribute.

    Defined this way, the QA team has a different position in the all process.
    You cannot hire QA people that have no clue about preventing defects in a software.
    The QA team members must be involved from day 1 in the design and development cycles making them equal with the developers.

    On one side automated classes unit tests, automated user interfaces unit tests and automated end to end testing are required.
    Test Drivent Development is even better if you can do it. (FIT is also very interesting http://fit.c2.com).

    On the other side because you may not be able to prevent all defect, early manual (exploratory) testing will do.

    But in the end it is the management (CEO, VP and director) that will behave as courageous and open leader or
    will just play the political game of their company.

    Frederic Torres
    http://www.InCisif.net
    Web Testing with C# or VB.NET

  • 11 Allen Childress // May 17, 2007 at 3:46 pm

    Stopping the snowball at the top of the hill:

    I was taught by a coding master to always design software in the beginning to log its own activities, and even better to allow for automated entry of test scripts (often in XML form these days). Doing so can make the life of everyone easier.

    It is especially critical in production when something goes wrong and a precise log can replicate the problem and data, back on the test machine, where it can be single stepped. Then those “production down” problems can be shortened from days to hours.

    The problem is that it takes a good ability to think abstractly and in strong Object Oriented fashion, to set up a system where either the normal client or a test client can be interchanged. And finding programmers with that kind of skill is rare to my experience.

    Similarly finding testers who can think abstractly is a joy to me as a developer. They do an excellent job of categorizing problems and recognizing the commonalities in test cases. The #1 gripe of all programmers about testing teams is getting 17 versions of the exact same problem. Having strong domain knowledge is very beneficial to testing, but doesn’t seem to help on this issue.

    “I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.”
    – Albert Einstein

  • 12 Mike Kelly’s blog » Blog Archive » Playgrounds & a Thought on Testing // Nov 1, 2008 at 8:11 pm

    […] has a great post on Playgrounds & a Thought on Testing. Worth a read, and a couple of cool pictures. Post new comment « February 2005 – The […]

  • 13 Software Testing // Oct 4, 2010 at 11:22 pm

    Good Job. The software testing is not the easy job. I tell this through my experience. The person who are love the profession only done the job like software testing.

  • 14 F14testing Team // Nov 20, 2010 at 10:45 am

    Yes, testing demands a lot of out-of-the-box thinking.

Leave a Comment