Fog Creek Software
Discussion Board

"Bob" the Useless Tester

In the vein of many previous "what do I do about my coworker" threads, I'm curious what good advice you all can give me about this one.

I work for a small company.  Of our technical staff, we have five programmers, one person who tests and writes documentation, one person who does on-site installation and phone support and geek-of-all-trades.

I'm not in charge of anything or anyone officially, but effectively my hat is senior dev interested in process improvement.  (I sometimes stop coding to do Joel Test stuff like set up a build process or a bug tracking database, or more specific stuff like organizing our test data.)

We have the classic "throw it over the wall to testing with no explanation" policy about being done with things.  Most people here don't tell Bob anything.  I'd blame them, but I've been trying, and it's like talking to a brick wall.  I explain how the server works, but that just doesn't lead to any demonstrated understanding or creativity on Bob's part.  If I want something tested, I have to describe exactly how to do it.

Bob is a very nice guy.  He's very agreeable, except for the clueless "please take this away from me, it's too hard" mask.  And I know he's very intelligent.  He can totally kick my ass at a game of RISK, for example.  On the other hand, what he's done here *IS* pretty intelligent from his perspective.  He has a job (finding bugs) that no one really wants him to do well, so he doesn't.  And he doesn't even have to do it himself, he's got me doing it for him!!

Anyhow, I'm very frustrated at the whole system (the developers pretend Bob is going to test their code, he doesn't, bugs aren't found, etc.) but don't know how I can improve it.

Wednesday, August 6, 2003

Fire Bob. Hire someone competent.

Tim Sullivan
Wednesday, August 6, 2003

Tell him to read a book like _Testing Computer Software_ by Kaner, Falk, and Nguyen.  I am merely offering this book as a recommendation, but by no means wish to get into a discussion regarding good/bad software testing books.

If he still doesn't get it or doesn't care.  Then, I'd look at getting someone new.  I know you aren't the one in that position, but possibly escalate the situation to a superior.  If you still find that you're the only one that cares about the issue, maybe that's telling you something about your job.

Wednesday, August 6, 2003

You really need a manager who understands people. What is really going on here?

Wednesday, August 6, 2003

You have not made the case that either "Bob" or yourself is intelligent. Assuming by RISK you mean:

all intelligent people outgrow it by the time they reach university.

If you can not win a reasonable percentage of games then you are mentally retarded.

If "Bob" wins an extraordinary percentage of games then he is a consumate politician.

On the evidence presented I am not suprised that "Bob" has tricked you into doing his job for him.

Anonymous Coward
Wednesday, August 6, 2003

Looks like somebody let that last poster in from Slashdot...

Andrew Murray
Wednesday, August 6, 2003

>> He has a job (finding bugs) that no one really wants him to do well, so he doesn't. <<

This seems like the key to me.  Why wouldn't you want a tester to do their job well? 

I'm guessing that replacing Bob won't help much because it seems that Bob is doing what he's there to do -- pretend to look for bugs.  Someone new might be motivated for a little while but will quickly learn that "no one really wants [him/her] to do well" and thus won't.  When no one wants bugs to be found, it's a problem with either management (see no evil, hear no evil) or programmers (they want to get away with writing crappy code), not with the testers. 

I want testers to find bugs in my code because I don't want bugs in my code.  It's like someone who thinks they are good at a given sport going out and looking for others to compete against while someone else acts like they're the greatest while never leaving their armchair. 

Wednesday, August 6, 2003

Sit down with Bob and make three things very, very clear:

1) The current testing is inadequate.

2) This is a shared problem; it's a breakdown in process that is not wholly or even largely Bob's fault.

3) It's Bob's problem to fix.

Tell him you expect him to research testing strategies, do a gap analysis between the current setup and industry best-practices, and come up with a plan to improve testing, including some baseline metrics to measure improvement in both the test process and the software. Give him a deadline for a draft - make it clear he doesn't have the time or pressure to write the 100% be-all-and-end-all test strategy doc. After the meeting, reiterate what was covered in an e-mail (this is very important). Make sure he knows you will offer any reasonable assistance -conferences, budget for tools, etc. Make sure he knows his document will be passed on for review by all stakeholders.

