Website Development : Testing

komodosp

Hi folks

Prior to this all my formal testing experience comes from Mainframe / COBOL type systems where, while the system would be huge, the path of execution was fairly predictable.

But now that I am working in website development, I'm beginning to find the little bugs creeping in, and I'm finding testing - in the traditional sense - quite difficult to do.

Anyone know if there are any resources out there on how to create solid test plans for websites? esp. E-Commerce ones? I'm talking about proper formal testing here, not just firing up the website and checking everything works on the main browser.

Thanks guys

Colonel Panic

Testing what about the website?

We use ASP.Net MVC so I use VS2010's built in unit test stuff for all the data access and controllers and there's Selenium which does browser automation to test that the UI works as expected.

As for how it looks in different browsers, To be honest, I don't try to make it look the same, we just try to make it look as good as I can in all browsers, although that aspect isn't my main focus.

Evil Phil

Do you have a tester on your team? I've always found that I can unit test my stuff to make sure it's doing what it's supposed to do but a tester has a different focus and will always do a better job than the developer. Hence they're so important. But I'm a dinosaur, maybe the world has moved on from that as well?

I did find it helpful to get input from the tester(s) when drawing up my unit tests.

Colonel Panic

No, your assumptions are right. Unfortunately for me the reality is the only testing the web app I've developed gets is via unit tests I've written and some Selenium macros!

Raladic

Now this might sound simplistic, but the basic mindset you need to have in your head if you want to test something is "how can I break this?".

Developers mostly have the "happy path" in their mind when writing code where users click exactly the buttons and fill in the values the developer wants them to. As a tester I test that the happy path works, but much more so, that the other less happy paths (aka edge cases) are blocked. So if there's a text field, see if it can handle an script tags, special characters, characters outside of the normal character set as input.

If you plan to write a test plan, then you should consider all areas - performance, security (threat models and mitigations), world readiness (encoding, globalization, localization), usability, accessibility, functionality, compatibility, programmability, IO, configurations, look and feel...
If you want to plan how to test your program/site then sit down and try to come up with test cases for all those areas (where applicable), e.g. for security what is done about DoS, how is data protected (encryption..) then move to the next area - this should give you a comprehensive list of areas which you can then prioritize.

Testing your own feature is always harder as you get blind for mistakes when you look at your code, so even code reviews from other developers can help prevent bugs before they are hit.

druidhill

You must have users test it or the team tester, it's not enough for just you the developer (even if you are a team of one).

I tested websites, long time ago now, and I am no longer in this area. Things have moved on greatly I would imagine, especially in terms of automation (for me it was strictly manual testing).

One of the most useful things I did was to test the website when the developer said it was ready for testing, without any specifications or requirements.

Sounds silly, but you have to have to see if from a raw/new users' point of view and not the "happy path" that Raladic refers to.

And another thing when a developer says its ready, it's not ready.