Working on agile teams is really about being flexible and every member of the team needs to be capable of doing most if not all jobs. As a tester, this means you need to share your expertise where it helps the team. The programmers, analysts, and product owner will be doing the same. While sharing your skills, you will also be picking up some test automation and programming skills. You will likeky have to show the programmers how to build test adapters for your fitnesse tables, but they will be more efficient at implementing these fixtures once you explain them to them. This will likely be a win-win situation where they help you get some automation in place and either you or the analyists (ideally both, working in pairs) flesh in some testcases. If you are willing to follow the approach I just outlined in this paragraph, you will find the resources listed below very helpful,
There are two books that I believe provide many insights on how testers can be most effective on agile teams:
Gojko's book is available now as in both paperback and PDF ebook. Note that Gojko's website shows the prices in Brittish pounds. The US dollar is stronger than the pound so your price is likely to be cheaper. If you are squeamish about conversions, you can buy from LuLu.com in your usual currency (currently $21.55 for the eBook and $38.97 for the paperback plus shipping). If you are not squeamish about currency conversions, the book should arrive faster when ordered from Gojko's website.
Janet and Lisa's book is available on safari.oreilly.com. If you are a safari subscriber, you can read the final version online or purchase a PDF eBook with 16 download tokens (when you login and click on the PDF icon in the upper-right). You can pre-order the paperback from InformIT for $32.49 or pre-order from Amazon.com for $42.70. (Both of these places are currently offering free shipping.)
The next area you will want to read about is Fitnesse (and FIT). First came FIT and Rick Mugridge and Ward Cunningham's book that explains the various test fixtures available in FIT and Fitnesse (fitlibrary):
FIT and Fitnesse were written in Java and originally Java was used as the language to write the test fixtures in. This was a barrier on some other platforms (such as Python and .NET) so people rewrote Fitnesse to work with these other languages. The problem was that the syntax and functionality of each of these ports differ just enough to confuse you if you work with more than one. Most of the Python people I know avoid Fitnesse in favor of more "Pythonic" test tools (such as nose and others). Mike Stockdale ported Fitnesse to the .NET platform. Gojko Adzic (creator of dbfit) wrote a book on using the .NET version of Fitnesse:
Finally, after 6 years in existence, Fitnesse is currently getting an "make-over" to deal with the problem of ports to each test language being different. Bob Martin (developer of Fitnesse) has recently created a new thin layer between Fitnesse and the System Under Test. The new interface is named "SLIM". Both SLIM and the old language-specific interfaces will be supported by next versions of Fitnesse. Many of the current authors of tools related Fitness will be porting their works to SLIM. I believe these changes will eventually result in Fitness being easier to learn and that your tests will be more portable across language platforms. Currently for us testers who are morphing into agile testers, it means one more set of things to learn!
Currently the best way to follow these developments is on the Fitnesse Mailing List. For starters, check out the Quicktime Movie on SLIM that Bob Martin has posted on his blog.
I know that all of these resources can be a bit much to digest. The bottom line is that they will save you time in the end. My suggestions to use Fitnesse for developing functional integration tests for your software still leaves several other areas of your software untested. I'm not suggesting only testing with Fitnesse. I'm assuming your development team is already doing unit testing using tools like jUnit or nUnit. If they are not, you as a tester will be spending so much of your time identifying their bugs that you really won't have time to set up a Fitnesse regimen. Regarding GUI testing, what you need to do really depends on the context and the maturity of your other tests. I've worked on projects where the GUI was the least important thing. In such cases, manual testing through the GUI while doing exploratory testing can be a great compromise. If you have an existing GUI test tool (such as Quicktest Pro) go ahead and use that. You already know its weak and strong points. If you haven't bought a tool there is an open source GUI automation tool named Selenium which is pretty good. Reading enough about each of these resources to explain them to others and implementing some tests with them is a good next step. I would read these in combination with Janet and Lisa's book (which is currently available online).
I want to close with a comment: As a tester you use your judgment at every moment of every working day. You want to look under the rocks and find the hidden worms. All of the tools and practices above are really just so you have more time to do what you do best. It's now called "Exploratory Testing". Don't forget to explore because all the "predicted in advance" tests you and your customers create are very likely not to catch all the bugs. I've learned this from experience and I'll describe this a bit in the next section. Hopefully the idea of exploratory testing will ring true for you while reading about "My Philosophy".