If he's as smart as you say he is, he will leave work totally jazzed that you have given him the opportunity to fix all the things he thinks is wrong with his job and the company's software. If he's not, you've put him on a short leash and have a framework for documenting non-performance in an open, straightforward manner.

In short, you want to do two things: recognize that self-organzing teams do the best work and establish that working software is the primary measure of progress and success.

Jim S.
Wednesday, August 6, 2003

I just wanted to comment that I love the name "Bob the Useless Tester"


Wednesday, August 6, 2003

"I'm not in charge of anything or anyone officially, but effectively my hat is senior dev interested in process improvement."

You need to voice your concerns to whoever is in charge (that doesn't mean some supposed "senior" person, but someone with the authority to hire/fire).  Since you have a title and no authority and  "Bob" does not report to you, trying to talk to him about his performance will do very little, if anything it may make your situation worse. 

Since you like Bob, instead of being a tattle-taler, you may want to offer some suggestions to your boss on how to improve the current testing procedures.  Show your boss where the holes in the testing procedure are, and offer suggestions on how to fix them (or how 'Bob' can fix them).
This can be a possible win-win for you, 'Bob' does his work more effectively and you keep the peace.

Wednesday, August 6, 2003

"On the evidence presented I am not suprised that "Bob" has tricked you into doing his job for him. "

Anon. Coward,

I don't think any trickery is involved here.  Mikayla seems to care enough about the quality of his/her work and willing to go beyond the call of duty (even if it means doing someone else's work).   

Wednesday, August 6, 2003

In my opinion, a throw it over the wall philosophy when it comes to QA is a disaster.  Developers must be ultimately be responsible for clearing bugs before it even gets to testers.  Testers must know what they are looking for and developers should be able to explain what situations could be "high-risk" areas to stress test.  If an obvious bug makes it to testers I consider it a black mark against the developer.

So while Bob is probably not doing his job well, it sounds possible to me that he is just participating in a department wide abdication of responsibility for solid code.  In that case it may be easy to blame Bob since he is a focal point of the problem, but make sure you aren't just scapegoating him for a problem that exists across the whole team.

Richard Kuo
Wednesday, August 6, 2003

Oh, and I missed the part about him being like a brick wall.  If he's really that dumb and it's contributing to the "over the wall" philosophy, then you definitely should fire him now before he wastes any more of your time and focus on hiring someone smarter.  Since you are a smaller company, maybe you might even take turns doing QA so the team has an appreciation for the process until the position can be filled again.

Richard Kuo
Wednesday, August 6, 2003

Does Bob catch grief from the higher-ups when bugs get through testing, or is it "all the programmers' fault".

If he doesn't, he should - it's a shared responsibility.

Andrew Reid
Thursday, August 7, 2003

Maybe he simply isn't being tested enough (no pun intended). You say he is intelligent - maybe he simply finds the work he is asked to do to be so damn boring, or that his input was not valued, that he switched off a long time ago. What about asking him how he would improve the quality of the process? Somehow get him to engage. Of course, I'm always willing to believe the best of people, maybe he's just an ass.

Thursday, August 7, 2003

Its called being a Jobsworth, which includes 'that'd be more than my job's worth mate' but which also includes 'I turn up, I do what they tell me nothing more, they aren't interested in anything I do, I get paid, what more do you want?'

Being intellectually interested in the work that you do and wanting to improve the quality is a corollary to being empowered to change and improve things. 

The original poster is so empowered, Bob, for whatever reason, isn't.  I would guess its that no matter what bug he finds, he, Bob, can't call it a showstopper or prioritise its importance, still less he probably can't close a bug.

Empower him, if his motivation is such that he's really not interested then he may have to be reassigned or let go.  However, if someone assumes that his behaviour is solely his own responsibility then they haven't recognised that its the company and its culture which created his attitude in the first place.

