Testers

[tarbera]

Doesn't really work in a forum full of programmers and accountants.

Lol

[woohoo]

Having testers just means the developers start cutting corners - why bother to verify that something works when that's the tester's job? Which means more bugs are reported and the management take that to mean the quality of the product has improved - all thanks to their decision to hire testers. All they've actually done is increase the size and inefficiency of the team.

I know what you mean but don't entirely agree. I would look at the culture first, unrealistic deadlines combined with a blame culture would encourage people to cut corners.

A good tester will test the whole system not just the specific bit the developer has changed, hopefully their testing will also be much better than a developers, it's their profession. You want your developers to test as they go but it's a waste of resources to turn your devs into testers.

I did read an article from a startup owner, who got rid of his testers because the testing was taking too long and they couldn't meet their release cycles (i think every two weeks). So his answer was to get rid of the testers and he told the developers to take responsibility for their own testing. He said it worked really well for him, but I could imagine his developers either being less productive or working longer hours to ensure they didnt release code that was going to take the site down.

[cailin maith]

Speaking of Testers.... where is Mich these days?

[SimonMac]

If dev's could do their job right in the first place there would be no need for testers!

[tarbera]

Speaking of Testers.... where is Mich these days?

Mitch had a serious illness

But the good news is he is now in regression

[VectraMan]

I did read an article from a startup owner, who got rid of his testers because the testing was taking too long and they couldn't meet their release cycles (i think every two weeks). So his answer was to get rid of the testers and he told the developers to take responsibility for their own testing. He said it worked really well for him, but I could imagine his developers either being less productive or working longer hours to ensure they didnt release code that was going to take the site down.

The thing is if a developer spends a bit extra verifying what he's done does actually work it might only take an extra 10 minutes. Whereas if you think something's done, move on, then have to come back to it a week later because a tester has found a problem it might take you a couple of hours to get set up again and remember how everything worked. So it's much more efficient to have the developer find problems in their own code.

But it is always a good idea to have a second pair of eyes check something. If I were setting up a software team I'd hire only developers and tell them they'd all have to spend a bit of time testing each other's work. That also has the advantage that everybody learns more about the whole system rather than focussing on just the bit they did and if bug reports come from developers they tend to be a bit more useful and so require less time to find and fix the issue.

[NotAllThere]

Where exactly do they fit in the pecking order?

Got one here and she's a right little bossy boots. Always referring to us as "my developers".

Gets right on my tits.

The way I see it is that it is us developers that do the jokes....

(..mind you, some of the places I've worked, that statement could be taken literally)

Never has it been more true to say they are the testers, you are the testes.

Mitch had a serious illness

But the good news is he is now in regression

Got it out his system, did he?

[Dallas]

Depends on the scale too.

My lot are testing alot of interdepedent code that no-one dev has been involved end-to-end. Now you can polish it as much as you want, if it doesn't hang via real use cases it wont get released.

I need my testers there to ensure the client (havent seen much mention of that yet...) doesnt get a pile of ....., hence jeapordising the creditability of the project team. Impacting future funding and contract renewals.

I have turned acouple of the BAs into testers too, they are the only ones with 100% pass rates, amazing that

You lot are writing like one-man-banders which is fair enough for smaller deployments. Its the biggies where you have interdependencies that bring more ££££ anf future contracts.

[d000hg]

The thing is if a developer spends a bit extra verifying what he's done does actually work it might only take an extra 10 minutes. Whereas if you think something's done, move on, then have to come back to it a week later because a tester has found a problem it might take you a couple of hours to get set up again and remember how everything worked. So it's much more efficient to have the developer find problems in their own code.

But it is always a good idea to have a second pair of eyes check something. If I were setting up a software team I'd hire only developers and tell them they'd all have to spend a bit of time testing each other's work. That also has the advantage that everybody learns more about the whole system rather than focussing on just the bit they did and if bug reports come from developers they tend to be a bit more useful and so require less time to find and fix the issue.

You don't seem to have a very well informed understanding of what proper software testing is/involves. By its very nature, developers often make bad testers because testing is dull, repetitive work. "Spend a bit of time testing each others' work" doesn't - from my experience anyway - catch too much beyond obvious bugs that should never have made it through in the first place. Our system has people constantly playing around as they work on overlapping areas but it's still the testers, with their ability to methodically work through "OK, but this time I'll press B before A", who still find lots of the 'real' bugs where modifying one area borks something else. Developers like to test that what they did works as it should, not that everything else still works, or that it works when done in every possible way rather than the one way the developer got used to doing things.

Good testers are able to think the way a stupid user would; developers struggle with that

[tarbera]

Never has it been more true to say they are the testers, you are the testes.

Got it out his system, did he?

Some of his bugs were reduced from critical to low priority when it was descoped with a manual reach-a-round