I'm the guy who is motivated to bring some quality assurance into our team. The problem is, that our developers very often hate testing and even if they have a test protocol, not all of them are really testing. Very often they are asking their colleagues instead of testing themselfs where the bugs were and practises like this. They are very often not very interested to do a good job.

This is of course a general problem and they could got fired for such an attitude. But in really things aren't as simple as this.

My question now is if there are clever tactics which prevent them from cheating. I would let some random errors occur for each tester to prevent it, but as they are the developers its nearly impossible to prevent searching the source code after this errors. Another idea would be to offer a reward for the person who found the most bugs. Or don't let multiple people test the same things (but this reduces the quality of the tests).

What are your clever suggestions to "force" the developers to really test and give them no possibility to cheat? Funny tactics are of course welcome too...

In my situation the application is written in PHP and the developers are the testers too (same persons).

Rather than trying to force "more" testing, have you tried simply holding them accountable for the resulting code?
–
Joe StrazzereSep 26 '13 at 16:17

They had to sign the testing protocols in the past, but the company needs them to much to force hard punishments. Beside this I'm searching for positive conditioning than creating more pressure as alreays exists.
–
AndySep 26 '13 at 20:37

6 Answers
6

As user246 says, tricks to force developers to test can always be gamed: you're much better off finding out why they don't like testing and what the actual problem is then building a culture of testing and quality from that.

You're working in PHP - there are unit test frameworks available for PHP that your devs can use. If they have no idea how much trouble testing can save them, that's where you get to evangelize. I'd suggest for starters working up a smallish project with some unit tests, and then refactoring it - use it as a demonstration of how well-designed unit testing can help save work: if you know you'll find any change that breaks existing features the moment you compile, you also know you can safely refactor and extend your system.

Some other things that can help:

When they gripe about something not working, or talk about games they play (there's almost for certain at least one gamer in the team), see if you can feel out the way they respond to bugs in software they use.

Google "Maybe they should have tested more". I guarantee you, your
developers do NOT want to find their application on that blog!

Be tactful. If you're obnoxious about it, you'll get resistance and sabotage. That's just human nature - people don't like feeling that someone is railroading them somewhere they don't want to go.

Make sure that you're creating unit tests and testing your work. If you're modeling the things you want the rest of your team to do, that's always a good start. From that, you can drop the occasional seed comment in, such as mentioning offhand how that last enhancement was so easy because you had all those tests to tell you as soon as you broke something (don't overdo it - mention it once then leave it for a while: let them come to you).

In general, you'll have a much better chance of building a culture of quality if your team wants to build it and thinks it's their idea. In the meantime, try not to get too frustrated: your team most likely sees "testing" as something any trained monkey can do and something that takes away from their main purpose.

Google "Maybe they should have tested more". Or try "Perhaps they should have tested more", too.
–
Joe StrazzereSep 26 '13 at 16:18

@JoeStrazzere - I'd forgotten the "Perhaps they should have tested more" one. There are some SCARY things that come up when you Google those phrases
–
Kate PaulkSep 26 '13 at 18:32

lol I had to laught. Thanks for the good advices. The scary thing is the self developed private framework and the application is huge. They had started with united testing but then time ran out and they focused on the developement itself. My target is now to get more quality into the whole thing. Because of this I've talked with all devs about what they want to change and told them I'm open for every constructive input. Next to this I've personaly started with Selenium to do functional testing. But there is also manual testing needed where I want ensure quality.
–
AndySep 26 '13 at 20:28

@Andy - that's usually how it goes. Unit tests and any other kind of testing gets dropped as soon as there's a time crunch. The problem with that is that if you don't take the time to do it right, you will end up taking the time to do it over whether you have it or not.
–
Kate PaulkOct 1 '13 at 11:27

@KatePaulk that's the reason why I pushing unit testing since years, but its hard when the management doesn't see the middle-long term time savings.
–
AndyOct 1 '13 at 14:47

Good luck with that. Your developers are probably bright enough to subvert any gimmick or incentive you put in place. Instead, you need to face the problem head-on: testing needs to be a part of your organization's culture. That's not to say that every developer needs to love testing, or needs to prefer testing over development. Rather, developers need to know and believe that finding and eliminating bugs is just as important as every other aspect of their job. If they do not believe that finding bugs is important, their product will fail and their careers will fail too. It is that simple.

