What to test in a web application?

This content is syndicated from On Agile Leadership by Manfred Lange. To view the original post in full, click here.

Sometimes I'm asked what to test, in particular when I explain that testing the happy day scenarios is not sufficient. For example in web applications I'd certainly expect that everything that has a link to a different page actually brings you to that other page.

Another example would be any kind of control for entering data, e.g. text boxes, radio buttons, drop down lists, check boxes, and more. Let's take a text box for a product number. The valid range might be a positive number that has 6 digits. In that case you would also want to test whether you can enter less or more digits. The system should have a defined behavior. Then try entering spaces, e.g. 2 digits, then a space, then 3 more digits. Test whether you can enter nothing. Test what happens if you enter a mix of digits and characters. I'm sure you can think of more depending on the system you are working on.

One less obvious case are routes. A route allows you to enter a link that the system can interpret and translate in a specific way into a url. Routes allow certain items to be bookmarked. For example: you may want to support a url such as "http://nirvana.org/Product/246337/View" (of course your domain name would be different). The concept here is that you have the domain class name first ("Product"), the specific instance id next ("246337") and the method ("View") last. In essence a route is then: "http://nirvana.org/Product/{productId}/View". Depending on the technology you use to implement this route, somewhere you will have to extract the product id and create a url to the page that can handle this request.

The point I want to make is this: A route like this needs to be treated like a method. In essence it is similar to a method and hence there are quite a few test cases. Some examples of test you should consider:
  • No product id: "http://nirvana.org/Product//View"
  • Non-numeric product id: "http://nirvana.org/Product/foo/View"
  • Negative product id: "http://nirvana.org/Product/-123456/View"
  • Product id too short: "http://nirvana.org/Product/12345/View"
  • Product id too long: "http://nirvana.org/Product/1234567/View"
And this is just a selection for this very basic example. I'm sure you can think of more tests. The point is, sometimes things like this are easily overlooked and as a result your system may contain defects that you are not aware of. In the case of a web application it means, that if you allow people to bookmark certain pages, be aware that people not only can but will enter invalid URLs! Be prepared!


Leave a Reply

What is 5 + 2 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA