devXero's blog

a blog about agile, development, and automation

Posts Tagged ‘Agile Development’

SWAT 3.0 Released

Posted by Mike Longin on January 19, 2011

We are very excited to announce the release of SWAT 3.0.  The biggest announcements are the new support of Chrome on the Windows OS and Safari on OSX.  In addition we now support calling SWAT from the command line independent of any test runner tool.   Finally we have made a roughly 30% improvement on the speed of SWAT running against the IE browser.  As usual we have also fixed a number of bugs and smaller issues that are detailed in the complete release notes.
New Features and Updates
  1. New Browsers Supported
    1. Chrome
      1. New custom built plugin for Chrome allows SWAT to easily control the Chrome Browser
    2. Safari
      1. Custom app for OSX now allows SWAT to stream commands to an OSX based system.
  2. SWAT Console
    1. Tests can now be run independent of any test runner.
    2. As of now this feature is for SWAT only and does not support any custom fitnesse fixtures.
  3. New Commands
    1. UI
      1. AssertJSDialog
        1. Added an optional timeout to allow users to select how long the command will search for a dialog box
      2. AssertTopWindow
        1. Allows users to verify if a window is the top most window on the screen
    2. Database
      1. RestoreAllTables
        1. Users can now restore all of the tables they have saved at once instead of one at a time
  4. Defects Resolved
    1. CORE – AttachToBrowser always finds the about:Blank window
    2. CORE – DB Connect now automatically closes the old connection when it creates new ones
    3. CORE – FF – AssertElementExists will find an element when the identifier is empty
    4. CORE – FF – PressKeys does not ignore CancelEvent in Javascript
    5. CORE – FF – Special characters above the standard 128 return correctly when
    6. CORE – FF – The AttachToWindow failure due to “OK” being added to title has been fixed
    7. CORE – IE – attachToModalDialog is now setting the currentIEBrowser
    8. CORE – IE – Browser screenshots work correctly in IE9
    9. CORE – IE – KillAllOpenBrowsers is now respecting AbandonTest
    10. CORE – IE – OnBeforeUnload JSDialogs in IE9 are compatible with SWAT
    11. CORE – IE – PDF pages open automatically in IE9
    12. CORE – Screenshots don’t throw a “Not attached to window” exception.
    13. CORE – SQL checks are passing in the editor and not in Fitnesse
    14. CORE – SWAT waits for all frames to load when waiting for the browser
    15. EDITOR – Editor is respecting the -c attribute for included files
    16. EDITOR – Values of 0 can now be saved in the Delay between commands option

Posted in Uncategorized | Tagged: , , , , , | Leave a Comment »

Cloud Based Management

Posted by Mike Longin on August 23, 2010

This blog is probably not what you think it will be about.

Where I work we have a very flat management structure.  What this means to us is that their are very few steps between an employee and a director.  In fact virtually all members of a team report directly to a director.  Currently there are about 200 members of the staff and 2 directors (though we are scaling up to 4).  As part of this, we have created what I am calling a cloud based management team.  What this means is that while people have a direct supervisor, they tend to go to any supervisor to discuss any issue.  If director A is busy, people go see B and vice versa.  This tends to allow people the ability to talk to people that they are most comfortable with and also allows more access to our directors since they are so interchangeable.  Overall I have found this to be an incredibly simple, yet effective way to manage a large group of people without a large amount of overhead.  It is definitely not a perfect solution (which I believe to be one of the reasons we are scaling up), however it has been working well for us.  I believe that as we scale up it will be more like adding nodes to the cloud and not forcing people to deal with one specific manager.

Posted in Uncategorized | Tagged: , | Leave a Comment »

South Florida Code Camp 2010 Presentations are up

Posted by Mike Longin on March 1, 2010

I have posted the presentations Chris Taylor and I did at the South Florida Code Camp.  You can find them here


An Introduction to UI testing using SWAT

Applying modern software development techniques to automating the web UI

Please let me know any feedback or questions you might have.

Posted in Uncategorized | Tagged: , , , , , | Leave a Comment »

Automation is validation

Posted by Mike Longin on October 28, 2009

At a presentation I did earlier this week one of my coworkers made the comment

Automation is for validation, testing requires hands, eyes, and a brain

I have heard similar comments before but I thought that this was worth repeating.  When you create and run automation, you are validating against what you already know.  The script (whether its above or below the UI) was based on some known state and values.  For the most part the automation can only tell you when something expected did NOT happen.  The majority of scripts will not tell you when something unexpected did happen.

For example if I have a login page that takes a user name and password.   When I fill in the user name and password, and press a button I log in.  Now if someone were to add an additional step to my login process, any automation I have would obviously catch that.  However if someone added something that did NOT affect login to the login page then most likely my scripts would NOT catch that.  These things could include changes to the UI, popups, new text, or possibly something more malignant.

This is where the basic difference between automation and testing come from.  When you test you not only are working with base data and expected results, but you have the ability to comprehend the unexpected. What extensive automation really does is allow testers more time to look into the unexplored areas of the system.  More time can be spent on exploratory testing since your regression suite is handling all of the expected tests and scenarios.  By spending more time doing this you are liable to find all of those edge case scenarios that your customers are guaranteed to find.

So in sum it all up, automation is a hugely important part of the development process, but to help identify that what is working hasn’t broke not to “test”. When it comes to testing, it takes someone (or maybe one day something) that can identify the unexpected and can appropriately identify what to do about it.

Posted in Uncategorized | Tagged: , , , , , | Leave a Comment »

Agile 2009 – Applying modern software development techniques to automating the web UI

Posted by Mike Longin on August 28, 2009

Chris Taylor ( and I have been working on this presentation for the past year.  The synopsis is that we need to take the lessons learned from development and apply them to automated testing.

Two quotes have really influenced us in this:

  • “Automated testing done right is Software Development” –Elfriede Dustin and Marcus Borch @ GTAC 2008
  • “Recorders are the training wheels of the automation world” –Loosely translated from Jason Huggins @ AA-FTT 2009

The presentation went off really well.  The best part were the questions at the end and the realization that we need to start providing tools for new people to really learn automation techniques.  Over the next month I am going to start creating smaller presentations on how to create automation from the ground up and how to avoid different pitfalls.

You can find the slides for the presentation here :

Below are also some of the pictures from the event (thanks John for taking these for us)

Posted in Uncategorized | Tagged: , , , , , , , | 1 Comment »

For internal builds is it acceptable to have some failing tests?

Posted by Mike Longin on December 19, 2008

So the typical answer to this question is no.   Usually with some harshly worded questions such as:

  • Why would you have a test in there, if you dont mind if failing?
  • Why would you even consider releasing a build with failing code?

But let me add some context.  When you have 20+ teams using the build and the test that fails is specific to one team AND the code is for a more “minor” feature.  Does that change the equation?  Or how about it affects 5 teams, but not the other 25.  Is that ok?

I am curious what people think.  

To me its worth starting to think of multiple tiers.  Tier one tests must pass every time.  Tier 2 tests are tests that affect 10% of the teams and while an internal build can be deployed, these teams must code freeze and fix the issue.  Tier 3 tests are limited to an individual team and that team would need to freeze and fix but everyone else can continue.  I am sure someone will tell me I am wrong, but to me its worth at least thinking about.

Posted in Uncategorized | Tagged: , , , | Leave a Comment »