A while back as I was reading through the WATIR (Web Application Testing in Ruby) newsgroup, Chris McMahon announced a Bay Area DT/TD Summit. To read more about it you can read the official release information for it here. So anyways being that it is invitation only I went ahead and sent in an invitation. Below you can find my invitation and yes I did get invited and I also will be giving an experience report about what I talked about.

• Which are you:

I am a developer who tests.

• How did you come to have that role?

Started when I worked at Washington Mutual and we developed and maintained an automated testing software utilizing Winrunner and TSL.

• What languages do you usually program tests in?

I have used TSL with WinRunner, C# with NUnit and Ruby with WATIR

• What do you hope to contribute to the Bay Area DT/TD summit?

I would like to contribute a new way of looking at web application testing. One of the things I discovered at Washington Mutual was that the current pattern for web application testing, Record & Playback has several drawbacks:

1. No code reuse. Basically everytime we need a new script for a page we have to fire up our recorder and run through the page needed to be tested.
2. It is very rigid because with anything in life there is change. But what happens when there is change? Usually we have two options, if we are a developer then we might open our script and make the changes needed to address the change but what if we are just a tester and not a developer. Then that means that the tester would need to fire up the recorder and run through the page again to develop the new scripts.
3. Our results from the test run usually are limited to successful or exception with most likely a vague detail as to what the exception was. Not to mention that with a successful run we still might not be identifying bottlenecks because we ren’t able to identify areas within the test that are slow.
4. Tying back to #2 with most testing architectures we have developers that maintain both, the architecture for testing as well as the testing scripts themselves which can be costly.

The way that we addressed these drawbacks was as follows:

1.       As for addressing the concern of Code Reuse I believe that WATIR is definitely on the right track. By encapsulating the functionality in Ruby needed for communicating with web applications I believe that they have made the first step in this direction. But the Record and Playback pattern still exists, it’s just that now they are at least utilizing the functions from WATIR rather than straight Ruby. The way that I have implmented the solution that I discovered while working at Washington Mutual is that you encapsulate functionality for controls and then you have a driver that reads a simple xml script that dictates what needs to be done. For an example consider xml snippet that I attached with this email. You will see that with this xml snippet I indicate to the test driver several things: create a variable, utilize a variable, browse to a page, clear and set a textbox, click a button. I think you get the idea as to how to drive this. What makes this nice is that then all you need is a mapping for your application and you can have a small UI that shows all the information and then you can have just simple testers writing all the tests needed and not have to require developers to do so. I also attached a screenshot of a simple UI I was using to create these scripts. This was written for me to test a dotnetnuke site so it isn’t very simple but it could be I just was building a prototype quickly to display it’s functionality.

2.       To address the changing application all we would need to do is update the application mapping that went along with the UI for creating the scripts and then at that point we can again have our testers make the changes and no longer do we need to have developers spend their time with that.

3.       The results are nice because now we can generate results for every step of the test as well as time spent running each step and exceptions that indicate which step of the test caused the exception. I also have attached a results file that you can look at it. It was written to integrate into CruiseControl.Net but you could really have the results come out in any fashion. At Washington Mutual we created pdf files through a COM library.

• Do you have any code or examples that you’d like to share?

I do have some code that I wrote a while back utilizing Ruby and WATIR that demonstrates what I believe to be a better pattern of implementing web application testing. Though really we could use it to do both web and application testing as long as our underlying language could communicate with the application. I submitted it to the Ruby and WATIR newsgroups but I only had a few people express interest and so they may have done something with it.

• What do you hope to get out of the Bay Area DT/TD summit?

I hope to get out of it a better way of implementing a testing architecture. Like I have mentioned the only thing I hear so many people talk about is Record and Playback scripts so I would like to see if there are other patterns out there for implementation of testing.