Testing any web page approach

Question

How should one approach testing a web page with tabs (linking to other pages), frames or form? What should be the general methodology? What could be the various test cases?

I was asked this interview for a Junior QA Engineer position without requiring to be very specific. And, I couldn't comprehend the question very clearly.

Some of the test cases I could think of: 1. Using various browsers to display the page

1. Modifying the address of the page by adding/removing some fields

2. For forms requiring numeric input, entering the boundary values, one legitimate value, and a couple of invalid values. Applying the same logic for other fields.

I couldn't get any great feedback from the interviewers. Any other ideas/suggestions?

Answer 1

Other than the usual functional software testing (stuff like SQL injection, business use cases and whatnot) one would do for all software, there are a number of things you should test with web software:

1. Testing over different Internet connections
2. Testing with different network-using applications running on the client (does the site work in bit torrent applications are running?)
3. Testing with multiple browsers, with multiple plugins, with different default colour schemes defined and default font sizes/zoom levels/font faces.
4. Disabling JavaScript (not always applicable)
5. Fiddling with HTTP GET and POST requests to make sure validation is handled properly.

Depending on the app you might also want to test on embedded browsers in cell phones and video game consoles.

Answer 2

The test cases you have listed are all good. Some other ones to consider.

• Make sure all user input is validated and sanitized. Anything that goes to the Database could possibly be an injection attack. Anything that displays user entered data could be used as a cross site hijack.

• If the site uses javaScript, does it still function/provide an alternative if javaScript is disabled, same goes for flash

• Do you have CSS for devices other than standard monitors? Can user view the site on hand held devices in an acceptable manner? How about printers?

• Accessibility concerns. Are there alternate titles for images etc.

• What about search engines? Is the site/page bot friendly?

• More of a design question: Does the site do/show what the company thinks is important or what the user thinks is important.

These are just a few off the top of my head. There are many more to do for a complete job.

Answer 3

For bonus points I would also mention using WinRunner or other automated GUI testing tool, so that you don't have to run the tests manually for every release.

Interviewers like people who think outside the box :)

Answer 4

When asked testing stuff, always push way farther than your initial reaction. whenever people ask these sorts of questions, they want to see how long you can talk about test cases. with longer almost always being better.

some tests for web apps i didnt see: -Security - hit on all aspects of this - cross site scripting, does it take in secure data? if so, how is that data handled?

-load testing. web sites should be able to handle large amounts of users simultaneously. you need to test this to make sure it can. with load and stress testing, its usually good to try to find the breaking point of a site/system and then verify if that breaking point seems acceptable.

-Can the website be viewed in a variety of languages? if a good character encoding is used it should work ok. If it isn't then it might show up as strange characters.

-try sending it values far larger than it would normally accept. are there restrictions on the input fields? does it give errors? or just blow up?

-As mentioned above, show some insight about automation tools. what sort of automation framework could you set up? could you make your own tools? what tools would work well? etc.

Answer 5

The answers above give some great examples for how and what to test regarding web apps.

I'm going to respond real quick to a few other points in your question:

When I interview for positions on our QA team, I have two primary concerns: the way the interviewee thinks and their knowledge of the underlying technology domain.

I've interviewed students and professionals whose idea of testing an application is to "turn it on and see if it smokes." They often had a great understanding of the product technology (e.g. the innermost workings of HTTP), but they couldn't connect this knowledge to a practical and systematic application (e.g. how to test a database app which communicates with a server via HTTP).

I've also been deluged with test cases by interviewees who simply didn't understand the underlying technology being exercised (e.g. networking tools, simple Java apps, database clients). Their lack of understanding greatly impaired their ability to arrive at insightful and useful test cases, even though they were able to provide a large number of tests.

In either case, I would highly recommend (for any type of interview) you first research the field in which you would be working prior to the interview. Don't just attempt to integrate jargon and buzz words (you'll look foolish if you get them wrong), but investigate the position with an intent at learning what it entails. The more you know prior to the interview, the better you'll understand the context in which the questions are coming from.

Also, never hesitate to ask for clarity on an interview question. I get annoyed when someone doesn't understand what I'm asking and tries to fake it. If someone asks me to reword or clarify something I've said, I usually take this as a good sign of someone who desires to communicate accurately.