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.