This weekend we held the final IWST workshop for 2007. The topic of the five hour workshop was 'Scripting for Testers and Test Automation with Open Source Tools.' What a great workshop! We packed in seven experience reports (with open season questioning) and we talked a bit about IWST for 2008. Attendees for the workshop included:

• Andrew Andrada


• Charlie Audritsh


• Michael Goempel


• Michael Kelly


• John McConda


• Chad Molenda


• Cathy Nguyen


• Charles Penn


• Mike Slattery


• Gary Warren


• Chris Wingate


• Jeff Woodard

We opened the workshop with an experience report from Charles Penn on his experience learning Watir. Charles covered some of the resources he used to learn the tool and he shared the details of his experience trying to get popups to work. Charles currently uses Watir for some of his regression testing. He has a suite that he runs daily over lunch. The code Charles used for his popups can be found here: Pop Up Clicker and a Test Logging Example

Following Charles, Jeff Woodard shared an experience where he used AutoIT to automate the import and export of test cases with IBM Rational ManaulTest. Jeff worked at a client that required the use of Rational ManaulTest. He felt the tool restricted his productivity. So he created some simple scripts that allowed him to work in his tool of choice for test case design and documentation, then all he had to do was run the scripts to "check in" the tests. With about 2 days of scripting, he estimates he shaved over a week from his workload doing administrative testing tasks. He managed over 700 manual test cases using AutoIT. For those who might be interested in his solution, the AutoIT code can be found here: export and import

Next, Cathy Nguyen shared how she currently uses Selenium for her test automation. The application Cathy tests is very Ajax intensive, and Selenium was one of the tools that she could get to easily work with the application. She uses the FireFox recorder, then takes those tests and converts them to C# for integration and management in Visual Studio Team System. With a bit of help she was able to create an 'MS Unit Test' converter, allowing her to integrate her Selenium tests with the developer tests already in use. Results can be tracked in the team SharePoint site and the scripts can be stored in source control. One of her next steps is to get the scripts running as part of the continuous integration process. The code that Cathy used to convert the tests to MS unit tests can be found here: tbd

After Cathy, Chris Wingate and Chad Molenda shared a joint experience of using Watir for smoke testing multiple projects in multiple environments, with several builds a day. The testing load on the smoke test scripts required them to migrate the smoke tests from IBM Rational Robot to Watir (faster execution, parallel execution, and easier code maintenance). They experienced similar popup issues, but also had some threading issues and dealing with multiple concurrent browsers on the same machine. They are working on creating a new method that allows you to manage dialogs based on the parent window instead of the user32.dll. I believe they plan on sharing that code back with the Watir community when they are complete; so look for that code in a future Watir release.

John McConda then presented an experience of using RadView WebLOAD on a client project. WebLOAD has an open source model that allows for some features in the open source version with a commercial version for clients who need more features/users. John said that he was able to get it to work with some Ajax and did a quick demo against the Mobius Labs website.