NB, I've made a mountainous amount of assumptions in all that.

Simon Lucy
Thursday, August 7, 2003

You can't "empower" someone.  They have to empower themselves.

Joe AA
Thursday, August 7, 2003

Ummm Joe, no.

Its called management.

Simon Lucy
Thursday, August 7, 2003

Perhaps you should tell us more about "Joe the Useless programmer" who throws buggy code over the wall at Bob?

Does Joe make Bob feel like a shmuck every time Bob finds a bug?

Or maybe "Helen the Useless Vice-President" needs correction.

Didn't she appoint a Senior Dev who has no real authority and no accountability to wander around trying to 'improve' things even though there seems to be no objective standard to performance by the team?

Sorry, that's all very tongue-in-cheek, but what you describe sounds deeply systemic to me. If your team was healthy and Bob was the fly in the ointment, wouldn't you have developers complaining to you about his attitude?

Reginald Braithwaite-Lee
Thursday, August 7, 2003

As far as I'm concerned regarding management empowering people, all they can do is place people in a position/environment where they want to, and do, empower themselves.

Thursday, August 7, 2003

reminds me of a song...

"Bob the useless tester"
lived by the sea...


Thursday, August 7, 2003

'"Bob the useless tester"
lived by the sea...'

Lived by the sea? I thought Bob lived in a van down by the river!

Synonymous Blowhard
Thursday, August 7, 2003

Sounds like everyone has their heads stuck in the sand about the reality of the situation.  Which usually means nobody wants to touch the 'real' problems, for whatever reasons.

Here are some suggestions:

1) Sit down with Bob and have a frank and solution-oriented discussion centered around a part of the problem that he can do something about (i.e. is part of his job responsibility).  State the current conditions as you see them, without putting and responsibility/blame on people.  Just a "this is how things are" statement.  Ask him for ideas on how to solve the problem.  Do this same thing with other people on the team.  Take an attitude of "Gee, I've noticed we do _this_, and I think we can do better, but I'm just not sure how.  Any ideas?"  Engage your fellow engineers' desire to apply their problem-solving skills and natural human desire for approval.

2) Talk it over with your manager.  Ask him/her for ideas on how you and he can approach the problem together.

3) Involve Bob in development.  Ask him questions about what you can do to make testing go better/easier.

