Grass Roots Agile

RTF Strategy

Choosing the correct tools has a tremendous impact on a teams ability to remain agile. Agile tools are testable, non-invasive, easy to use, flexible, and lightweight. As RTF requires continuous measurement of automated acceptance tests, measuring RTF requires a tool. A few such tools exist in the open source space.

FitNesse is a testing tool, wiki, and web server all rolled up into one. FitNesse allows project team members to
collaboratively define acceptance tests by creating tables on web pages using wiki markup. FitNesse wiki pages integrate with test fixtures that invoke application code, making FitNesse a testing tool that doesn’t rely on web based testing, but does require test fixtures that have the ability to directly invoke application code.

Selenium simulates the user by executing its tests directly in a browser. SeleniumIDE is a plug-in for FireFox that allows you to record test scripts. Scripts can be included on an HTML suite page using Selenium Core, or converted to Java, C#, Perl, Python, or Ruby for inclusion in an xUnit style test case using Selenium Remote Control.

Both FitNesse and Selenium are relatively agile tools. FitNesse does require running the FitNesse server, as well as test fixtures that can interact directly with the code being tested, so the test code must be deployed with the application under test. Selenium Core comes with the same restrictions, but Selenium Remote Control does not. Instead, Selenium Remote Control provides a Selenium Server that is run and communicates with the browser via AJAX, allowing you to test a web application in a very non-invasive style.

In 1994, Standish Group published the original CHAOS report. The top three impediments to project success were lack of user input, incomplete requirements and specifications, and changing requirements and specifications. Recent feedback indicates similar problems exist today, proving that attempts to stabilize requirements early in the lifecycle cannot and will not work.

Software requirements will always change, and it is our job to deal with it. Eventually, all change leads back to the source code. We must nurture and grow a resilient codebase. We must adopt practices that promote early and frequent discovery. We must adjust our attitude to embrace change. It is our professional responsibility to lead the effort toward a better, more satisfying way of creating software. The only guarantee in life is change. If we do not assume this professional responsibility, someone else will.

From http://techdistrict.kirkk.com/