I’m not sure development teams do the testing they are suppose to do, or follow the advice of what proponents of testing say you should do. As a matter of fact I know that most teams do not practice any form of formal testing, or rather make testing a key component of their development. Test Driven Development in an Agile scenario prescribes that you write code, write test code, test it and iterate if necessary. Essentially TDD forces you into a discipline of making sure your code works, which incidentally is one of the key objectives of an agile development methodology – you must always have a working portion of your code. In other words if you have to release code immediately then there should be code of sufficient working quality available to make everything work. That is my understanding anyway.
The reason I am looking at using agile as a development methodology is because I want to develop a commercial product using ASP.NET MVC and as Phil Haack says in this article:
Notice that at this point, we’re focusing on the behavior of our app first rather than focusing on the UI first. This is a stylistic difference between ASP.NET MVC and ASP.NET WebForms. Neither one is necessarily better than the other. Just a difference in approach and style.
And from that I gather that ASP.NET MVC was designed to work well as a unit testing platform as well. I started about 3 weeks ago to formalise my development process and I started out by defining agile to have the following steps:
- Start off by Planning a work item
- Do a requirements analysis of the work item and identify what you will need to do to get it working correctly
- Design the code/program
- An iteration then begins:
- Write the code
- Write a unit test
- Do an acceptance test
I am having to change my development process though, because I intend to use Team Foundation Server (TFS) as my source control system, and I was thinking that maybe I need to consider using MSF (Microsoft Solution Framework) to drive my development process. MSF is integrated into TFS, and it essentially means that you can build applications and do source control within a development methodology. I started off looking for stuff on MSDN and searched for this and came across this presentation. From this presentation I understood that the agile process is structured a little differently to what I did in my initial process definition. Each iteration in a MSF consists of:
- Envision
- Plan
- Build
- Stabilize
- Deploy
- Continuous
Iterations occur at various steps and its up to the project manager to determine how many iterations occur. MSF also promotes a daily work cycle, which essentially makes sure that your code is of an acceptable standard. Essentially you check-in each day, make a build, make sure its an acceptable build and then you continue the develpment process within an iteration. This process repeats daily. Within the iteration cycle there are several other iterations which aim to achieve a pre-determined level of quality, based on planning of feature sets. The iterations also act as a mechanism to correct a project plan if there are deviations. The iteration is broken up into iteration cycles, with iteration 0 consisting of a project setup plan followed by a first iteration that involves planning, developing, testing and getting feedback followed by an nth number of iterations that involve planning, developing, testing and feedback. The last iteration is a set of nth iterations that involve developing, testing and releasing the product. You have to view these iterations as a set of ‘refinement’ iterations, each iteration is intended to refine the solution. You also have to view these iterations in relation to the iteration steps mentioned above. In the powerpoint presentation they present a very cool view of the iterations as they happen.
Iteration 0
At the top they start off with the envision stage that includes the writing of a vision statement and the identification of personas within your system. Once that is defined you have to determine an iteration length. At the planning stage of the iteration you have to access/assess project progress, which is a continual thing I assume. Within the build stage you must start off by creating a scenario through brainstorming. You must also create a Quality of Service scenario through which you create a QoS. At this stage you must also refine the personas. The scenario that you created previously requires that you prioritise the scenario list, each with a scenario description. You need to prioritise QoS as well and write a QoS requirement. From the scenarios that have been written you need to create a solution architecture that partitions the system. You also need to storyboard the scenario, and develop a performance model. You also have to identify the security objectives, and then you need to test the scenario by defining a test approach.
On the next level you have to determine the interface. Does this mean the actual UI? You also need to plan an iteration at this stage by estimating a scenario or QoS. Then you need to develop a threat model. On the next level you need to plan an iteration around scheduling a scenario. From this you can develop an architectural prototype. You also need to plan an iteration around QoS and then create a infrastructure architecture. At the next level/step you plan an iteration around dividing the scenario into tasks, that make up a dev task which is then costed, and the same strategy is applied to QoS.
From the diagram in the powerpoint I assume that you can repeat as many iterations as you want.
Iteration 1
Iteration 1 includes writing a QoS test and writing a validation test for testing your scenario. It also includes doing a code check-in to your source control. It contains stages/levels that require you to write code for a development task, as well as creating an update of a unit test. It also covers fixing bugs:
- Reproducing the bug
- Locating the bug cause
- Deciding on a bug fix strategy
- Reassign the bug
- Create of Update unit test
- Code the fix
- Perform unit test
Implementing a development task covers the following:
- Create of Update Unit Test
- Write code for dev task
- Perform Unit Test
- Perform Code Analysis
- Refactor code
- Integrate Code Change
After this stage there has to be a build and an accepted build. In the build there will be:
- Start a build
- Verify a Build
- Fix a build
- Accept Build
An accepted build will revolve around testing scenarios and in particular:
- Conducting an exploratory test
- Select and run a test case
- Open a bug