12

Recently I started a new project at work (it was nice to shake off the cruft of an old project and pick up a new one) and my team and I are pushing harder for more professional development practices, which include writing Unit Tests. The Product Owner isn't so impressed since this translates into delayed feature delivery, in the PO's opinion.

The PO (who is also my boss's boss, which provides a bit of conflict of interest IMO) is very upset about an issue that slipped through to our release product. I'm making the point that a good Unit Test suite would have caught the issue (some additional refactoring needed to deal with some inexperienced coder's architecture blunders), and the PO wasted no time in suggesting that we "figure out how to spend some quality OT on setting up unit tests then." Our schedule is already packed with feature requests and minimal time for bug fixing and other maintenance tasks required.

I'm disinclined to offer overtime for something that I've come to learn is to be included as part of the standard development process in a team of professionals. How do I communicate that Unit Test writing is a necessary part of the day-to-day responsibility of the developer? How can I help guard my team from being demotivated by having overtime demanded of them?

PS, I don't know how to tag this, I'd appreciate any help with that, too.

Improve this question
10
  • 1
    I'm not familiar with the term "Product Owner". Is this your customer?
    – David K
    Jul 8, 2015 at 14:09
  • 1
    Possibly related as it addresses one aspect of the problem: workplace.stackexchange.com/questions/7095/…
    – 404usernotfound
    Jul 8, 2015 at 14:11
  • @DavidK Yes! Sorry for the ambiguity. This is to refer to the person who own the product my team is developing.
    – Hyperbole
    Jul 8, 2015 at 14:15
  • @404usernotfound I'm not a contractor, I'm not sure your link helps (though it's a good read, thanks).
    – Hyperbole
    Jul 8, 2015 at 14:16
  • @JoeStrazzere I'm a team lead, and I'm speaking for myself. I'd like to be able to prevent others from also having to put in overtime, too, since protecting my team is a part of my job (that I enjoy, even).
    – Hyperbole
    Jul 8, 2015 at 17:17

2 Answers 2

Reset to default
17

Since you are using the term Product Owner, I'm going to assume you're using Scrum (or a related method). If not, ignore this answer completely.

If you are using scrum, the PO doesn't determine how much the team can do in a sprint, the team does. If you need unit tests to help you meet the PO's definition of done, then include them in your point estimates. In scrum, your schedule shouldn't be "packed" -- you can only get so many points done each sprint, and that's your schedule.

The PO should be setting the priority based on business value gained. If bug fixes and technical debt aren't important to the PO, then they won't put them high on the priority list. But your team should not be held liable for them either. If the work met the PO's definition of done (and QA testing should be included in the definition of done), then you did what was required.

Your Scrum Master should be the one guarding the team from both interference by the PO and interference from higher ups, so get them involved.

Improve this answer
3
  • The PO's definition of Done has been negotiated to indicate "development completed but with QA," against my better judgement.
    – Hyperbole
    Jul 8, 2015 at 15:31
  • 12
    Then your Scrum Master needs to make sure it's the PO, not the team, who is held accountable for that decision.
    – Kathy
    Jul 8, 2015 at 15:53
  • @Kathy has the right idea. OP you have to educate your boss on why unit testing is important for him to agree. Right now he doesn't seem to understand the value of it, the best way to do that is to do his approach and when tech debt piles up mention to him that it is because you guys are not doing unit testing. He will then be more likely to listen.
    – bobo2000
    May 25, 2016 at 9:21
7

When you scope or size your features do you break down unit testing as part of that or is it a separate line item? I would suggest that you make unit testing part of your development process and then scope tasks accordingly, while not breaking them down into code this feature test this feature. Just assume that the effort to "code" a feature includes writing the test cases.

If asked why things are being scoped higher, just indicate the project is growing, the larger the project the more features cost to add. You could enlighten him on TDD (test driven development), but I don't think it will make much difference. On the other hand if TDD is part of your development process, then it's just all integrated and isn't really a separate thing, it is just how you get things done.

If you are doing agile/scrum then the PO shouldn't be dictating schedule anyway, he/she should just priority and defining features. It's your team's job to give him a timeline. If you have to go back and do some cleanup then there is some argument for own time, but you may want to negotiate a certain amount of "Engineering" time. Where I work now we have a negotiated that 15% of our time is dedicated to engineering efforts. These are things we have identified internally as needing fixed. It could be a performance thing that isn't too noticeable now, but will be soon, or it could be that module that was not done right the first time and needs some love.

Improve this answer
4
  • 1
    Making UT a line item in a task is a practical risk, the PO is highly resistant to anything that doesn't have an immediate, tangible business benefit. Even after this major defect in a published product, the benefits of UTs aren't something the PO is willing to hear.
    – Hyperbole
    Jul 8, 2015 at 15:28
  • 3
    You said 'development done' was part of your definition of done. UT is part of development, it is developer written test cases and should be part of your definition of development, assuming have a definition for that. You may need to push this if you want this incorporated, so it's not done or even ready for QA until all the unit tests pass. It's also code, your PO clearly doesn't understand software development, so good luck.
    – Bill Leeper
    Jul 8, 2015 at 21:05
  • 1
    @Hyperbole It's generally better not to mention unit testing at all but have a general rule in the team that all new or changed code must have sufficient unit tests for whatever level of confidence you need and then re-estimate everything based on that. Yes, some stories or tasks that look simple will suddenly get a lot more expensive if you're having to write the unit tests that should have been previously written (or even more expensive if you have to rewrite the code itself to be testable).
    – cjs
    Nov 2, 2022 at 3:39
  • 1
    But that addential expense now is the cost of getting out of this and paying back technical debt. If it's truly unpalatable, you might cheat things a bit by insufficiently testing the worst cases now, leaving adding better tests for later, but you need to keep moving forward on doing tests. ¶ The important thing is to avoid negotiations from non-technical people about how to write the code; the XP principle that only people writing code can make decisions about how to write code is expressly designed to address this problem. And that includes how much unit testing you do.
    – cjs
    Nov 2, 2022 at 3:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .