3

We are a very small team (1 front-end developer, 1 back-end developer/solution architect, 1 PM/UX) working in Scrum with 2 weeks Sprints.

Up until now, we were mostly working on prototype projects not requiring any testing but one of our MVPs is gaining traction and we've started implementing unit testing as part of our Definition of Done for our user stories.

However, we're now having an issue where testing is taking as much time, if not more, than the development/coding time for two main reasons:

  1. My devs are not used to the unit testing framework and are still learning.
  2. There are only two of them, each with their own specialty (front-end and back-end) so they have to do both the coding and the unit testing for their side of the stories.

This has led us to fail sprints because unit testing ends up taking so long that the stories don't get finished before the end of the Sprint. This becomes problematic for medium-sized stories that can't be split into smaller stories because when we add unit-testing estimation, it ends up making these stories so large that a single story ends up taking up almost half of the Sprint capacity.

Would you have any tips on how to improve this process so that testing is more streamlined/faster? Our front-end is using React and currently using JEST for unit testing, and our back-end is built with .NET on AWS but hasn't started implementing unit testing just yet.

2
  • 2
    It is important to identify the level of quality that is appropriate for your product. If you have a high level of quality necessary for your product, then maybe spending half of the sprint on quality, including unit tests, is the right amount of time to spend.
    – Daniel
    May 27 at 14:13
  • TANSTAAFL. If your team or your organization feels that testing is a net benefit—which it almost always is—then it should also be willing to treat the testing effort as work that the project is willing to pay for. I give a longer answer below, but feel like the X/Y problem here is likely a "free lunch" mentality within your organization. It's at least something you and your team should strongly consider when deciding if this is really a process problem or a cultural one.
    – Todd A. Jacobs
    May 27 at 23:43
11

My devs are not used to unit testing framework and are still learning

This will improve over time as they gain more experience.

There are only 2 of them and each with their specialty (Front-end and back-end) so they have to do both the coding and the unit testing for their side of the stories.

That is absolutely normal. Who else would write tests? Even if you had someone else to write tests, you would need to hire and pay them probably at the same rate as the developers. Tests do not magically appear.

This has led us to fail sprints because unit testing ends up taking so long that the stories don't get finished before the end of the sprint.

Yes. Your estimations are completely off, because up to now you have not delivered working , production ready software, you have delivered half-tested prototypes. And that's fine for prototypes, that's what they are: not production ready. That's the whole point of a prototype, get something going, don't get bogged down in details, show that a concept can be done. But now you need to deliver production quality software. And that takes longer than prototypes. There is little you can do. Improve your estimations to take that into account so you don't fail sprints.

But if your team is not producing enough at the quality you need, there is no silver bullet. You need more people. Hire another Frontend developer and backend developer. Producing production ready software instead of prototypes is easily double the work.


Even though you did not ask: hiring more people gives you a chance to improve your processes. If you have one frontend developer and one backend developer each having knowledge of their domain, there is about zero option for teamwork. I mean sure, the backend and frontend have to talk to each other, but that's not the teamwork I'm talking about. There is no one to help with the backend if they get stuck. There is no one to ask if the frontend gets stuck on a problem. Right now you don't have a team, you have an assembly line. You need more people with the same specialty so they can help each other, and work as a team. You need to be able to compensate if one of them has a week of for vacation or has to call in sick. You need to get your team to production size. As a first step to a minimal, barebones team you could hire a full stack developer that can help on either part or the project. Better would be one more of each role. Scrum does not work very well with a two people team.

1
  • Hey, I completely agree with everything you said and have been pushing for at least a full stack dev to join but budget doesn't allow it at the moment unfortunately. Thanks for the insights!
    – Paz
    May 28 at 2:27
3

TL;DR

The real problem here is that your organization is framing the cost of testing as unwanted overhead, rather than as an expected and necessary cost of doing business for product development, maintenance, and support. Focus on fixing that.

Analysis and Recommendations for Reframing

Would you have any tips on how to improve this process so that testing is more streamlined/faster?

