The end result of bobville, you'll never retire

[Mich the Tester]

I like Agile it works for me, what I dislike is calling something Agile just suit whatever approach is needed which I've seen done a few times. I do a lot of exploratory testing here and despite the massive of amount automation they have here done by software engineers in test (SET's) I've still found shed loads of bugs

Yep, I was chatting with a couple of very highly regarded (here in NL) context driven testers yesterday evening and we exchanged a few tales of BBB's (big bastard bugs) we could never have found with automation. Including bugs in medical and emergency services systems that would quite feasibly kill people. I await with mixed feelings the day that some Test Automation fundamentalist finds himself in court with Cem Kaner, Michael Bolton or James Bach opposite him as an expert witness. I say mixed feelings because I just hope it isn't bankruptcies or human suffering that brings something like that to court, but I know that Kaner has done some cases where the lack of exploratory testing has led to clients winning compensation claims.

[SupremeSpod]

I like Agile it works for me, what I dislike is calling something Agile just suit whatever approach is needed which I've seen done a few times. I do a lot of exploratory testing here and despite the massive of amount automation they have here done by software engineers in test (SET's) I've still found shed loads of bugs

They normally have a habit of testing for success rather than testing for failure.

Just saying, like...

[tranceporter]

Unfortunately though, in most of the places I have worked at, testers are either very few in number compared to the number of developers, or loads of testers with poor testing standards. In the last place I worked at, they developed code for 4 years before they hired their first ever real tester!
And the moment that poor bloke joined the team, he was bombarded and overloaded with projects and stuff to test, and I really felt bad for him. Things have moved on since then, and in a year, we had 4 testers, with 1 of them resigning. He was the best of the bunch though, even developed some Fiddler extensions to aid testing. Really knows his stuff. The poor quality QA I have seen are unfortunately bobs (of my own creed) who are usually employed by TCS/Infosys/Cognizant/Accenture (or replace with any other mass market IT recruiter), and have barely got any hands-on experience with real world apps, but have been sent on-site either due to round robin policy, or some office politics (his/her manager is from the same community, so they look after each other ). This leads to the more "common yet incorrect" view that testers are people without no technical aptitude; who just click buttons to check if things perform as per user story, and tick the user story as passed/failed.
Testing seems to be the first thing that goes out for a toss, when the project deadlines change, or some idiot business bloke at the top just moves the goalpost to please his client. Rather sad.

[Mich the Tester]

They normally have a habit of testing for success rather than testing for failure.

Just saying, like...

Spot on.

Repeating my mantra here; it's easy to find out if a sytem does what you say it should do; the skill is in finding out how to make it do what you absolutely don't want it to do.

[vetran]

I work from home mostly because the infrastructure desk has been vacant for four months and the 6 months before then the person in the chair was building their career so everyone kept asking me to fix their PC. Came to a head when my boss arrived for an annual visit and there were 6 people asking for me to fix their PC's, sort of made it easy for me.

Anything he doesn't understand he rings me, I send him the manuals and wait, 10 minutes later he rings me asking the same question having not read the manuals. He's actually native Sikh and quite intelligent so not a Bob.

Its an attitude, experience builds resourceful-ness but you are marked on jobs completed so there is no incentive for him to think, he just tries to leach off me.

[tranceporter]

I work from home mostly because the infrastructure desk has been vacant for four months and the 6 months before then the person in the chair was building their career so everyone kept asking me to fix their PC. Came to a head when my boss arrived for an annual visit and there were 6 people asking for me to fix their PC's, sort of made it easy for me.

Anything he doesn't understand he rings me, I send him the manuals and wait, 10 minutes later he rings me asking the same question having not read the manuals. He's actually native Sikh and quite intelligent so not a Bob.

Its an attitude, experience builds resourceful-ness but you are marked on jobs completed so there is no incentive for him to think, he just tries to leach off me.

The question, however, is if he learns it after leaning on you the first time, and sort out the same problem next time without reading the manuals, or waste your time again? I have seen that habit a lot. Like some previous poster mentioned about First line support, it's far easier to adopt the habit of quickly leaning on someone to find a solution, than searching yourself for an answer. Sooner or later, in the contracting world I have seen, such contractors get the kick after the first month of "leaning".

[Mich the Tester]

The question, however, is if he learns it after leaning on you the first time, and sort out the same problem next time without reading the manuals, or wasting your time? I have seen that habit a lot. Like some previous poster mentioned about First line support, it's far easier to adopt the habit of quickly leaning on someone to find a solution, than searching yourself for an answer. Sooner or later, in the contracting world I have seen, such contractors get the kick after the first month of "leaning".

I think leaning on others is fine if you first try and do a bit of groundwork with the wonders of google; techies are often absolutely terrible at giving spoken or written instructions on how to do something so it's generally a good idea to sit down together with them and work through something making notes as you go.

[tranceporter]

I think leaning on others is fine if you first try and do a bit of groundwork with the wonders of google; techies are often absolutely terrible at giving spoken or written instructions on how to do something so it's generally a good idea to sit down together with them and work through something making notes as you go.

Lol, I must say I have been knowingly guilty of that. Sometimes, you just assume that the QA knows the stuff you have coded based on the requirements, and just skip the instructions altogether I must say though, that this is where SpecFlow features and scenarios can help a lot if uses correctly.

[vetran]

The question, however, is if he learns it after leaning on you the first time, and sort out the same problem next time without reading the manuals, or wasting your time? I have seen that habit a lot. Like some previous poster mentioned about First line support, it's far easier to adopt the habit of quickly leaning on someone to find a solution, than searching yourself for an answer. Sooner or later, in the contracting world I have seen, such contractors get the kick after the first month of "leaning".

jury still out. he just asked me about an issue his direct colleague on another site is the expert on, there are docs I put up 4 years ago in the help area I showed him last night.

was sorting out usb hard drives for him yesterday so very nervous.

give him a month and see how we get on.

[bobspud]

Not my impression.

Think you should take a look at these guys...

Platige Image

I would not want to be in graphics design would in Soho when the advertising market get a handle on what they can do and for how much money...