Integrated Testing.
Would like to talk about this topic using the Analogy of building an Aeroplane. Assuming that the final product is an Aeroplane. Assume that it takes a few Sprints to deliver each of the parts, each part is tested as it is built.
Now the entire aeroplane is ready. So this is a logical point to perform an integrated testing to check that the Aeroplane can fly.
Would having an integrated testing cycle done once the entire product is ready contradict the Scrum principles ?
instead of the metaphor of the aeroplane, I suggest the one of a vehicule, like a car.
See http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
First increment = skate-board. It need to be tested and to be useable before release.
Second increment = scooter. Again, tested and useable before release.
...
Surely the entire Aeroplane, or the car, or the scooter can be delivered in 1 Sprint. Hence the example that I took.
Sorry I meant that the entire Aeroplane or the car etc cannot be delivered in 1 Sprint, but would take multiple Sprints to deliver as a whole.
yes, the car can't be delivered in one single sprint, but how can you split the work in order to have "something" usefull to get feed-back from your customers ?
in the context of the aeroplane, what about a glider or a flight-ticket at first ?
Olivier, even glider won't be delivered in 1 Sprint.
But we are deviating from my query, that in the scenario of producing a product like plane, the logical testing point comes when the plane is ready. Often in software also we come across such cases. So is it wrong or un-Agile to do an integrated testing towards the end.
Sprint iteration may include integration testing of developed components, you may think having a separate sprints just for integration if you wish before release happen. Having a potential shippable product at end of each sprint is way to add incremental value, but components usually don't move to production in each sprint, unless integration testing are completed before release. Usually, production release cycle follow in every quarter and complete integration testing apart for components level testing does happen before every release including regression testing, load & performance testing if required.
Maybe you can find some ideas into this recent topic about the DOD ? https://www.scrum.org/Forums/aft/2490
And from the wikispeed team : http://wikispeed.org/team-2/the-wikispeed-process/
OK, it's not an airplane ;-)
> So is it wrong or un-Agile to do an integrated testing towards the end.
There's nothing wrong in assuring integration at any point in development. What would be unagile would be deferring the release of an integrated product until the end of the initiative, because that would represent a large and unvalidated leap-of-faith.
Integrated and releasable increments may include the engines, which could be used on existing airframes, or the airframes for already existing engines. New seating arrangements could be validated using existing aircraft. A scale model might be built to validate fuel efficiencies. All might be useful MVP's a PO might reasonably care about. As Olivier mentioned, even a flight ticket could be a useful increment if it allows a pricing point or other market assumption to be validated before building anything.
Agree with Ian here. You should not wait for the integration tests till the entire project is complete. As soon as two inter-operable components are built, the integration tests also should be done along with it. By delaying the integration tests till the last moment, you are risking the entire project.
According to me, integration tests should be a part of the definition of done and automated as part of the build. However, it is the team's decision.
So I agree to the point that as parts keep getting built, they also have to be assembled and tested at the same time. So as the wings get ready, they can be integrated with the plane body and tested.
But is it also wrong to say that when the entire plane is ready as a whole, it should not be tested for its flight ?
In your case, extra tests towards the end sound necessary.
However one word about Agile testing: when you have a separate verification and validation phase, you are NOT agile.
An agile tester works hand in hand with the coder and the PO to make his voice heard.
Concretely speaking, you could consider the two following points regarding your test strategy
- Involve a tester in backlog grooming sessions so that he can ask "test-oriented" questions. This would improve the refinement of acceptance criteria.
Everybody would understand clearly how/to what extent a given item needs to be tested in order to be DONE.
- The tester and the developer should discuss more often and since the beginning of the sprint about the tests that will be needed. This way the developer knows what is coming. It influences the way code is written.
Irrespective of the strategy you adopt, keep in mind that the aim of testing in agile is to provide FAST feedback.
Do whatever is necessary to have that.