In my tenure as a tester and a test manager, I’ve worked with both types of settings where:

my company provided testing as a service to some development firms, so the testing team was the service provider and the coding team was the client.

My company developed the product itself, so the testers were a part of SDLC team.Also it was on the best digital marketing companies in Bangalore.

Interestingly in both cases the coding teams had similar wish lists for testers. Here are some common comments and how we can do something about them:

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.

Make sure you question each line of requirements documentation, find positive as well as negative scenarios to test.

Test from each stakeholder’s perspective. Cover most user scenarios.

Test environment to resemble end user’s setup as closely as possible:

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.

Early reporting of defects:

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 say “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.

Adequate information in defect reports:

A good defect report consists of all the info required to isolate and fix a defect, in a succinct, crisp way.

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 programs running when the system stalled? When you executed a file more than 2 GB did you get a crash? Paint the exact picture.

Surrounding testing while closing defects:

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 a reasonable number of attempts, the defect is verified closed.

Performance numbers for products / websites:

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.

LEAVE A REPLY