If you agree with that, then the question becomes, "How do I promote a culture of testing?" You need to show developers how the testing process impacts their success. Show them what's happening to the bug backlog. Give them some examples of how your product is at risk of failure because of its quality. Measure how much time is spent in testing, then talk about how much more work your team could do if you could finish testing faster by having everyone chip in.

You might also ask them why they aren't interested in doing a good job in testing -- not in an accusing way, but in an inquisitive, open way. It is possible that they like (or at least tolerate) some kinds of testing and not others. Or they might dislike testing because they don't really know how to test. You won't know unless you ask.

Thank you for your advices. You're completely right. They have a hard time behind them and I want to provide my part. I've talked with all of them and start automated testing with Selenium myself. I hope I can change the atitude of them and providing them with tactics which work. That's the reason why I'm searching for creative ways to ensure the quality and motivate also because there is no simple way to cheat on stuff like this.
–
AndySep 26 '13 at 20:34

Dale, is your position that the rest of his developers don't need to test -- and shouldn't be asked to test -- as long as they provide Andy with enough/the right kind of information?
–
user246Sep 28 '13 at 19:18

Well, they might not need to test, depending on the information he needs. But if he needs information that can come only from testing, they'll have to test in order to create the information. But my point is: Don't ask them for the work. Ask them for the valuable result. It's easier to tell whether you're getting it. And they'll better understand the value of what you're asking for, which may offer better motivation than sticks and game-able metrics.
–
Dale EmerySep 28 '13 at 22:57

That's exactly my way. I try to capture their needs, give them the most comfortable testing-environment and talking with everyone to ensure they know how important their work is. Next to this, I'm providing my own part so they can keep in mind that I've to do such work also and we're improving the whole thing together.
–
AndySep 29 '13 at 8:56

How do you know this? Just because they are asking other programmers where the problems are? While this isn't a holistic strategy it's not a bad way to find well understood problems.

They are very often not very interested to do a good job.

How do you know this? Perhaps you haven't communicated what a "good job" testing means? It's entirely possible you and your developers don't see eye to eye on what you mean by testing. Perhaps they see their approach as being good? Does the organization have a common understanding of what testing means? What quality means? What you consider a bug / issue, etc?

Trying to apply some new formal testing in an organization that's never had it, without a skilled, dedicated resource requires some strategy and influence. Chances are your developers don't know what testing is and think unit tests are as far as they need to go.

My advice:
Think about what you want to see with regard to a testing strategy, then figure out what areas your developers can reasonable do given their current set of knowledge and skills. Then work on expanding that current set of knowledge and skill until they can gradually fit your test strategy.

Another idea would be to offer a reward for the person who found the most bugs.

An approach like this will likely lead to gaming the system where large numbers of bugs are filled but the most important, critical bugs that take days to isolate and report will be left in the system. You are basically asking for low hanging fruit - really shallow testing.

Or don't let multiple people test the same things (but this reduces the quality of the tests).

How do you know the quality of their tests are any good? Do you review their tests and testing strategy with them? If not this might help as well.

Please don't get me wrong. I'm not their boss nor I have a trust problem or something like this. A few of the devs themselfs told me for example they didn't complete the whole testing forms and only asked other guys from the office about the bugs to skip the testing task. What I'm searching aren't punishments, I'm searching for creative ways to get a little bit more motivation and ensure that the testing tasks are REALLY completed. I'm only the guy how tries to make the best out of his time and ensure better QM what we all benefit from. They are good devs but hate to do manual tests.
–
AndySep 26 '13 at 20:19

1

Devs usually hate to do manual tests - and forcing them to do them is usually a waste of a good developer. Unfortunately, if you don't have dedicated test specialists, that's what you're stuck with.
–
Kate PaulkOct 1 '13 at 11:22

Testing is a motivational issue. For most programmers it can become a unbearable threadmill. I have heard that a irrelevant positive reward, like a free beverage on finding an error, can help. It is not so much the reward, as well as the game mode.

In general look for means to diminish testing. Otherwise good developers will leave, and such. Switching to TDD, Test Driven Development, can be such an incremental solution. It needs organized code and data though, but that adds to the software quality. One writes small unit tests, which serve as regression tests later on, when code is changed.

Typically a data model, listeners for changes, actions and so one is done. Specific parts are emulated, like the selection of an HTML select box.

I've voted for a long time for TDD and they started with it. Because of very unconfortable deadlines they stopped it. But I try to get back on the TDD path. But for the moment I'm primary searching for the best way till we're back on this road.
–
AndySep 29 '13 at 8:59