cost through discovering the root cause of the build error ,as shown in figure 1.
Unit T esting
Unit testing has fast become one of the most popular ways to automate testing. Many people merge the unit test suite with the continuous integration build so that all the unit tests must pass before each build even starts. Since unit tests are working at the code level, it can be very fast, as opposed to manual or even automated functional testing. And, a large number of tests can be run in a short period of time. This is an ideal way to shorten the length of time it would take to run a suite of regression tests, however it only tests the individual “units” of an application and not necessarily the end-user experience. So, for example, your finance application might pass a unit test where the labels for last name and first name are accidentally swapped. Although you cannot survive on unit tests alone (if you have a GUI, that is), they are still very useful.
You can create unit tests as a form of documentation. A developer can look at the test when he looks at code and wants to know how it is supposed to behave This can be more useful than maintaining detailed documentation, which can be time consuming to create and can quickly become obsolete if not continuously updated.
Functional and S moke T esting
The five-day regression tests scenario I mentioned earlier came from a company I once consulted for. The test suite was a combination of automated and manual tests. Testing a GUI application—even with automated tools—e takes longer than a unit test, since the GUI or web page has to load or render before the test can begin. And, if the playback of the test goes too fast, it might skip over some part before it has chance to load and fail.
But, automated tests are good, and we don’t have time for manual testing, right? So, what’s the solution?
For automated regression tests, you can limit your focus to the most important features of the application, and run a much-reduced suite that ensures the most important functionality always works. Developers can also smoke test new changes that effect the GUI as they are completed—meaning that if you add a new button to your application, you fire it up, click on the button to make sure it works, and, if it does, commit your code.
Unit tests and continuous builds will look for any error introduced after each change is made. Smoke testing by developers will prevent obvious flaws. An automated functional regression suite is the last line of defense to ensure the most important features always work before the product ships out the door.
Often, agile teams don’t have a dedicted tester as defined in Scrum And XP From the Trenches : “What I mean by ‘tester’in this case is ‘a guy whose primary skill is testing,’ rather than ‘a guy whose role is to do only testing.’” Building and maintaining an automated test suite is time consuming but worth the cost. It is something that every member on the team participates in (and, in some cases like TDD, it is inherent to the process), and team compositon can be adjusted to include members with testing skills.
There are formidable challenges with instituting automated testing. It is a time consuming and a continuous process, as new tests must be created all the time to cover new changes, and new changes may cause old tests to fail while maintenance must be performed to update