Overview of Web Application UI Automation

I recently returned from a road trip through the Midwest where I spoke to the development teams at companies like Payless Shoes and H&R Block. I was there to represent my parent company Volt (staffing) as well as to evangelize Microsoft technologies and MSDN Magazine (where I’m a Contributing Editor). I learned a ton, including: Web applications and Web services are still hot topics, the job market for Web developers (especially ASP.NET developers) is unbelievably hot, and nobody does Web application UI test automation. Let me address this last point by describing four general approaches to writing Web app UI test automation, and why these approaches are fatally flawed in most work environments, and then describe what I think is a part of the solution to the problem. One approach to Web app UI test automation is to buy, learn, and use a commercial test framework. But commercial frameworks are expensive, have a significant learning curve, lead you towards testing based on the capabilities of the framework rather than the needs of your test effort, and add an external dependency to your effort. A second approach is to use an Open Source framework such as NUnit.ASP or WATIR. The downsides are similar to commercial frameworks except that you don’t pay anything but in return you get questionable quality and increased instability in the tool code base. A third approach is to write custom Web app UI test automation using a language such as Java or C#. The downside here is that, in general, the time and effort required to write your automation is too much relative to the payoff you get in bugs found / improved product quality. Put more simply, you usually just don’t have time to write test automation. A fourth approach is to write test automation using a scripting language such as Perl or JavaScript. The downside here is that scripting languages are generally a bit too lightweight to use for UI test automation and so the time you gain by using a scripting language is lost due to the increased complexity of your code. Anyway, I’ve been looking at Web application UI test automation using Windows PowerShell, Microsoft’s new scripting language and shell environment and I think this approach is a big advance. PowerShell can call the .NET Framework directly, has built-in cmdlets which shorten the size of your scripts (and therefore development time), has an interactive mode which greatly speeds up script writing and gives you a virtual help system, and has a modern set of command structures and error-handling capabilities. I’ve written up an article describing the details for MSDN Magazine and hope to see it in print soon. I demonstrated Web application UI test automation with PowerShell to several companies and groups in the Midwest and it generated a lot of interest. 
This entry was posted in Software Test Automation. Bookmark the permalink.

2 Responses to Overview of Web Application UI Automation

  1. mike says:

    I like your basic premise but it seems like you are really under rating the value of the open source frameworks.  I\’ve extensively used several of them, most recently watij, to do UI unit testing and then built it up to do full acceptance testing driven via fitnesse.  The \’questionable quality and increased instability\’ has been a small issue compared to the power that you can leverage.  I have no experience with PowerShell but building your own vs. leveraging proven open source doesn\’t seem like the easy choice you imply in your post.

  2. Sharon says:

    I also used open sources like -selelium and fitnesse for web UI application testing and aceptance testing. I think they are quite easy to learn. But sound like PowerShell is another great source for testing. I am very interesting to learn it if I have chance.

Comments are closed.