Testers

[tomtomagain]

Flaring up with passive-aggressive personal insults the moment says they think you're wrong is a perfect illustration why most technical people are not equipped to do non-technical roles

Am not. We've obviously misunderstood each other.

Yes, because you have a very narrow view of what is valuable or constitutes work.

Believe me I don't. I have a very broad view of work and the value created by people in organisations.

[original PM]

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)

However getting back to the OP's post - testing is just a process which is undertaken to prove the system works correctly.

So you do your tests and mark them as pass or fail (or blocked..)

It is not a 'win' for anyone to discover a bug it is just what is expected as part of the testing process.

The amount of people I have worked with who have been testing something and got all excited when it broke just for me to give them a bit of a stoney glance and tell them to mark it down and carry on testing.

Just follow the process.

Having said that worked with a large company and they seemed to do no development other than to remove bugs (e.g. pretty much every test failed first time round).

[CheeseSlice]

Show me the org chart of any large corporation and you'll find that the "do-ers" are actually at the bottom.

Some people like doing the work and focus on that. Others focus purely on how they'll get their next role.

Personally I think the Gervais Principle best descibes most organisations.

http://www.ribbonfarm.com/2009/10/07...to-the-office/

[The Spartan]

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.

Which part are you not convinced on?

It's happened to me at a few places where they've turned around and said yeah the dev's have tested it so we pushed it out, only for it to be rolled back.

[vetran]

However getting back to the OP's post - testing is just a process which is undertaken to prove the system works correctly.

So you do your tests and mark them as pass or fail (or blocked..)

It is not a 'win' for anyone to discover a bug it is just what is expected as part of the testing process.

The amount of people I have worked with who have been testing something and got all excited when it broke just for me to give them a bit of a stoney glance and tell them to mark it down and carry on testing.

Just follow the process.

Having said that worked with a large company and they seemed to do no development other than to remove bugs (e.g. pretty much every test failed first time round).

don't you have a book running?

Times my code screwed up = X
Times testers deviated from tests or misunderstood the instructions / invented stupid reasons for failure = Y
Times the original design was incorrect=Z

I just make sure the number in my bit is much lower than the others.

[RetSet]

Back in the day when I was a programmer (no such thing as developers then) we tested our own code and took the 'phone call if it all went tits up at 2am.

That built character, attention to detail, and a sense of responsibility.

Then when testing became a skill in its own right and I moved over to testing as a career, I noticed that attention to detail and responsibility started to disappear from 'development'.

It got worse when so much development got bobbed. Code thrown over the wall that couldn't possibly have been through even the most rudimentary unit testing.

Many years ago, when I was one of the first people to gain ISEB certification, Dot Graham told us on a number of occasions that you can't test quality into software.

These days I'm finding more and more that testing is about being a professional turd polisher (phrase courtesy of Test Manager at current client Test Consultancy).

[GlenSausio]

Back in the day when I was a programmer (no such thing as developers then) we tested our own code and took the 'phone call if it all went tits up at 2am.

That built character, attention to detail, and a sense of responsibility.

Then when testing became a skill in its own right and I moved over to testing as a career, I noticed that attention to detail and responsibility started to disappear from 'development'.

It got worse when so much development got bobbed. Code thrown over the wall that couldn't possibly have been through even the most rudimentary unit testing.

Many years ago, when I was one of the first people to gain ISEB certification, Dot Graham told us on a number of occasions that you can't test quality into software.

These days I'm finding more and more that testing is about being a professional turd polisher (phrase courtesy of Test Manager at current client Test Consultancy).

This is 100% correct.

[Cenobite]

Unless you expect the tester to chase the end users for actual requirements?

This is where a lot of teams go wrong: the testers should not get their idea of what the software needs to do from the developers. If the testers get their picture from the developers then you might end up with a system which does not really satisfy user needs. Testers ought to work as a check-and-balance by getting the requirements independently from the customer team.

[Cenobite]

The thing is, the decent developer can do all those other roles. You can't flip it around. A BA or tester cannot stand in for a developer.

This has really bugged me in previous roles. Companies want "team players" and Scrum teams just have the one role "development team member" which covers programmers, testers, UI and BAs. So companies want people to muck in when they have to, but this almost always means a developer doing other people's roles for them. As you said, it's not as if the average BA can start coding.

Even worse, in one team I worked in, everyone on the development team was on the same pay scale. I've been a PM, a BA and a developer and I just don't think it's right.

[Cenobite]

But ... Java/C# has ruined the game for decent devs, the entry level is so low that you get idiots who can't
do the other roles- that's not to say there are not brilliant java devs around, because there are. In the old days, when we were all doing C++, there were very few idiots around - no BAs or many testers either.

I totally agree. I'm an ex-Java developer. Most C++ programmers know their stuff and I think companies would have a lot more trouble bobbing out C++ work than Java. My top tip is Clojure, a functional programming language: I've found functional languages really separate the wheat from the chaff because a lot of average developers just can't get their head around it.