Erbil Yilmaz, COMPANY
As part of story-driven development, in each sprint feature crews (teams) take a few stories and implement them. The goal, at the end of each sprint, is to demonstrate and complete the customer experience along the stories’ design. This is a great software development methodology proving the software being built can deliver the customer experience.
However, story-driven development brings unique challenges for software testing. As stories are implemented, relying on each other, a complex software system emerges capable of doing more than just what the stories told. With the addition of each story, testing surface and capabilities (and defects) of the software grow exponentially.
Usually, different sub-teams develop different parts of the software, making it very difficult to manage and understand the complete set of capabilities of the software. As a result, at the end of each sprint the software product consists of: (1) features told with developed stories and (2) features/defects emerging from untold stories, coming from interactions of the implemented stories. Sometimes these features are as designed, but often hiding significant integration bugs.
This paper describes various techniques developed and used by the Visual Studio Architecture Tools team over a few releases, through experiments in testing within agile development. It also presents some case studies to illustrate and emphasize key points, ranging from using architecture diagrams as part of test planning to particular test coverage along with test spectrum range. The guidance presented focuses on a set of best practices that teams can adopt to accomplish optimal test coverage over the test spectrum.