Allow me to give a suggestion: Make unit testing a part of every test strategy. Add it in with exploratory and tool-based techniques, but make sure you add it. Good unit testing allows you to explore products deeper, lowers your estimate, improves quality, and maintains productivity pace.

I don’t expect you to design or execute the unit tests, but having unit testing as an explicit part of your test strategy says you depend on it and expect it to help deliver quality products. 

When you discuss strategy, explore the multiple benefits of unit testing. It can:

• Evaluate basic functionality and requirements, allowing you to explore deeper and more diverse scenarios
• Reduce your estimate because the time spent evaluating requirements is now better spent in other scenarios. The time spent in requirements-based testing can be part of the development estimate
• Help you explore areas that are difficult for black-box techniques. The tester collaborates with the developer to probe those areas and reduce defects that are difficult to locate or reproduce
• Reduce defects to help maintain productivity pace

So, you may be asking: Why doesn’t everybody do it?

Unit testing can be one of those polarizing topics in software development. Many developers do not plan, create, execute, or record their testing. The ensuing defects erode their credibility, cause delays in projects, or cause focus to shift away from product development.

If your project is not seeing adequate unit testing, here are some thoughts on its benefits and ideas you can use to collaborate with developers.

Getting Your Team On Board with Unit Testing

For the purpose of this article, I discuss unit testing in the context of software development, and I think of unit testing as the same thing as development testing, low-level testing, or component testing. I submit that unit testing is any action a creator makes to check a change they made, and it is not necessarily automated. The unit test of a change can be a review or a demonstration of functionality—or, preferably, both.

Under this definition, notice that I don't constrain anyone to just source code. There are many files that are necessary for an application to operate successfully. The application file itself, component files the application may reference, configuration files that direct behavior, database files, schema files, and debug files work together to deliver functionality. Each of these files can be impacted by a change to the source files used to construct the application, so any change to any file is a candidate for a unit test.

Any change? you may be asking. Joe, if I change a single character in a configuration file, you are suggesting that a unit test is necessary?

Under my definition above, yes. But it depends. For me, it depends on who made the change, the scope of the change, and the context of the change.

Who made the change?
As you work with developers, you learn who creates good code and whose code may need more review. You can see this in the number of defects discovered and by listening to conversations between developers. Until a developer proves a certain level of competency in producing good code, I might scrutinize his code a little more. As a test lead, I coach testers along this line, too.

Similarly, you also assess a developer’s history in making changes and his familiarity with the products he changes to help determine the right amount of scrutiny.

What is the scope?
If a developer comes to me and says she made a simple change, I want to know what she means by simple. A unit test for a text change from “unit pest” to “unit test” might be a file comparison (i.e., before and after the change), where a change in the location of a database server might require a unit test demonstration.

What is the context of the change?
Finally, I want to know more about the context of a change. Production issues impacting customers require a brief but focused review. However, something discovered during testing or a drive-by demonstration may require one or more unit test scenarios.

Unit Test Documentation

The amount of documentation depends on the credibility of the developer and development team, the present defect rate, and code complexity. When the code complexity and defect rate are low and the developer produces solid code, I might have the developer demonstrate the unit tests. This can be completed at his desk. As those dimensions change, I might require a list of bullet points or something closer to a test plan. In that case, I target something that requires half an hour or less to create.

When our project’s defect rate nearly doubled over two iterations, I worked with the lead developer to have developers prepare for unit test demonstrations, to create better documentation, and to require unit test documentation before the code became available for test. Our defects decreased over the succeeding iterations. Because a demonstration and documentation were required, it helped the developer focus the unit tests to cover important functionality and improved the quality delivered to our test environment.

Unit Testing as a Collaborative Strategy

Unit testing serves to scrutinize new and changed products. The products are as good as the tests, so objectivity is encouraged. However, the level of the unit test is the real value. When a developer unit tests her changes, she demonstrates integrity. Her tests help her understand the behavior of the product. When she demonstrates a product through her unit tests, she improves collaboration. Two minds using the medium of the test to review product behavior creates a shared responsibility and shared outcome.

When she demonstrates a product to her business team member through her unit tests, she improves confidence. Demonstrating the basics helps the business team members trust her work, frees them to ask deeper questions, and makes them feel part of the solution. A clear, concise, and well-prepared demonstration helps business team members understand their product’s capabilities.

With an understanding of the basics, they can explore the product through questions or experiments. Being part of that conversation benefits them and your project team because they are helping to create a solution that fulfills their needs. As a tester, a strategy that includes unit testing facilitates that relationship, improves quality, and saves time.