TDD and BDD are not "go faster" buttons. While teams often do get a little more efficient with testing over time, the goals of testing are more closely aligned to:

  1. Reducing technical debt.
  2. Eliminating certain classes of common or predictable bugs.
  3. Creating executable documentation.
  4. Making code more flexible through emergent design and comprehensive regression tests.
  5. Making testing, support, and maintenance easier by designing the code for testing and debugging right up front.

While these things often make adding new features or finding/fixing bugs easier in the future, they don't usually make current development faster. In fact, refactoring (or worse, redesigning) code for testability inevitably adds short-term drag and long-term overhead. Furthermore, getting everyone up to speed on new tooling and techniques takes time and effort, and by definition will consume team capacity.

There are several things to keep in mind here:

  • You will pay the costs of testing either way, either as overhead during development or as maintenance problems down the road. You might as well pay them up front since these costs are almost inevitable.
  • Regardless of whether you pay the costs in TDD/BDD or leave them to become drag from technical debt, all costs (including the cost of testing) should be visibly charged against the project. In Scrum, you do this by adding TDD/BDD to the Definition of Done and bake it into your Product Backlog estimates.

Note that in many agile frameworks, it's also perfectly acceptable to add architectural runway items directly to the Product Backlog. Since you're in the process of adopting a new testing approach, the work related related to tooling, training, and other overhead that can't otherwise be attributed to a typical feature can and should be prioritized by the Product Owner on the Product Backlog. This ensures that this necessary work is treated as planned work rather than as unexpected or undesirable overhead. When using this approach, architectural runway and testing activities are properly treated as a cost of doing business.

3
  • Thanks Todd! I agree with what you say and am considering TDD. You mention something very interesting about architecture runway and earlier, about refactoring. Things that can't be attributed to a typical feature/user story. Given that we've "jumped the gun" from prototype to product, there is a LOT of rebuild that should happen to get it more stable/future-proofed/scalable. Do you think it would be worthwhile to simply "pause" the current project to rebuild it as a production-quality, TDD driven, project? Maybe this should be a whole new question :D
    – Paz
    May 28 at 2:34
  • 1
    No, you don't pause the project. That's still an anti-pattern because you'd be treating process and architectural runway as somehow separate from the rest of the development effort. Since comments are not for extended discussion, if you still have questions about this please open a new question that references the relevant questions, answers, or comments that raise further questions for you.
    – Todd A. Jacobs
    May 28 at 12:06
  • Ok Thanks Todd!
    – Paz
    May 29 at 2:53
1

To echo what the others have hinted at:

Testing is not a necessary evil.

Testing is a crucial component of delivering quality (or at least working) software.

Keep in mind that you only get one chance to make a first impression and delivering buggy software destroys your reputation.

So, to answer your question: You need to budget in more time for testing - and even more time for fixing bugs that are discovered once testing begins.

To "to improve this process so that testing is more streamlined/faster", make testing the focus, not a punishment added on post-scheduling.

So, how do you go about that?

You mention that your stories are large and cannot be shrunk. Possibly you need the help of an experienced Technical Project Manager, to help explain to your team how to shrink the stories.

Large stories = large chunks of code = more chance of bugs = harder to fix.

An experienced (ex-)programmer/PjM will show your team how to shrink your stories into manageable bites (or bytes).

E.g. Techniques such as stubbing would be used; as you progress, you turn each stub into real code. But meanwhile you have lots of small stories - one per function - that can be coded and unit-tested, and even peer-reviewed, since they are of a manageable size with a single function.

And it won't take longer - it will probably shrink the timeline as more time is put into planning the code before it's written.

2
  • Thanks, Danny! Not sure I understand how you can have "one story per function" while keeping the stories user-centric and not developer-centric? I'd like to avoid falling back into "as a developer I need..." kind of stories that lead to working on features developers want rather than what users want. Would you be able to provide examples?
    – Paz
    Jun 1 at 0:50
  • @Paz, not easy supplying examples without knowing what you're developing, but for your registration story you could break it down to "login" w/o verifying user exists (the stub returns needed ghost "user"), then "create new user", then "user already exists", then "send verification email", then "lost password", then "change password", then "wrong user/password" - that's 7 stories instead of a big "registration" story. Jun 1 at 14:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.