Tracer bullets and SIT.

Agile teams deliver smaller slices of deliverable to avert the big bang releases and failure. Also, by delivering iterative, we are getting frequent feedback. Here are the important questions related to this.

• ·        How to perform system integration testing? Whether we need to keep the integration testing as a part of scrum team or as a separate team?
• ·         As we plan to deliver frequently, are we going to perform SIT for each small slice of functionality?

Since the agile teams deliver only a slice of the feature, sometime the suitability of this code in the overall architecture is not validated; until a complete regression on system integration is done and certified.

To avoid such delay, we shall implement tracer bullets. Here is my blog talking about the difference between tracer bullet, POC and prototypes.

http://myagiledays.blogspot.com/2014/12/tracer-bullet-and-more.html

Tracer bullet is a skeleton implementation of a feature which spans across the architecture. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and rest of the iterations can build on this code.

Tracer bullet ideally should cover all the major data flow paths in the technical architecture to perform the basic ask in the user story. The design thinking should ensure (Ideally) that SIT should done once for tracer bullet and once again after implementing other functional asks.

This way, we would be performing system integration when we test tracer bullet and we will validate functional integration when we perform remaining sprints deliveries.