The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

testing resources

I have been tasked with developing a testing approach/plan for a fairly large website my employer is developing.  Can anyone recommend any online resources or books that may be helpful.  I'd really like to see some templates or examples of what others have done.  At this point I would like to keep it pretty simple but also want to make sure the approach is effective as well.

Tuesday, December 19, 2006
I have recently been exposed to the glory that is Watir. I would strongly recommend using this tool to develop automated functional tests for the website.

There is a small learning curve, and there will be a significant amount of Ruby coding required (nothing strenuous, however) but we've found it to be a huge improvement over traditional record type testing tools.

Currently, it only supports IE, though there is a firefox version, called fireWatir. You'll probably have to do your portability testing some other way.

Good luck.
Bruce Rennie
Tuesday, December 19, 2006
Consider using an automated testing tool. Web site testing lends itself well to these tools.


for Mercury products. There web application tools are mature and there is wide support in industry for their applications.

I would also evaluate IBM Functional Tester but if you are not a Eclipse/Java shop, I would be hesitant to fully endorse it.

Tuesday, December 19, 2006
The tool suggestions above address how to execute testing, but don't really address what to test, which is what a test approach is.  If this is the first time someone has asked you to produce one, it's kind of an odd exercise.

First, recognize that you have some pretty significant prerequisites, and second that you have to consider multiple audiences.  But what it all comes down to is making sure that it does what it's supposed to do.

The prerequisite comes from needing a good definition of "what it's supposed to do."  I wish this were as easy as it sounds.  Look at how much is written about whether/how to write specifications to see what you're up against.

Once you have a good spec, you have two questions to answer.  It's really the same question answered for two audiences, but the answers can be pretty different: How do you ensure that it does the right thing; and how do you demonstrate to your client that it does the right thing?

Answering the first question will involve unit testing, regression testing (for upgrades), creation and execution of test scripts, etc.  It's possible a large part of the execution will actually be done by the developers.

Answering the second question -- satisfying the client -- requires you talk talk in terms of: user interaction, use cases, end-to-end scenarios, scalability/performance/load testing, support and training needs, etc.

Imagine you are presenting a sales pitch to a client, and you need to describe how you can demonstrate the value and correctness of your application.  Write a narrative proposal, eg:

"Working with end users and subject matter experts (name names if possible), we will define use cases that describe the expected functionality of the application.  This process should take $X hours of the users' time over the course of $Y days. 

"These use cases will be executed and verified by $someone, using $volume of data extracted from $source.  Developers will also create automated scripts to be executed on $tool, simulating $how_many concurrent users executing $how_many transactions per second for $how_long."

You're not trying to actually write the test scripts yet.  Start out with the higher-level description of what types of testing you expect to do, and who is responsible for writing and executing each type.  Theoretically you may not know the performance figures in that second paragraph, but I find it's better to put some numbers in front of the stakeholders and let them disagree.
Drew K
Wednesday, December 20, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz