Tuesday, June 1, 2010

7 habits software coders wish the testers had

In my tenure as a tester and a test manager, I've worked with both types of settings where:
  1. my company provided testing as a service to some development firm, so testing team was the service provider and the coding team was the client.
  2. my company developed the product itself, so the testers were a part of SDLC team
3 musketeers disney edited



Interestingly in both cases the coding teams had similar wish list for testers. Here are some common comments and how we can do something about them:
  1. Good functional coverage: This is the first, most basic and a must-have requirement. Everyone – coders, managers, clients, all stakeholders – expect you to understand requirements inside out.
    1. Make sure you question each line of requirements documentation, find positive as well as negative scenarios to test.
    2. Test from each stakeholder’s perspective. Cover most user scenarios.
  2. Test environment to resemble end user’s setup as closely as possible:
    1. I’ve seen more than one case when the testing was done well but the environment on which the system was used at the user’s end was not well replicated. Result? Disappointments and wasted  efforts! So beware.
  3. Early reporting of defects:
    1. Coders wish the testers would tell them about a lurking defect as quickly as they have found it (so that they can fix it soon). That does not mean testers should should “I’ve got one” each time something unexpected happens. No. You should definitely take your time to dig deeper, isolate your findings, find possible causes of the problem (and probable solutions, even? Why not?!). Just don’t wait till the last moment to fling a defect over the wall when the product is about to roll out.
  4. Adequate information in defect reports:
    1. A good defect report consists of all the info required to isolate and fix a defect, in a succinct, crisp way.
    2. Here your skills of observation are going to be utilized the maximum. Mention the exact scenario(s) when something failed. Mention your test environment. Did you have any network services or antivirus program running when the system stalled? When you executed a file more than 2 GB did you get a crash? Paint the exact picture.
  5. Surrounding testing while closing defects:
    1. Verifying and closing defects is another crucial activity, that is often overlooked even by experienced testers and that results in dollars lost. One trick I tried while closing a defect was to try and replicate it again. If I fail after reasonable number of attempts, the defect is verified closed.
  6. Performance numbers for products / websites:
    1. Coders more often than not rely on you to understand the health of the system they are building. Set aside time and make sure you perform load, stress testing. Do your numbers and report how good, bad or ugly your system is. After all you might have given the best UI features, the coolest animation and stuff on your web page, but if it takes forever to load your users will be turned off. So, get serious about reporting these numbers.
    2. Make sure you also make your managers aware of the importance of these readings, so they can plan time for performance testing, finding related defects and getting issues fixed, system optimized.
  7. (Last but not the least) Respect for other person’s work:
    1. One of my greatest lessons from serving s/w industry is that “it’s the man that maketh the machine”. And men (and of course women, too) have human flaws. Egos. If you spent your 8 waking hours of a day away from your family (and TV) to write a web page, no matter how sloppy, you’ll still be expecting others to look up to it with awe. Ok. I agree there’s a bit of exaggeration there. But get the point clear. Don’t make defect counts proportional to the amount of respect you show for others. Be diplomatic when it comes to announcing faults in someone else’s work. “Do unto others what you would have others to do unto you.”

Enjoyed reading this article? You’ll like receiving more tips and testing related information in your e-mail. Please subscribe by clicking here. You’ll also be helping me in reaching my goal of having 1000 subscribers by Dec 2011. You have my word for no spam and complete privacy of your information.

3 comments:

  1. Hi there,
    I saw your pitch on the Problogger forum. It interested me because my husband is a software engineer. He doesn't do testing, but he talks about people who test. Anyway, I think your short pitch works! And I like this 7 habits post even though it's too technical for a liberal arts major like myself. :-)

    Sandy

    ReplyDelete
  2. Thanks Sandy, appreciate you taking time to comment on my blog.

    ~Varada

    ReplyDelete

I love comments!!!! Please feel free to share what you think of this post. I'll make every attempt to respond to your requests, if any.

Thanks for dropping by.