After some discussions with folks on the testing/QA side of our company, we're of the opinion that better unit-level testing by developers would greatly reduce bugs and issues and help development overall. However, developers (and dev management) seem a bit resistant, with the usual reasons ("Too much code!", "We don't have time!"). However, I think it'd be a worthwhile effort and I'd totally be on board to help make this happen.

What can a non-developer to do to help promote writing unit tests? Any suggestions for technical and/or social approaches to this problem?

Questions of the form "How do I convince [boss/colleague/customer] to [do something]" have not fared well on this site. I recommend the book Getting To Yes. If you have a more specific question, that might be a good fit.
–
Aaron KurtzhalsMay 24 '13 at 16:00

I agree that unit testing ought to be done. But that burden really belongs to development and can't fully be moved to QA. So if you can't convince it to happen in dev, your next best bet is to do as much automated testing at higher levels (integration, component, system, etc.) as you can.
–
AllanMay 24 '13 at 16:28

Are you sure the crux of the problem is unit tests?
–
mike30May 24 '13 at 17:49

2 Answers
2

meaning that some investments will have to be made before the returns can be gotten.

The same is true for unit testing.

Your mileage with unit testing may vary when it comes to the rewards that unit testing might yield. Improvements in quality of code will only come after a few development cycles, but the dev department still has to account for the loss of productivity until people get used to doing it. Besides that, if you're really under pressure, you'll likely skip doing them under the guise of some lousy argument or ease the test so that it'll pass in most circumstances.

I'm not opposed to unit testing, not at all.

There is however the issue of writing 30-70% extra code if you intend to do the testing properly, which does take extra time. It remains to be seen if that amount of time can be gained by not having to repair the bugs. It certainly will not mean an instant productivity increase. On the other hand, unit testing is a proven means to improve quality of code.

The way to promote unit testing is to convince the general management, and let them deal with the decision.

@gnat: Done. better this way? Proper paragraphing is also something that counts, even if that means the product will be "a wall of text".
–
OnnoMay 24 '13 at 16:15

1

@tomfanning An answer that's hard to read isn't a particularly useful one. Check Onno's edits, isn't the answer much better now? Also, no one downvoted this, please don't assume that a comment that may be a bit critical is coupled with a downvote. More often than not that's not the case.
–
Yannis Rizos♦May 24 '13 at 18:50

I just didn't think it was hard to read at all. Also, it was sat at -1 when I made my comment.
–
tomfanningMay 25 '13 at 14:36

After some discussions with folks on the testing/QA side of our company, we're of the opinion that better unit-level testing by developers would greatly reduce bugs and issues and help development overall.

You have a QA team already. testing is a QA function. Unit testing by developers is a build function. The practice is that the automated unit tests done by developers verifies that the current build is stable, before it moves onto QA. There is no logic I can see where a successful built translates to a reduction in bugs discovered by QA.

The benefits of unit tests by developers are as follows:

The package delivered to QA will not be returned to developers, because it failed to deploy.

An issue closed by a developer is not reopened because the fix was faulty.

Regression of stability where old closed bugs are reopened.

If you are seeing of lot of the above occurances from QA, then you need to improve your testing and build processing at the developer level.

Functional testing and feature testing is what the QA team is for. They take the build from the development team and verify everything is working using automated test methods. When they discover something the build is sent back to development.

However, developers (and dev management) seem a bit resistant, with the usual reasons ("Too much code!", "We don't have time!"). However, I think it'd be a worthwhile effort and I'd totally be on board to help make this happen.

Try going to your neighbours house, walking inside and tell them their home is dirty. You won't get a positive response from them.

The development team should be treated as a group who are responsible for making a delivery. That delivery is the build. It should be a packaged piece of the product that they hand over to QA. Focus your efforts on that.

When they finish a build. Tell the development team you will start tracking the following points. When their team comes up for review these points will be used to aid in their performance.

Are builds sent back from QA because they were incomplete or failed to deploy?

How many times do QA re-open issues closed by a developer.

How often do closed issues from a previous issue get re-opened.

How many iterations of DEV to QA to DEV take place before a version is stable enough to release.

Once you force development to be accountable for the above issues. They will have no choice but to start unit testing.

If the above issues are not a problem, then what they are doing. Weather or not they unit test. Doesn't need to change. Let them have control of their own domain.

What can a non-developer to do to help promote writing unit tests? Any suggestions for technical and/or social approaches to this problem?

I once had a guy come to my desk and ask how come it took so long for the servers to migrate data from one database to the other. I said, each database is over 100GBs in size it simply takes time. He said to me "Why don't you Zip the files first."

Don't tell people how to do their job unless you know what you're talking about. I'm not saying you're wrong to recommend unit testing, but they could be neck deep in legacy crap.

Instead, tell them they need to make better builds. If you hired the right people, then they will make the right decisions.

If they can not make good builds on a consistent basis, then you have a problem with the development team as a whole. Upper management needs to sit down with human resources and make some tough decisions. Hire new development members who can improve the team, or let go of those who are weakening the team.