The end result of bobville, you'll never retire

[eek]

Even more when you discover you can get a decent logo for £3.50

How to get a professional logo for £3.46 | Econsultancy

[Mich the Tester]

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.

Good that you're aware there's a problem and here's what I think can help;

- never assume; it makes an 'ass' out of 'u' and 'me'. Alternatively 'assumption is the mother of all ****-ups'

- some techies (I sometimes make this mistake too) gloss over details that for them are obvious, but for others may appear quite difficult, like 'you need to do a pull from git and then bla bla; don't assume someone else knows how to do this

- some techies, and this is really irritating, think that if someone else doesn't know how to do something they find simple, then that person is somehow dumb. He isn't necessarily dumb, but just needs a little help on that subject. Perhaps the most intelligent person I know doesn't know how to copy and paste a file in the windows explorer. He's an author who's written some critically acclaimed books in Holland, and his knowledge of the world and his understanding of the human condition far surpasses mine. Likewise a local catholic priest; I'm not a believer, but I've learnt a lot from just chatting with him in the pub about human nature.

- among testers there is a huge variety of backgrounds, but what should unite them is critical thinking, an ability to ask probing questions and some conceptual understanding of technology; they will usually have some practical techy skills, but they can be very varied. I was a DBA/Database Dev before testing, so I know a fair bit about SQL and procedural SQL, relational database models, data relations, logical relations between lumps of information and how to analyse the meaning of some piece of data, etcetera; that doesn't mean I know anything about Python, Hadoop or any of the other cool new technologies. One of the best testers in the world is Cem Kaner. A brilliant man who can rip almost any application apart with exploratory testing, provides excellent training for testers and he has contributed an enormous amount to the testing field; he's not a techie; he trained as a lawyer. See that? Critical thinking is what made him succesful, not a gift for technology.

- Always remember how incredibly privileged you are to be asked to share your knowledge on some subject. There are hundreds of millions of people who are never asked to do that; they are wrongly seen and treated by their employers as human donkeys with a strong body and no other value than the ability to shift heavy objects from one place to another. When they eventually lose that ability, they'll be replaced with a younger body and left to find some way of surviving. Think of Boxer's role in Animal Farm and be glad that that's not you.

- One last thing; there are no stupid questions, but there are stupid people. Stupid people can get smarter by asking questions. Remind yourself, when faced with a question that you think someone shouldn't need to ask because you think he should know anyway; if I help him with his question today, tomorrow he'll be less stupid and just a bit smarter. If I don't help him, then tomorrow I'll have to deal with that stupid guy again; that makes you stupid.

[tranceporter]

Good that you're aware there's a problem and here's what I think can help;

That's all true, but one if the things I dread is when "intuitiveness" of the front end is handled by the QA. I have seen this happen before, and some testers love to take on the role of an "accessibility expert", when he cannot find any serious bugs in the system. "Xyz functionality is working great, but I simply cannot understand the layout. Why can't you put this button here, and the drop down here?" says a critical bug. This is one of the common issues I have seen where QA and developers start working against each other, because such bugs involve the business, and whole gamut of people you would not want to involve, coz they don't have an effing clue about what's happening, but hold the funds and care only about the timeline. Soon it escalates into a cluster**** of issues, where the same page is designed and re-designed 10 times, and as a developer, I lose interest. IMO, design of websites should be initially for UI specialists, and then left to actual end users of beta testing, to complain about lack of intuitiveness.

[cojak]

I've finished a very successful contract where Agile and off-shoring together restricted the creativity and curtailed the ability to get things done outside of the (poorly) deployed Agile teams.

I think that this could be a very profitable route over the next few years if I can package it without insulting the hiring client.

'You need me because you're too thick to implement Agile properly' may not win me too many contracts.

[NotAllThere]

- some techies, and this is really irritating, think that if someone else doesn't know how to do something they find simple, then that person is somehow dumb. He isn't necessarily dumb, but just needs a little help on that subject....

As a techie, the ones that bug me are not those who don't know how to do something, but otherwise intelligent people who just can't be bothered to learn and want spoon-feeding.

Thickos I can deal with (which is why I get on well with the testing team ).
Lack of knowledge - no problem.
Deliberate pig-ignorance...

[OwlHoot]

Good that you're aware there's a problem and here's what I think can help;

- some techies (I sometimes make this mistake too) gloss over details that for them are obvious, but for others may appear quite difficult, like 'you need to do a pull from git and then bla bla; don't assume someone else knows how to do this

It's more than about simply regurgitating sufficient details - You need to be aware of what the other person doesn't understand, which can range from the whole thing (obviously, if they're new to it) to just a single sticking point.

Psychopathic personalities, who lack empathy, find this terribly difficult. They just blindly parrot their own understanding, regardless of what the other person finds hard to grasp, which may hinge on one small misunderstanding or missing piece of the jigsaw, as the explainer would realise if they bothered listening.

[Mich the Tester]

Psychopathic personalities, who lack empathy, find this terribly difficult. They just blindly parrot their own understanding, regardless of what the other person finds hard to grasp, which may hinge on one small misunderstanding or missing piece of the jigsaw, as the explainer would realise if they bothered listening.

whs

Listening is a skill.

[mudskipper]

whs

Listening is a skill.

Sorry, what?

[The Spartan]

That's all true, but one if the things I dread is when "intuitiveness" of the front end is handled by the QA. I have seen this happen before, and some testers love to take on the role of an "accessibility expert", when he cannot find any serious bugs in the system. "Xyz functionality is working great, but I simply cannot understand the layout. Why can't you put this button here, and the drop down here?" says a critical bug. This is one of the common issues I have seen where QA and developers start working against each other, because such bugs involve the business, and whole gamut of people you would not want to involve, coz they don't have an effing clue about what's happening, but hold the funds and care only about the timeline. Soon it escalates into a cluster**** of issues, where the same page is designed and re-designed 10 times, and as a developer, I lose interest. IMO, design of websites should be initially for UI specialists, and then left to actual end users of beta testing, to complain about lack of intuitiveness.

Hahaha you'd hate me then I love to raise accessibility issues and problems with the design though I do log those as feature requests. Not all of them are taken on board due to timescales but I've had more implemented than were thrown out so I must secretly know what is better for users