Black-Box Testing


Remember all the way back to Chapters 4 through 7, the ones that covered the fundamentals of testing? In those vitally important chapters, you learned about black-box, white-box, static, and dynamic testingthe raw skills of a software tester. Web pages are the perfect means to practice what you've learned. You don't have to go out and buy different programsyou can simply jump to a web page, one of your favorites or a completely new one, and begin testing.

The easiest place to start is by treating the web page or the entire website as a black box. You don't know anything about how it works, you don't have a specification, you just have the website in front of you to test. What do you look for?

Figure 14.2 shows a screen image of Apple's website, www.apple.com, a fairly straightforward and typical website. It has all the basic elementstext, graphics, hyperlinks to other pages on the site, and hyperlinks to other websites. A few of the pages have form fields in which users can enter information and a few pages play videos. One interesting thing about this site that's not so common is that it's localized for 27 different locales, from Asia to the UK.

Figure 14.2. What would you test in a straightforward website such as this?


If you have access to the Internet, take some time now and explore Apple's website. Think about how you would approach testing it. What would you test? What would your equivalence partitions be? What would you choose not to test?

After exploring a bit, what did you decide? Hopefully you realized that it's a pretty big job. If you looked at the site map (www.apple.com/find/sitemap.html), you found links to more than 100 different sub-sites, each one with several pages.

NOTE

When testing a website, you first should create a state table (see Chapter 5, "Testing the Software with Blinders On"), treating each page as a different state with the hyperlinks as the lines connecting them. A completed state map will give you a better view of the overall task.


Thankfully, most of the pages are fairly simple, made up of just text, graphics, links, and the occasional form. Testing them isn't difficult. The following sections give some ideas of what to look for.

Text

Web page text should be treated just like documentation and tested as described in Chapter 12, "Testing the Documentation." Check the audience level, the terminology, the content and subject matter, the accuracyespecially of information that can become outdatedand always, always check spelling.

NOTE

Don't rely on spell checkers to be perfect, especially when they're used on web page content. They might only check the regular text but not what's contained in the graphics, scrolling marquees, forms, and so on. You could perform what you think is a complete spell check and still have misspellings on the page.


If there is contact information such as email addresses, phone numbers, or postal addresses, check them to make sure that they're correct. Make sure that the copyright notices are correct and dated appropriately. Test that each page has a correct title. This text appears in the browser's title bar (upper-left corner of Figure 14.2) and what is listed by default when you add the page to your favorites or bookmarks.

An often overlooked type of text is called ALT text, for ALTernate text. Figure 14.3 shows an example of ALT text. When a user puts the mouse cursor over a graphic on the page he gets a pop-up description of what the graphic represents. Web browsers that don't display graphics use ALT text. Also, with ALT text blind users can use graphically rich websitesan audible reader interprets the ALT text and reads it out through the computer's speakers.

Figure 14.3. ALT text provides textual descriptions of graphics images on web pages.


NOTE

Not all browsers support display of the ALT text. Some only show simple TITLE text in the tooltipor nothing at all. Since this could prevent the blind from using the Web, it should be considered a serious accessibility bug.


Check for text layout issues by resizing your browser window to be very small or very large. This will reveal bugs where the designer or programmer assumed a fixed page width or height. It will also reveal hard-coded formatting such as line breaks that might look good with certain layouts but not with others.

Hyperlinks

Links can be tied to text or graphics. Each link should be checked to make sure that it jumps to the correct destination and opens in the correct window. If you don't have a specification for the website, you'll need to test whether the jump worked correctly.

Make sure that hyperlinks are obvious. Text links are usually underlined, and the mouse pointer should change (usually to a hand pointer) when it's over any kind of hyperlinktext or graphic.

If the link opens up an email message, fill out the message, send it, and make sure you get a response.

Look for orphan pages, which are part of the website but can't be accessed through a hyperlink because someone forgot to hook them up. You'll likely need to get a list from the web page's designer of the expected pages and compare that with your own state table.

Graphics

Many possible bugs with graphics are covered later under usability testing, but you can check a few obvious things with a simple black-box approach. For example, do all graphics load and display properly? If a graphic is missing or is incorrectly named, it won't load and the web page will display an error where the graphic was to be placed (see Figure 14.4).

Figure 14.4. If a graphic can't load onto a web page an error is put in its location.


If text and graphics are intermixed on the page, make sure that the text wraps properly around the graphics. Try resizing the browser's window to see if strange wrapping occurs around the graphic.

How's the performance of loading the page? Are there so many graphics on the page, resulting in a large amount of data to be transferred and displayed, that the website's performance is too slow? What happens if you test on a slow dialup connection instead of your company's fast local area network?

Forms

Forms are the text boxes, list boxes, and other fields for entering or selecting information on a web page. Figure 14.5 shows a simple example from Apple's website. It's a signup form for potential Mac developers. There are fields for entering your first name, middle initial, last name, and email address. There's an obvious bug on this pagehopefully it's fixed by the time you read this.

Figure 14.5. Make sure your website's form fields are positioned properly. Notice in this Apple Developer signup form that the middle initial (M.I.) field is misplaced.


Test forms just as you would if they were fields in a regular software programremember Chapter 5? Are the fields the correct size? Do they accept the correct data and reject the wrong data? Is there proper confirmation when you finally press Enter? Are optional fields truly optional and the required ones truly required? What happens if you enter 9999999999999999999999999999?

Objects and Other Simple Miscellaneous Functionality

Your website may contain features such as a hit counter, scrolling marquee text, changing advertisements, or internal site searches (not to be confused with search engines that search the entire Web). When planning your tests for a website, take care to identify all the features present on each page. Treat each unique feature as you would a feature in a regular program and test it individually with the standard testing techniques that you've learned. Does it have its own states? Does it handle data? Could it have ranges or boundaries? What test cases apply and how should they be equivalence classed? A web page is just like any other software.



    Software Testing
    Lessons Learned in Software Testing
    ISBN: 0471081124
    EAN: 2147483647
    Year: 2005
    Pages: 233

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net