Links Testing

One of the unpardonable sins of a newly released or poorly managed website is a broken or failed hypertext link. Users who have stayed on a website to learn, shop, or play can change their perception of the site when a link they wished to use results in a 404 error. A website test plan should verify every link on the site, including the following:

• Outbound/Off-site links—An outbound link or an external link logically connects a webpage to another webpage, typically on another website. Bear in mind that the outbound link on the source website is also an inbound link to the target website.

• Internal links—An internal link connects one part of a webpage to another part of the same webpage or links one webpage of a website to another webpage of the same website. Internal links can cause errors in initial testing due to missing or misplaced anchors.

• Missing or omitted links—On most websites, all of their webpages are meant to be visited for one purpose or another. If there is no link associated with a webpage or if a webpage does not have a way to return to the landing page or the page that is linked to it, this error needs to be corrected and retested.

• Email links—Users may use different email clients, not all of which may be compatible with the browser brand you had in mind during the development. Testing should attempt to verify that the “mail-to:” links do, in fact, open an email client. The testing should be performed on a variety of browsers and email clients.

• Broken links—In case you had not heard, the internet and web are in constant flux with URLs coming and going, documents moving from one website to another, and data or references disappearing altogether. The use of a broken link checker is perhaps the easiest way to verify that the hypertext links of a website are all still valid. There are a variety of broken link checkers available on the web, some free and some not, including: ahrefs.com’s Broken-Link-Checker (ahrefs.com/broken-link-checker), Dr. Link Check (www.drlinkcheck.com/), and Screaming Frog’s SEO Spider tool (www.screamingfrog.co.uk/seo-spider/).

Forms Testing

There are a variety of reasons for including a form on a webpage: registrations, ordering products or services, and others. In general, a webpage form provides visitors the ability to communicate, perhaps interactively, with the website’s owners or operators. The information entered into a form should be validated. Doing so helps the visitor provide correct data and ensures that the data stored by the website are correct for future use.

Webpage forms have three primary types of data fields to be verified:

• Missing data—Forms, in general, will have some data that must be entered, such as names, telephone numbers, birth dates, and addresses, for example. A webpage may also have sets of radio buttons, check boxes, and yes/no questions, which require a selection.

• Input data validity—Some data fields have specific lengths, character types, and perhaps a limited set or range of acceptable values, such as telephone numbers, postal codes, quantities, money, and Social Security numbers.

• Standard sets of values—Some data fields must have a specific value, such as state names, and perhaps month names and a range of years. Using a pull-down list, like the one shown in Figure 12-7, is the most common way to at least narrow the choices to valid values. However, there is no guarantee that the correct value is chosen. Verifying these values can be complicated, but it is worth it in the long run.

• Abandoned shopping cart—A feature that e-commerce sites overlook on occasion is what to do with items that have been added to a shopping cart. Do you save them to the database? Do you display a dialog box asking if they wish to keep them or discard them? Whatever was decided in the design of the select-to-cart function, make sure it is working.

Cookies Testing

If cookies are used by a website, there is a functional reason. Therefore, testing for the creation, presence, or content of a website’s cookies verifies that these functions are correct and working as they should.

Each time a visitor downloads a website, the website either creates a cookie, if none already exists, or reads a cookie to create a UX. Website cookies are stored on the client side. There are two types of cookies stored on the local client: session and persistent.

A session cookie tracks the interactions of a visitor with a website, but only for a single specific use. A session cookie is created by a browser when the download website is displayed and ends when the user closes the browser. Session cookies are temporary records, while persistent cookies, if enabled, remain on the client system from session to session and for months to years.

A persistent cookie holds, at minimum, three pieces of data: the identity of the server that initiated the cookie, the lifetime of the cookie, and a randomly generated value that serves as an identifier. Persistent cookies are stored on the client computer, but different browsers store them in a variety of locations. Browsers typically have an option that allows users to see what cookies are on their systems and the amount of space in use. As shown in Figure 12-8, some websites store multiple cookies, each with information on specific types or actions in separate accesses.

You can also view the cookies in use by a particular website, as shown in Figure 12-9. Since cookies of either type are tied to a particular browser, if you wish to view all cookies for that browser, you would need to search for a browser extension to do so.

To fully test the cookie-related functions of a website, you can use any or all of five separate testing steps:

1. Disable cookies—After disabling and removing all cookies, open the website and exercise the site’s cookie-related functions. This test exposes the website’s functions when a cookie is missing.

2. Corrupt cookies—Open and edit a cookie in a text editor and randomly change its values. Save the cookie and attempt to use the cookie-related functions of the website. This will demonstrate how the site will perform if it encounters a corrupted cookie.

3. Cookies on multiple browsers—The cookies of one browser are not necessarily compatible with another browser because each creates its own cookies. Test the website on multiple browsers to check that the site will operate in general on each one as well as that there are no problems with cookies.

4. Session cookies—After closing the browser, verify that all session cookies have been removed. If not, research the browser’s documentation to determine the cause.

5. Cookie encryption—Persistent cookies are created and sent to a client from a website’s service-side functions. If user credentials, including usernames and passwords, credit card numbers, and the like, are included in the cookie, this information should be encrypted, and testing should be performed to verify that this is happening.

Note: Most browsers support one or more cookie testing plug-ins that perform the previous tests and, in some cases, a few more.

HTML/CSS Validation Testing

Small errors in the coding of a webpage can cause large problems. A missing close parentheses could cause an important action to be omitted. A typing error in the CSS coding may emphasize the wrong heading or action. These types of errors are common, and often visually scanning the coding statements may not catch them. This is why there are numerous tools available from browser publishers and others to check the HTML and CSS code on a webpage.

Figure 12-10 shows a results page for Silktide’s Nibbler website tester (nibbler.silktide.com/). Website testers, like this one, check a variety of content and functions for problems, including server behavior, internal and outbound links, meta tags, and more.

Search engine optimization (SEO) is another test on website content that checks for a website’s availability on and compatibility with major search engines. Figure 12-11 shows an example of the results of a website analysis by the SmallSEOTools’ SEO Dashboard (smallseotools.com/website-seo-score-checker/).

After testing for coding errors or issues and any SEO suggested improvements, search for the website on several search engines to ensure the site is appearing in the search results correctly. The position of the website in the search results is another matter altogether and, in most cases, is a function of popularity and payment.

Security Testing

A key component of any software development methodology is security. A website can have a variety of vulnerabilities, such as cross-site scripting and code injections, which must be mitigated before the site is released for access. Regardless of whether the website is on an intranet, extranet, or internet, vulnerabilities seem to always end up exploited.

Testing of an appropriate type should be included in every phase of a web application development as well as in pre-release testing. Any security flaws or vulnerabilities should be corrected or mitigated, and then the testing should be performed again, from its beginning.

After it is released, if some security flaws managed to slip past testing, corrective action should be immediate. No matter how minor the threat may be, think of all vulnerabilities and their related threats as icebergs. You only see the tip of the problem.

A website’s security functions are generally limited to protecting the integrity of personally identifiable information and other sensitive user data that are stored by the site, hopefully encrypted. Testing this security is a matter of exercising the entire data flow of the website by entering all data a user is requested to enter, including data to be secured and then verifying its content and security. The objective is the assurance that the data were, in fact, encrypted, if appropriate, and stored. Other types of security testing that can also be used to identify and eliminate vulnerabilities are penetration tests (pen tests), vulnerability tests, CAPTCHA tests (if included on the site), and tests verifying that invalid login credentials cannot access secured information.