4) Stop throwing things over the wall.  Accept the reality that Bob doesn't test, do all the testing yourselves.  When someone asks why you haven't released to test in a while, explain.  Let the natural consequences take their course.  (Be sure you can document Bob's uselessness.)

Good luck with it.  Let us know how it turns out.


Thursday, August 7, 2003

1. Come up with solutions to the problem.

2. Wait until a situation comes up where the problem is obvious.  (Or create one.)

3. Call a meeting with your boss.  Say "I don't want to get personal, because I think the problem can only be solved systemically." Present your solution.

Contrary Mary
Thursday, August 7, 2003

Insert a bug that he should have caught. When he
doesn't. Well...

Thursday, August 7, 2003

Empowering people to do their job better is a part of motivating people (oh you're all self motivators hmmm).  It takes more than just giving someone a title, a job description and hey just do it.

It requires support and  whoever it is has to know they have the ability to make decisions that make sense in their work and that can affect other people.

All too often someone is sitting in a job knowing more about what they can't do and can't affect than they know about what they can do and what effect they can have.

Everyone is part of QA, or nobody is.

Simon Lucy
Thursday, August 7, 2003

Wouldn't you know it, I post something like this and then end up out of the office for a day and don't catch up with it in time.

It's interesting how totally on target most of you were.  Pretty good job of interpolating the environment, history, and the existence of Helen the useless VP and Joe the useless programmer (whose arrogance may very well have sent Bob into defensive mode in the first place).

To correct misconceptions: I did say I wasn't officially anything.  It's a small company, and among the positive aspects of Helen the useless VP is letting us all make contributions in our area of interest as long as we clear them with her first.  Our other developers have interests too: Web services, file format design, and cryptography are the ones I can think of off the top.  Mine are just less code related than most.

Probably because I've come to prioritize getting the job done.  Doesn't matter if "my part" is done if the whole thing is crap.  I've been partly responsible for enough shelfware in my life, and I have to look at the bigger picture if I want to change that.

I certainly want Bob to do his job well.  I try to be encouraging, supportive, appreciative, etc. when he does.  It's possible that my attempts in that direction aren't enough to offset Helen and Joe and the weight of history yet.  One thing I probably should try is talking with Bob on a more friendly level rather than the coworker level, and see whether I learn anything that way.

I wouldn't feel comfortable talking to Helen without talking to Bob.  I'm not sure I feel it would be useful anyway.  Helen is one of those "nice" people who doesn't realize that helping someone move on to a job they actually like and are good at, or a company that suits them better, is probably a bigger favor than any other.  *sigh*  And the negative effect on the rest of us...I don't know if that's something she notices or not.  Hiding in the corner office all "tra la la la la, I have a corner office" doesn't tend to produce much insight into what's really going on out here.

(I was also very amused by the troll who thinks I should be better at RISK.  Granted a lot of engineers have that kind of strategic "good chess player" intelligence, but not all of them do.)

Sum-up is probably Richard's: "a department wide abdication of responsibility for solid code."  This is the part that nags at me.  I like the people here, like the fact that I can make changes.  I hate the fact that I figure a place out, can't change it, and quit a year or two later.  I don't want  to do that again already -- but if I stay, I'll end up becoming a part of the problem.

Friday, August 8, 2003

I don't think anyone has mentioned the book "Creating a Software Engineering Culture" by Karl Wiegers. It's written from the point of view of a team leader or project manager who wants to develop an engineering culture within their software development team. If you have enough influence and/or can team up with other influential developers, you may be able to use some of the ideas in that book or use the book as a reference for "how we should be working".

Good luck to you!

Friday, August 8, 2003

Have Bob call me, I'll straighten him out.

  The relationship between test and dev is a love hate thing. Dev hates QA for finding 'flaws' in their work.  Dev loves QA for finding that catastrophic bug which didn't make it to production (thank God!).  It appears to me that everyone including BOB, excluding yourself doesn't see the value in testing. Does everyone in your small organization understand the costs associated with letting bugs get by through each phase of the Project Life Cycle?  Are there metrics that prove the value of testing for each project? Are they aware of their defect rate? Is Bob testing black box test cases with a user interface? Or is he testing white box tests on a headless app? Many testers are perceived as bottom of the barrel, low man on the totem pole.  With that stigma, it is difficult to stand up to, question, etc the 'elite' developers. Bob needs to get a backbone and tell you exactly what he needs from you to perform his job. If he knows anything about testing at all, he can write a test plan as long as he has a requirement and a design.  Now, executing that test may be a difficult task.  If the design says

If X happens, then take Y and add P to it, Bob should be able to write a test case.

1. condition: X happens.  Expected result: YP
2. X doesn't happen. Expected result: Y

The developers can review or walkthrough the test plan with Bob and decide whether or not it is 'feasable' to have Bob execute the test or a developer during unit testing. If the expected result is in working storage or stored in a database behind the scenes and Bob doesn't have the competency to write a sql statement or debug code, then you do it!  If the expected result displays on a nice clean GUI dummy proof interface, then Bob can execute the test.  Bob can still add value by defining the tests for you.

Bob needs some props and some good formal testing methodologies to follow which will help him whether he's testing a simple line of code or writing a test plan to test a missle guiding system or the hubble space telescope.  Give him requirements, a design and a good book with formal test methods and he should be good to go.

Someone needs to make it clear to Bob that his job is to ensure quality, not make friends - which it sounds like isn't happening anyway.  In the end, he may still not be popular, but he will be the unpopular team member with respect from his coworkers, which is better than being unpopular with no respect.

Friday, August 22, 2003

*  Recent Topics

*  Fog Creek Home