test objects design

I downloaded a paper by Jeff Jewell of ProtoTest presented at StarEast 2005 conference. PDF found at stickyminds (powerpass required) but I uploaded it to my server because when you google it it’s not found anywhere. It’s also too bad that the pdf is password protected and you can’t copy any content out. I uploaded it to my server as a reference (will not be indexed by robots)

“This paper will provide some of the information needed to successfully navigate the minefield of open source test tools. Some of the benefits and common misconceptions of open source software will be presented, along with information on what it takes to successfully use open source tools, how to find an appropriate tool, and what challenges may be faced in its implementation”

Jeff writes about the current state of Open Source tools for testing. Points to OpenSourceTesting and Tejas Open Testware Reviews.

So, what’s available? Mostly tools where testers would need to know some scripting language (like Python or Ruby). Most tools are for unit testing, performance testing and test Management: like FitNesse. I personally think Wiki is a great tool for collaborative requirements gathering.

For Functional Web testing there is Canoo but it’s for back end and it does not exercise GUI which is what we want to do to emulate the real user scenarios. There is also selenium which uses JavaScript and iFrame.

Lots of tools for performance testing (but not my specialty). I am all about functional testing, requirements and such… I did once use JMeter for some simple performance tests. Another one is OpenSTA and uses Script Control Language. Here are some general Rules of SCL usage.

As for defect tracking there is a slew to choose from but I think I would select FogBugz from Joel’s company. Not open source but worth it. For bug tracking I would definitely use FitNesse or some other Wiki. I think because the minute you find a bug it screams to have a test written against it and added to regression testing.

I think tracking bugs is for management mailny. Sometimes I think it’s a waste of time to manage a bug as a defect, I would rather manage it as a Test Case which either passes or fails. The real issue is that there is a bug and if we can reproduce it then this is a Test so I would put it in FitNesse, write a story in Wiki and track it that way.

I think using bug tracking is better if you have geographically dispersed team with customers and other shareholders who can enter bugs. I also found most bugs are misconceptions and/or non-captured requirements that are coming out as software progresses. Bug tracking tools are more about eliciting conversations for improving sotware. Any Bug Id is really a repository for the history of a conversation. The actual bugs should be in Tests like FitNesse or some other executable form.

It is true that “The landscape of software testing tools is dominated by a few high-end vendors with suites of tools that are very rich in features and relatively easy to use” but the problem with those tools is that they all use Vendorscript languages and many do not have any Frameworks defined. Out of the box they all mostly capture/playback tools. (XDE tester uses Java which I think is an over-kill and it’s very time consuming to write tests, at least my experience from the pilot project I did).

Technorati Tags: Agile Testing, test tools