Engaging Developers in Unit Testing
Our overarching goal in agile and DevOps is to deliver increments of customer value more quickly with acceptable quality. In doing so, we employ many approaches and techniques to verify requirements, designs, and code at every step in our software engineering methodology.
One key practice in driving early defect identification is unit testing, but several organizations and teams continue to be challenged when it comes to designing and implementing unit tests.
A question I continue to be asked is how to engage developers in this respect. The difficulties usually include poor build quality, later-stage defect identification, and increased rework, which all slow the delivery of value increments to users.
Traditionally we’ve approached testing, manual or automated, from the UI perspective, so teams usually have more UI tests than unit tests as they begin their agile journey. Driving testing to lower levels of the application or system under test results in earlier defect detection at the structural levels of the code and easier defect identification and repair due to decreased complexity.
Of course, comprehensive unit testing does not eliminate the need to test at higher levels, but it contributes significantly to reducing rework delays and improves predictability in our sprints and releases—whether tests are written first, as in a test-driven development approach, or unit test are written after the code. Unit testing adds significant value.
Here are some suggestions for how to instill a unit testing culture.
First and foremost, leadership must value testing. They should nurture and support a culture of testing early and often for continuous feedback. That means there must be a balance of speedy change or feature delivery to code quality, and developers must be given the time to design and implement sound unit tests.
The goals and incentives for individuals and the team also must be aligned. If developers are goaled on “more code faster,” the first thing to go will be good unit testing. Recognize and reward developers and the team on great unit testing practices.
And answer the WIIFM question: What’s in it for me? Communicate the benefits of unit testing and highlight the consequences of poor unit tests through quantitative metrics and root cause analysis.
Also provide training for developers in efficient and effective unit testing techniques and approaches, and ensure developers have the tools they need to design and implement solid unit tests. Few of us were formally trained on testing during our university years.
Set guidelines, requirements, standards, or norms so that the accountability and expectation of conducting unit testing is clear. For example, specify change and feature submission criteria that includes unit testing prior to and during the build.
Finally, conduct code reviews, practice paired programming and unit testing, conduct static and dynamic code analysis, and track the key metrics from these methods and tools to determine the effectiveness of unit testing. When downstream defects are discovered, understand the root cause and investigate whether additional unit testing may mitigate these downstream risks.
I’ve not yet met a developer who purposely inserts defects in code. In my experience, realizing a culture of sound unit testing is more a leadership challenge than a developer one.
In order to discover defects early I would sugest to perform first Requirements review. this technique is very effective and much cheaper than testing. Poor Requirements will for shure couse defects and troubles during the whole SDLC.
Regarding how to ingage developers in Unit testing it"s very simple.
Define the process of coding by saying that coding is not done without documented Unit testing.
Unit test documentation should be very simple, each test should be documented on a simple form containing the following information: what is the purpose of the test, SW Version/Build/Sprint , date of test execution, test environment, what is the I/O ' expecte results and actual results. Each test form after test execution should be signed by the person who performed the test. In addition In addition a cross reference matrix between requirements and test should be maintained also. SQA should review and approve test execution documentents regarding the validity of the performed test and completness of the testrequirements matrix.
Only after those approval the coding of the Build/sprint is consider as done.
Defining and implementing such process could be a good incentive for the developers to perform Unit testing.