In agile software development, and more specifically in our agile methodology Smart, testing plays a crucial role. We deliver working software in short iterations, where each iteration is used to deliver a number of discrete features. In order to avoid bugs before we even create them, we test as early as possible. That is, we test our individual features during our iteration.
Testing is more than unit testing
Although the importance of testing is stretched in any of the well-known agile methodologies or processes, such as Scrum, XP, DSDM, or Lean, strategies around testing remain quite vague, like just stating that testing is important and should be done as soon as possible. When it comes to defining
what to do exactly, you're on your own. And even though unit testing is a great technique for managing maintainability and extensibility of your code, there is actually much more to testing than just writing and running unit tests. Unit testing is a developer activity, whereas
functional testing remains the domain of testers. Checking whether the code to deliver or being delivered actually meets user acceptance, or that navigation through your web site is implemented as desired, is a totally different ball game.
Smart testing
In projects that are executed using the agile methodology Smart, the highly structured (and small) smart use cases are the main unit of work. They are not only used to express requirements, but also help to estimate the complexity of a project, and set the outline for coding (and code generation) and testing as well.
Because smart use cases are realized throughout the project during iterations, in Smart testers are therefore present from the start of the project, and in any case from the start of the first
Realize iteration. But as much of the work around smart use cases is standardized and automated, so is the testers work, as you can see in the smart use case life cycle below.
 Smart use case life cycle |
In basic steps, testing smart use cases is executed as follows.
Step 0. Identify smart use cases to test
At the start of each of the iteration in a Smart project, the smart use cases are selected that will be implemented during that iteration. Priorities are set by the customer and possibly the users. The number of smart use cases that is picked depend on their complexity (defined by
smart estimation) and the iteration velocity.
As our smart use cases are very much standardized, for most smart use cases testing becomes standardized as well. So here's an opportunity to save some of the sparse testers time, and define in which of the selected smart use cases to put the effort. Not all smart use cases need to be put to the test at the same level of rigor.
Note that this step is normally executed at iteration kick off.
Step 1. Model smart use case scenario's
In most projects we model an activity diagram for each of the smart use cases that will be tested. This activity diagram (but any other process flow type diagram will do as well) is used to identify the different scenario's by which the use case can be walked through. And there's different scenario in almost any smart use case.
Types of smart use case scenario's
There are three different types of smart use case scenario's. These include the happy day scenario (the success scenario), failure (with an undesired outcome and recovery scenario's (which go wrong in the first case, but can be mended along the execution).
Sander Hoogendoorn
Chief Architect ADP
This work is done
before the smart use case will be implemented. It is actually an important part of the smart use case (test) design. Quite normally, the tester together with the developer (!) do the work. This allows for knowledge sharing and in our experience avoids the creation a lot of unnecessary bugs later on when the use case is being built.
From here: work in progress
SH.
Step 2. Identify test scenarios
Using a simple graph theory exercise, it is possible to write out all the scenario's in text format, taken from the activity diagram.
Identify decision nodes
Identify partial paths
Create full paths from partial paths
Every path defines a test scenario
Describe test scenarios
Name partial paths
Define test scenarios
Write test cases with test scenarios
Test happy day scenarios
Test alternative flows