Why Code Coverage Matters For a Quality Culture (Part 2)
How can contracted teams deliver on quality? Perception & Visibility are KEY!
Federico Toledo reached out to me and asked for my opinion about what consulting test managers are doing to show test coverage. This is part two of a two part blog post (here’s part one!). This focuses on contracted (consulting/outsource) quality teams and development.
Through my career, I’ve seen both sides of equation. As a consultant through ThoughtWorks, and as a Full Time Employee at several companies. One question always comes up and it’s not the easiest question to answer:
How much work do you need to show for the company to trust that you are doing the best work possible?
Perception is always an issue, and even more so when you are a consultant or you are working on a project that has been outsourced to your team.
Whatever cadence you’ve set for communication, meetings, delivery, reports, and the actual work, it’s important that you keep those timelines as much as possible as a consultant or outsource team. Maintaining a schedule, even when things slip due to blockers or unexpected issues, creates necessary transparency around the team’s work.
To address Federico’s question in this context, creating live dashboards on development progress and testing as quickly as possible will also aid in creating transparency. This is where the ROI is worth the effort, especially for a consulting/outsourcing company.
When budgets are tight, and you want to maintain relationships with your partner companies, showing your work, and backing it up with visible metrics is absolutely key.
Create Dashboards for the following:
Testing Progress Dashboard- have a tool or plug into one that shows how testing is running. Report on unit, integrated, and UI tests as much as possible. If your dev team isn’t using unit tests to show how much their code is testable - try to change that attitude as quickly as possible. Consulting/Outsourcing companies should be writing unit tests - this is what gave ThoughtWorks developers a real edge. Unit tests accompanied any code and could be run locally before the PR was pushed. TW could absolutely say with 99.9 percent accuracy that their code was stable, testable, and would cause as few bugs as possible.
Change Management Reports - Report on PRs and the week over week addition and subtraction of code. Keep this at the team or the org level. Don’t narrow it to a person by person report. Showing this metric with the tests shows how fast teams can move when the codebase is stable. This further helps perception that your team is making steady progress on business requirements.
Sprint Report - With the #of PRs, and the delta on code updates, report when requirement changes happened during the development process. Even if the change won’t impact the overall timeline, making sure your estimates are account for the changes will be crucial. (This is often where external teams don’t push back when they should. Though I know this can be difficult when contracts are on the line.)
Combining the Sprint & the Change Management report along with overall testing metrics can tell a really good story about progress being made by the team. It creates transparency, and lets team managers point at these artifacts with confidence.
Jira can make this fairly easy as they have a lot of built in reporting. Plus, plug-ins to tie your git repos/PRs and test management software into sprints/kanban boards.
If a company you are working with doesn’t have these reporting structures already, create them for your team. If you’re working as a lone consultant (like a quality coach or a developer lead), creating something like this as quickly as you can will give you room to breathe while you work on the underlying problems (which will likely be communication - so the reports will start to repair some of that immediately). In this instance, the reports and dashboards are definitely worth the ROI to create visibility, and gain a positive perception around the quality of your work.
When I was at ThoughtWorks, I wondered why we spent time reporting on our metics and delivery, when overall we knew we were doing good work. Truth is, not everyone knows a team is doing good work. Sometimes you have to show your work to gain trust and a positive perception, especially when things are going well. Because when they don’t, you’ll have built up the credit to be trusted to fix things when they deviate from what was planned. And in this economy, that might be the difference between keeping your current contract work vs looking for new clients.