Following John, Charlie Audritsh presented some scripting tips for performance testers. First he showed a trick he uses to script usage model paths using case statement with a random number generator. This simple technique allowed him to reduce the number of scripts required to implement his workload model, and also allowed him to implement fractional percentages for user groups/activities within the model. After that, Charlie showed a store procedure he wrote to help with performance test logging. He uses it for debugging and for detailed logging when he needs it (turns it off when he doesn't). An example of both techniques Charlie shared can be found here: dec_iwst_audritsh.wri

Finally, Mike Slattery shared a number of tools he has tried for his testing, including Jacobie, webunitproj, jwebunit, htmlunit, httpunit, and Selenium. He found he had some common problems he had to work through, regardless of the tool. Those included popups, difficulty in having the same tests do double duty as functional and performance tests, difficulty in testing stylistic aspects of the application, and general test code fragility. Mike did say something about the ability to build your own recorders in Selenium, something I wasn't aware of. I know I need to check that out.

On the topic of future IWST workshops, I'm sure we will do something for 2008. I don't think they will be every month, but we'll see what we can do. I plan on starting some discussions on the IWST mailing list and we'll see what the community has energy for. I will also get all this info (code and such - when I get it) up on the IWST site at some point. I think I need to upgrade and redesign a bit in the coming months.

Thanks to all who participated in the 2007 Indianapolis Workshops on Software Testing. The full list of attendees for 2007 include:

• Andrew Andrada


• Charlie Audritsh


• Dave Christiansen


• Howard Clark


• Lisa Etherington


• Michael Goempel


• Jason Horn


• Karen Johnson


• Michael Kelly


• Steve Lannon


• Kelvin Lim


• Baher Malek


• John McConda


• Scott McDevitt


• Rick Moffatt


• Chad Molenda


• John Montano


• Cathy Nguyen


• Charles Penn


• Kenn Petty


• Vishal Pujary


• Mike Slattery


• Michael Vance


• David Warren


• Gary Warren


• Chris Wingate


• Jeff Woodard

Every tester has a credit score. You use it every day. Each time you ask a programmer or analyst a question, when you talk to a project manager about your status, when you write up a defect, or when you deliver some other artifact, you are potentially impacting your credit rating.

This week in our online Rapid Software Testing class the topic came up, and it reminded me to relate a recent experience where I upped my street cred. It's worth relating because I think it's an often overlooked aspect of testing. As a tester, many times your effectiveness is relative to your current credit rating. Much like buying a house, even if you have the right information at the right time, you may be overlooked or have to go through a difficult process because of past mistakes or oversights.

In a recent meeting, we had an odd mix of people in the room. We were researching a high profile issue. We had executive management, middle management, project management, architects, technologists, performance testers, key programmers, infrastructure, operational monitoring, and me. I was lucky enough to get called in the night before. This was the status meeting.

At the meeting, several topics were bounced around, many of them works in progress. One of them involved pulling transaction times from a production log. Someone in the room had just pulled down the production log before the meeting. As we discussed the work in front of us, the issue of who would parse the log came up. The super smart Java programmer in the room and I, the tester, were sitting across from each other. We gave each other the "I have it" stare. I threw down the gauntlet and said I would do it.

(I might be exaggerating a bit here, but hey, it's my blog and this is how I want to remember it! We did look at each other, and I did say I would do it. The tumbleweed and high-pitched whistle may or may not have been there.)

Once I had the task, I popped open SciTE and got to work. Here is where the cool part comes in. Standing behind me was one of the more respected architects within the company. A smart, likeable guy, who everyone respects and looks up to. He was looking at my screen.

During the meeting, while the conversation continued, I coded. I filtered most of the conversation, listening/responding only when I absolutely needed to. When I wasn't focused on the conversation, I wrote a Ruby script. Because the architect was looking over my shoulder, I refused to spend a lot of time looking up methods online (pride dictated I had to do it without seeking help), so the code was a bit more complicated then it probably needed to be. In about 10 minutes, I had the finished script and ran it.

@sourceFile = 'C:\\file.log'@

@infile = File.open(sourceFile, "r")@
@responseTimes = []@
@thread9Begin = 0@
@thread9End = 0@
@thread10Begin = 0@
@thread10End = 0@

@#Log file entries look like this...@
@#12:28:29.494 COL D 10 (java_extensions.cxx:1442): ****** BEGIN@
@#12:28:32.914 COL D 10 (java_extensions.cxx:1442): ****** END@

@#0 - 12:28:29.494@
@#1 - COL@
@#2 - D@
@#3 - 10@
@#4 - (java_extensions.cxx:1442):@
@#5 - ******@
@#6 - BEGIN@

@infile.each { | line |@
@currentLine = line.split(' ')@
@if currentLine[6] == 'BEGIN' then@
@if currentLine[3] == '9' then thread9Begin = currentLine[0] end@
@if currentLine[3] == '10' then thread10Begin = currentLine[0] end@
@end@

@if currentLine[6] == 'END' then@
@if currentLine[3] == '9' then thread9End = currentLine[0] end@
@if currentLine[3] == '10' then thread10End = currentLine[0] end@
@end@

@if (thread10Begin != 0) and (thread10End != 0) then@
@responseTimes.push(thread10Begin.split(':')[0] + ", " +@
@(((thread10End.split(':')[0].to_i - thread10Begin.split(':')[0].to_i)*60*60*1000) +@
@((thread10End.split(':')[1].to_i - thread10Begin.split(':')[1].to_i)*60*1000) +@
@((thread10End.split(':')[2].to_i - thread10Begin.split(':')[2].to_i)*1000) +@
@(thread10End.split(':')[3].to_i - thread10Begin.split(':')[3].to_i)).to_s)@
@thread10Begin = 0@
@thread10End = 0@
@end@

@if (thread9Begin != 0) and (thread9End != 0) then@
@responseTimes.push(thread9Begin.split(':')[0] + ", " +@
@(((thread9End.split(':')[0].to_i - thread9Begin.split(':')[0].to_i)*60*60*1000) +@
@((thread9End.split(':')[1].to_i - thread9Begin.split(':')[1].to_i)*60*1000) +@
@((thread9End.split(':')[2].to_i - thread9Begin.split(':')[2].to_i)*1000) +@
@(thread9End.split(':')[3].to_i - thread9Begin.split(':')[3].to_i)).to_s)@
@thread9Begin = 0@
@thread9End = 0@
@end@
@} #infile.each@

@infile.close@

@puts responseTimes@

The best part, it worked the first time I ran it. I copied the results over to Excel, turned my laptop, and presented my results. The meeting wasn't even over and we could talk about the actual data. I got a small verbal pat on the back by the person asking for the information, and we moved on.

Fast forward a day or two...

At another meeting, on a completely unrelated topic, with a room full of different people (except for the architect), we were talking about implementing a new process for an automation issue. As part of that issue, we would need to write some Ruby code to populate some data via a web service.

At one point, I volunteered to write the code to populate the data. That drew some looks from the programmers in the room (I'm just a tester you know). It was at this point that the architect stopped the meeting for a minute to relate what he saw me do in the meeting, writing the code in a hostile environment and it working the first time.

That's the best feeling in the world. Someone else, not even a close friend, stopping a meeting to give you a vote of confidence. And because he has high street cred in the programmer community, I now have higher street cred in that community. It's was more influential then if I had found ten super obscure technical bugs. Probably more influential then if the developers had actually seen me write the simple script (I included it so you could see how simple it is - and I'm sure it could be simpler).

So what's your street cred? How do you build it? How do you cash it in?