Selecting a test automation tool has always been a daunting task. Let’s face it, just the thought of automating tests can be daunting! The selection of tools available today, especially open source tools, is positively dazzling. In the past several years, “test-infected” developers, not finding what they need in the vendor tool selections, have created their own tools. Fortunately for the rest of us, many are generous enough to share them as open source. Between open source tools and commercial tools, we have an amazing variety from which to choose.

To avoid that deer-in-the-headlights feeling, consider taking an ‘agile’ approach to selecting web testing tools. Plan an automation strategy before you consider the possible tool solutions. Start simple, and make changes based on your evolving situation. Here are some ideas based on experiences I’ve had with different agile (and not so agile!) development teams. Even if your team doesn’t use agile development practices, you’ll get some useful tips.

It is becoming clear, not least from the pages of this publication, that agile development methods are being adopted or at least considered by a growing number of software development teams & organisations. Whether you are already an active practitioner agile development, or considering its adoption on your project, you will be aware of the business benefits that can be derived through faster and more effective software delivery not to mention the motivational impact it can have on development teams. Alternatively, maybe you work for a large organisation that has yet to make any serious inroads into agile development, and are left wondering how agility could be made to work on a large scale.

This article shows how continuous integration can help to keep projects on track with a rapid feedback on the product status.

Methods & Tools is a free e-newsletter for software developers, testers and project managers. Fall 2007 issue's content:
* Measuring Integrated Progress on Agile Software Development Projects
* Lean Configuration Management
* Refactoring Your Development Process with Retrospectives
* Mass Customizing Solutions

40 pages of software development knowledge.

To download or read this issue go to http://www.methodsandtools.com/mt/download.php?fall07

Rest In Peace (from Latin requiescat in pace) is a sentence that typically appears on christian tombstones. Software development projects have usually the same destiny. Once they are finished, often the best thing that will happen is a little celebration for the project team. Nobody will formally look back at a project to understand what went well or wrong and why those things happen, so that this project can actually rest in peace and lessons learned could be used for the next projects.

The argument has been made: "We should be using an Agile software development method." And the command has rung out: "Make it so!" Now what do you do? How do you take that one-line "requirement", and make it so?

Adopting an Agile method is no different from any other change we might make to the methods and tools we use. We must determine why we are embarking on this course, choose the method that will satisfy the need most closely, then map out the path from where we are today to where we need to be. Then we can "make it so".

Refactoring is a powerful technique for improving existing software. Having source code that is understandable helps ensure a system is maintainable and extensible. This paper describes the refactoring process in general and some of the benefits of using automated tools to reliably enhance code quality by safely performing refactoring tasks.

In the rocket-fast late 90s, I struggled with using traditional software process and testing practices on e-commerce applications. Then I read Kent Beck’s Extreme Programming Explained and had an amazing ‘aha’ moment. Ron Jeffries sums it up best: Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation. (www.xprogramming.com)

Applying more discipline to traditional waterfall process had not helped my team. A new kind of discipline based on values such as communication, simplicity and feedback might be the answer! I immediately took an opportunity to join an XP team as a tester, and enjoyed working on XP teams for the next 18 months. Indeed, XP did allow us to produce high-quality e-commerce applications on time and on budget! Our customers were happy! We were happy! We struggled some with how I, as tester, could best contribute to the team, as the XP literature at the time didn’t say much on that subject. With the whole team focused on quality and testing, we came up with some great solutions. I was so excited about XP testing that I co-authored a book on it (Testing Extreme Programming, with Tip House).

In a period where the trend is to follow agile approaches with condensed guidance (see the 12 principles of the Agile Manifesto for instance), it could seem strange to publish a book on software development with more than 500 dense pages. You should however not be frightened by this book. Beneath the size and the structured form lies an approach based on practical experience that incorporates change and flexibility without abandoning the quest for precision and delivering value.

Following a dzone.com link, I reached an article accompanying a presentation made by Joe Rainsberger at the Agile 2007 conference. This article, "My Greatest Misses: XP 2000-2007", is an honest experience report on the many issues and failures met by Joe Rainsberger as an agile change agent during these years, trying to teach others the merit of the extreme programming approach created by Kent Beck.