Testers

[vetran]

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

The thing our developers & DBAs seem to struggle with is dotting the I s and crossing the Ts if you are expecting a number refuse to accept an Alpha or the presence of a try catch block etc. is good coding. The user who stands on one leg and uses their nose on the keyboard is the responsibility of the testers.

Just having a 'conversation' because data templates include Lookup values that aren't and will never be in the destination system (which we don't have sql access to). The users during data mapping selected an appropriate value and we coded that.

It fails load because we didn't use the 'right' values why didn't we use the template? We did we reply. Its taken 3 weeks to get them to agree to correct the template.

We have no testers , but I have a new application to test this week and I expect to be a pile of pants the development team are quite shoddy.

[original PM]

I've never been on a team that has more testers than devs and it's quite easy to see when they're cutting corners as things just don't work, I have a few here that I know when it comes to testing their work that it's not going to work as expected.

Not convinced on this.

Our dev team make sure the product works e.g. does not thrown bugs/exceptions/errors.

However it is down to the test team to ensure that the system works properly under operational conditions.

Had a great example recently where a new report had been delivered - dev team tested it and it ran ok - however the finance team did not verify it returned the correct numbers.

So it was put live but did not work - for me that is down to the testers not the dev guys.

[jmo21]

Not convinced on this.

Our dev team make sure the product works e.g. does not thrown bugs/exceptions/errors.

However it is down to the test team to ensure that the system works properly under operational conditions.

Had a great example recently where a new report had been delivered - dev team tested it and it ran ok - however the finance team did not verify it returned the correct numbers.

So it was put live but did not work - for me that is down to the testers not the dev guys.

It ran ok? you mean it put something on screen that turned out to be not what they wanted?

Was it a bug in the spec then?

Or was there no spec, some rough conversations about how it should work, coded, not verified in test, and put live.

Bug in the software development lifecycle then, not sure a tester could have caught that. Unless you expect the tester to chase the end users for actual requirements?

[original PM]

It ran ok? you mean it put something on screen that turned out to be not what they wanted?

Was it a bug in the spec then?

Or was there no spec, some rough conversations about how it should work, coded, not verified in test, and put live.

Bug in the software development lifecycle then, not sure a tester could have caught that. Unless you expect the tester to chase the end users for actual requirements?

No not a bug in the spec but it was a complex financial report and we needed the testers to ensure that the various calculations were correct - dev people are there to develop - do not want them to spend time checking their work over and over again.

Whoever asks for the change must test it and not rely on anyone else to sign off it is correct

[jmo21]

No not a bug in the spec but it was a complex financial report and we needed the testers to ensure that the various calculations were correct - dev people are there to develop - do not want them to spend time checking their work over and over again.

Whoever asks for the change must test it and not rely on anyone else to sign off it is correct

So when it was found to be not correct, one or more of these calculations was incorrect presumably?

So either the dev(s) misread the spec and coded it incorrectly (devs fault, logged as code bug) or the spec was wrong/not complete (spec writers fault, bug logged against spec).

Or was it something else?

(maybe new information came to light and it wasn't fed in to change request process)

[vetran]

No not a bug in the spec but it was a complex financial report and we needed the testers to ensure that the various calculations were correct - dev people are there to develop - do not want them to spend time checking their work over and over again.

Whoever asks for the change must test it and not rely on anyone else to sign off it is correct

whoever designed the job should have supplied data for them to test in Dev and got them to confirm the calculations came out correct.

Testers and customers should have checked with real data.

[original PM]

whoever designed the job should have supplied data for them to test in Dev and got them to confirm the calculations came out correct.

Testers and customers should have checked with real data.

Cannot put live data in test environment
don't get me wrong we are not talking lots of bugs and the dev team get judged on that but the initial requester has to test and sign off prior to deployment to prod environments

Also erm.... Agile kinda relies on dev.test.rework

[GlenSausio]

No not a bug in the spec but it was a complex financial report and we needed the testers to ensure that the various calculations were correct - dev people are there to develop - do not want them to spend time checking their work over and over again.

Whoever asks for the change must test it and not rely on anyone else to sign off it is correct

I get the BA (ie. glorified tester) to sign off on test cases. Those test cases (ie. inputs to the report and expected calculated values) go into my unit tests. No tester needed, I can prove the code is working- my unit tests are passing. The tester adds very little. Actually, the BA adds very little but that's a different story.

Automated testing specialists are quite useful. But point and click testers are only useful when developers are lazy. And you can't trust them testers to do a proper job of testing the app. It's merely a TRANSFER OF OWNERSHIP of responsibility, that the dev team would like. Blame the tester.

[TestMangler]

I get the BA (ie. glorified tester) to sign off on test cases. Those test cases (ie. inputs to the report and expected calculated values) go into my unit tests. No tester needed, I can prove the code is working- my unit tests are passing. The tester adds very little. Actually, the BA adds very little but that's a different story.

Automated testing specialists are quite useful. But point and click testers are only useful when developers are lazy. And you can't trust them testers to do a proper job of testing the app. It's merely a TRANSFER OF OWNERSHIP of responsibility, that the dev team would like. Blame the tester.

A BA is not a glorified tester. A BA takes other people's documents, changes the author's name and re circulates them as their own.

As for the rest of what you say, it's bollocks

[original PM]

Indeed a BA could create use cases and the system could be tested against those.
However in order to prove the development has met the requirements an independent body has to confirm this.

We often call them users wearing a testing hat.