2

I am a software engineer trying my best to scope out some work in ticket form. My question is: what is the best way to write stories to include integration tests between two components which don't yet exist?

My thought was to scope component "A" in one story and component "B" in another story (the development work is sizable for A and B separately). Would it be appropriate to have a separate ticket to write integration tests between A and B? Or would it be better to include integration testing as part of the B ticket scope (assuming work on A is complete)?

5 Answers 5

1

You might be overthinking this.

Unit testing should go together with each component you develop. "Has unit tests" is most likely also part of your definition of done. But integration tests are a separate thing, where you test how things work together. In this case how component A works with component B. So you cannot run the integration test if any of the components are missing anyways. So there is no need to tie them to either component A or B.

Record the integration tests as their own tickets.

That's my 2 cents :)

1

You need to better define what your unit of work - your "ticket" or "story" - is.

I am a proponent of units of work that represent demonstrable value to a stakeholder. Often, the stakeholder is someone outside the development team, like a user or a customer. However, it could also be another development team or even the development team doing the work. Regardless of who the stakeholder is, the point is that when the team says that the unit of work is done, they can go to the stakeholder(s) and objectively demonstrate the value of the effort to do the work.

Because of this definition, I would never have units of work that represent things like "build component A" or "build component B". The decision to build a new component or extend an existing component is a design decision made to help realize value. Building a component, by itself, isn't valuable. The value is only realized when the system is changed in some way.

I would include the creation or maintenance of integration tests whenever there was a unit of work that affected the interactions between two components. You would make this decision as early as your refinement activities and as late as doing the work. The amount of up-front design and decisions around building (or buying) new components or extending existing components depends on the risk. Units of work - stories, tickets, or whatever you want to call them - inherently include an evaluation of and updates to integration tests whenever the delivery of value includes the creation or modification of two or more components.

1

Until the integration testing is completed successfully neither Component A nor Component B are done.

Imagine a scenario where you report to your stakeholders that Component A and Component B are finished, but then start on integration testing. The testing reveals some problems that require rework of Component A and Component B. You then have to explain to your stakeholders that the components you said were finished now have work still to be done.

It is this kind of reporting of progress we are trying to avoid when following an agile approach.

My recommendation would be to assume that integration testing is a part of the Component A and Component B stories. For estimating, I would tend to include the integration testing estimate in one or the other of the stories (the one the team is most likely to do last).

1

TL;DR

The question is largely about how to represent work in Jira, but the practical solution is to reframe the issue as one of testing coupled units of work. After reframing, address it through effective communication about how testing related work elements impacts the critical path to "done." That communication can take the form of various decomposition and linking techniques in Jira, or (better yet) ensuring people talk to one another about the coupling. There are lots of ways to represent dependencies in Jira, but only a few ways to pragmatically address interdependencies between a set of components within a product.

Redefining the Question

The underlying problem is that you consider this a stylistic issue (the question was previously tagged , but it is not a question of style but of tools and frameworks. In this case, you're allowing your tool (specifically ) to drive your approach to defining "done."

Jira is simply a ticketing system. It has no built-in Definition of Done for a unit of work; that's really up to the working agreements and "rules of engagement" that govern your process. In other words, it's a question about expectations rather than a built-in formalism. Jira can't and won't solve this problem for you. You have to define what "done" means for your ticket, your project, and your team in order to decide how to address this properly.

In short, what you really need to know is:

  1. When is Componant A "done?"
  2. When is Component B "done?"
  3. When is the integration of Components A and B "done?"

They are three separate but tightly-coupled questions.

Define Working Agreements for "Done"

You can call each component "done" when it meets whatever specifications or unit tests you define for it, but pragmatically neither will really be done until you can ensure that they work together because they are coupled. In an iterative development framework this might matter less since ongoing changes to coupled components is an expected part of emergent design. However, in more traditional frameworks or workflows, you can't really call either A or B complete until you've ensure that they are both individually complete and are collectively integrated.

Depending on your framework, you have a couple of basic choices here. They include:

  1. Adding "integration testing" as a task or dependency on both components A and B.

    NB: This essentially means neither A nor B can be completed independently of the other.

  2. Placing each related ticket inside an epic, which is only done when:

    1. Both components are completed.
    2. Both components have been unit-tested.
    3. Both (or possibly all) components have been integration-tested.
    4. Add additional tickets to the epic as needed to track any additional work on the components needed for integration.
  3. Treating "integration" as a separate ticket.

    • Tickets for A and B can depend on the integration ticket, even though Jira usually treats dependencies as prerequisites rather than follow-on activities.
    • The integration ticket can depend on the ticket for components A and B, which is a more Jira-centric way of looking at it.
    • "Integration" with the other components can be a task within the tickets for A and B, but then you still can't close the other tickets before you perform integration.
  4. Integration testing will be performed after marking components A and B as "done."

    1. If new work or rework is required to properly integrate the components because they don't actually integrate, then new tickets or dependent tasks need to be created/linked to the "integration" work.
    2. The work needed to modify and unit test the components should be treated as new work, and must meet your new Definition of Done.
    3. Once those tickets are done, you have to essentially rerun the tests and other activities in your "integration" ticket to reach its Definition of Done.
    4. Mark the integration ticket as done if successful; otherwise, return to step 2.

The first option is more agile, as it acknowledges the coupling of the components are treats them as a single deliverable increment. The second and third options are both very Jira-centric, but offer different ways to look at what is essentially a set of circular dependencies.

The fourth "option" is a little different. It's fairly ticketing-system agnostic; it simply represents the process cycle required for any approach (including within Jira) that is required if you treat the coupled components as separate work items.

A Simpler Alternative

Rather than trying to decouple the two components, which are clearly intertwined, you should probably treat them as a single work package or (to use agile parlance) a single Increment when both components work together. From a Jira perspective, you could do this by treating the deliverable Increment as a single ticket with the tasks for each component—including unit testing and integration testing—as defined task items within the ticket. That makes it clear that they need to be delivered together.

By taking this approach, you define what the components need to accomplish, but leave how they need to be built and tested so that they work together up to the people working the ticket and/or tasks. This fosters collaboration, and despite the fact that Jira can't assign tickets to more than one person at a time (unless you use mailing lists or similar to assign tickets to groups) you are still encouraging people to work together on the coupled components rather than working in parallel. The latter is a form of utilization fallacy because it assumes that parallel work is a more efficient use of people, when in fact swarming collectively over coupled components is usually demonstrably more efficient in practice.

Using Jira doesn't make a project agile, and often works against doing so. On the other hand, even if you aren't interested in agile frameworks, tightly-coupled work usually calls for tightly-coupled workflows and work packages. So, regardless of what your tracking tool is encouraging you to do, your best bet is really to treat this interdependent set of work units as a single work package. Then break the work down and link the pieces together in Jira in whatever way communicates the interdepedencies most effectively to both the team and its stakeholders.

You can sum up the whole thing in one sentence: You must ensure that everyone understands that the two components can't really be delivered separately without redefining "done" as "possibly done, unless something we didn't consider needs to be added or changed."

0

As far as I understand you have "Component A", "Component B", and "(host)Component C" that has "Component A" and "Component B" inside; they must be interacting in a page or a component, correct? So, the integration story can go somewhere under that "Component C".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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