An Introduction to SWAT 2.0


 SWAT or Simple Web Automation Toolkit is an open source web automation testing tool developed by software engineers and testers who work at Ultimate Software. Currently SWAT is used in-conjunction with Fitnesse Framework however it is not dependent on FITNESSE being installed, but currently formatting is based of Fitnesse Pipe formatting.

Here are some screen shots of the currently public version 2.0


Version 2.2 SWAT Recorder


Assertion Tool



SQL Assertion Tool

Christopher Taylor

Software Engineer in Test & Agile Coach Certified Scrum Master

You may also like...

4 Responses

  1. Ryan Morgan says:

    Where is the download for this?

  2. Rocky says:

    I’ve had the benefit of woknrig with Architects on both a failed and a successfull agile endeavour. It’s obvious that the integration of architecture within agile is a poorly understood and continually emerging relationship. I still don’t think i’ve witnessed the perfect integration, but in comparing the 2 cases i mentioned, one may find a nugget or 2 of wisdom. It’s worth noting that this exact topic at Agile 2008 in Toronto had only one session of attention directed towards it, although Ron Jefferies made several comments about it in some of his sessions.Very quickly, in the failed implementation, Architecture was almost comically proud of their ivory tower status. They created Enterprise Architect diagrams for system interfaces that were either already implemented, currently being developed, or nowhere near the next 2 or 3 sprints. Their work never appeared on the Product Backlog, and the PO had no idea why they inhabited the same floor space. The obvious collisions occurred as you might imagine. Interfaces were implemented by devs in complete disregard of an Architecture team that was disengaged from the current product development rhythms, and as a result, Arch spent most of their time trying to force Dev to refactor woknrig stories to fit their models’. Ridiculous? They were hired by the VP, so that gives you some insight into why it was tolerated, and ultimately failed. I almost forgot, they also didn’t code.Ok, now onto the good stuff. At Logitech we have decided to retain the Arch group because of the complexity of the product, and to drive consistency across 5-8 scrum teams. However, there are very clear guidelines that we impose on them to keep it as Agile’ as possible, and not break too many rules.1. Archs code too: The only way an Arch will live in harmony with a bunch of crack senior devs, is to possess the same willingness and skill deep inside the codebase.2. Architect kind-of just in time’: For a complex framework that requires a significant amount of design, it’s probably too ambitious to rely on a bunch of XP Devs to emerge the architecture in a highly refactorable way that doesn’t incur too much waste. So, in other words, the stories ultimately trigger the need for architecture, but we Load Up that first story with as much of this design/prototyping as we can get away with, and still deliver something testable and usable for the user. Future stories in that functional area will always force us to revisit the architecture and the interface design, but at least we have meatier platform to work with. The counter argument here is that we might be inadvertantly creating waste because we don’t know how the arch will emerge throughout the project, but i don’t buy it, because there is always a bunch of core and crud-like’ stuff that needs to get built as part of your overhead cost of creating a robust platform. A good example is error handling. The obvious waste in creating a quick and dirty solution for one story should be avoided, because you know that eventually you’ll have to create a centralized error handling mechanism, which of course will never be a user story.3. Architects bind to stories: Rather than having them operate as their own scrum team, we have decided to lend them out to the scrum team that has picked up a story that requires arch input. So, in the previous case, an Arch would probably build a starter’ error handling component to be delivered with the first story that required it, and with some quick knowledge transfer, devs could handle the rest. This doesn’t help us derive clean team sprint velocities, but in a Scrum of Scrums setup, we are also concerned with the team’s overall Product burndown. It’s the trade-off in our scenario, but the teams love having the archs work closely with them on stories that require that bridging effort across the platform. That’s what the Archs do, and it help the devs to concentrate on acceptance criteria, TDD, and the ultimate delivery of a story. The primary reason i don’t gravitate completely to XP is because complexity creates specialization. This is a dynamic that is as apparent in human social development as it is in product development. We can’t rely on a model of equally brilliant and capable Devs who can work on anything. Specialization, interspersed with as much knowledge sharing as we can afford, allows Archs to coexist with devs and to platoon from scrum team to scrum team, depending on the stories that require their input.4. It’s ok to create a Technical Story’: We have negotiated a 15% budget to work on technical’ or Arch related stories. That means that our public velocity is 85% of our average story points capacity. This prevents a lot of discussion around proving that a technical story is required in order to complete what seems like a simple user story.Once again, i know we have made some un-Agile compromises, but the alternative of a pure Agile approach was untenable. Like everything, we iterate and we retrospect, and through it all, we keep a close eye on the principles and values that keep us honest. The purist in me feels guilty, but i can live with that, because after all, it’s the user that ultimately determines success.Nuno

  1. January 4, 2011

    […] An Introduction to SWAT 2.0 August 2008 2 comments […]

Leave a Reply

Your email address will not be published. Required fields are marked *