Whenever you write some code you better make sure you have it covered by some tests. There are different possibilities on how to achieve this (and you might want to use all of them).
Unit Tests
Unit tests are a classic. You usually write them while you code. Write tests, run failing test, write code and run passing test. Repeat. Keep this small and simple. Test the smallest unit which makes sense. You might end up with hundreds if not thousands of them. Make sure you have no external dependencies in them, like databases or external webservices. Mock them away. They are usually written in TestNG or JUnit.
These tests can run at every check in in the VCS.
Integration Tests
Integrations Test are one step higher. You want to make sure your applications runs with all or some dependencies and things plays well together. These usually have a much higher run time since they might involve some external services. Usually you would use a framework like TestNG, nUnit for them.
These tests are run not so often since they can be very expensive.
UI Tests
Many applications have some sort of graphical user interface. To make sure everything works alright there are several tools like Selenium or HP Quality Center to simulate a user going through the GUI. These tests are written more towards the end of the projects since in the beginning the interface might change fast and often and the overhead to change them might be significant. You usually can not run through all paths of your applications. Choose the ones which are the most critical.
They can be run a couple of times a day depending on the size of the application and the tool (e.g. Quality Center tends to be sort of slow) you use.
Reference System Tests
If you have to implement some business rules or calculations and your client can specify these in Excel you might want to use a framework like Fit (or Fitnesse). You run your system against the values in the sheets and verify that it meets the expectation.
There are many more test possibilities and techniques to make sure the system meets the demands of the customer. These are just the ones I tend to use in my projects and I found them very useful.
Tests (and specifications) with tools like Concordion or the use of a Behavior Driven Design frameworks like EasyB are offering nice
ways to make sure the customers gets what he pays for (and he understands it). I still need to play with them.
For the last couple of month our scrum master always drew our daily burn down chart. Nice and fine and it always happened automagically. It came to the point that we (the developers) only occasionally paid attention to it (a little less then we should). One day our scrum master stopped doing it and forced us to do by ourselves. While it seemed a bit strange at first it turns out it was a brilliant idea.
We are now reminded every day how much hours we burned (in contrast to we just complete cards but nobody calculates the sum and tells that everybody). If the result is far below the theoretical number of developers x 8 hours a day we quickly analyze the problem and try to solve it. We are more aware that we might be in trouble. This was not so much the case in the last sprints.
Self made burn down chart
It could be that it just works because it is new but I think it is worth a short. I certainly like how everybody stands around the burn down chart and tries to do mental arithmetic.
