This is maybe a strange blog post because it is written as an instruction to a junior developer who I have been coaching on how to be better at QA of web sites and a template for a site test protocol.
I’m sharing it with you to get feedback myself on my mentoring.
Project: <project or site name>
Release: < build date and version number >
Test leader: <name>
Date: <date when test was performed>
Page Validation Tests
TEST: Simple WAI test
Performed with Firefox with Web Developer Toolbar plug-in. Turn on option Persist Features, and disable JavaScript, disable CSS and disable images.
Success criteria’s
- Verify that you can understand the page and the structure of the information. All sections should have h1-h6-tags.
- Use CSS for class for Aural Text to hide headings only needed by screen readers.
- Make sure label tags are used and that they point to correct control.
- Test functionality! Buttons does post-back but Link Buttons rely on JavaScript and will fail to work.
- Make sure all images has alt-tags. Decorative images should not be in markup only in CSS.
Meridium’s site is a good example:
TEST: Markup and CSS Validation
Test quality of markup and CSS with the validation tool in Web Developer Toolbar.
Success criteria
- There should be NO validation errors at all.
TEST: Traffic check
This test can be done in parallel with a full run of another test. Just start capturing and analyze the result afterwards.
Disable browser cache during this test with Web Developer Toolbar in firefox.
Capture all traffic between your browser and the web server using Fiddler HTTP Debugging proxy.
Success criteria’s
- No error server responses (400-599)
- All resources has relevant caching
TEST: Browser Layout Validation
Compare each page with reference layout.
Success criteria’s
- Page should look good on its own with balance.
- Structure should not collapse or information be hidden.
- Missing functionality should degrade gracefully (i.e. rounded corners being square on IE)
- No major differences in margins or padding.
- Elements should align.
Instructions for test documentation
A developer should of course do a self test in a few browsers before check-in but a complete test of a site is still needed with all A-Grade browsers.
Each row in the test protocol is a representative test page on the site or test of functionality block. There is usually one row for each Page Type and/or each Product Backlog item.
Each column represents a type of test that should be performed on each test page or functionality block. Each cell holds the result from a single test.
Legend to use for test result
- [Blank] Test not performed yet.
- X Not applicable, this test case is not relevant.
- OK Test is performed without remarks.
- 123 Test is performed with remarks. Number is a reference to the remark. Use screenshot if needed to clarify
Test Result Matrix
|
Test Cases |
Other |
Browser Layout Validation |
||||||||
|
Simple WAI Test |
Markup and CSS Validation |
Traffic check |
IE7 |
IE8 |
IE9 |
FX 3.6 |
FX 4 |
Safari (Mac) |
Chrome |
|
|
Start Page |
||||||||||
|
Normal Page |
||||||||||
| … | ||||||||||
Test Remarks
1. <test remark>
2.
3.
Page Performance Test
This test is performed on the start page of the site and on commonly used AJAX functions.
Use YSlow plug-in to analyze the start page.
Success criteria’s
All C-F grades should be reviewed but only some issues in the list are related to development and other to configuration of hosting environment.
IMPORTANT! Always use jQuery and Microsoft AJAX scripts from Google or Microsoft CDN!
The following tests should always be reviewed by developers:
YSlow Test Result
|
Grade |
Test |
|
Make fewer HTTP requests Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Some ways to reduce the number of components include: combine files, combine multiple scripts into one script, combine multiple CSS files into one style sheet, and use CSS Sprites and image maps. |
|
|
Put CSS at top Moving style sheets to the document HEAD element helps pages appear to load quicker since this allows pages to render progressively. |
|
|
Put JavaScript at bottom JavaScript scripts block parallel downloads; that is, when a script is downloading, the browser will not start any other downloads. To help the page load faster, move scripts to the bottom of the page if they are deferrable. |
|
|
Make AJAX cacheable One of AJAX’s benefits is it provides instantaneous feedback to the user because it requests information asynchronously from the backend web server. However, using AJAX does not guarantee the user will not wait for the asynchronous JavaScript and XML responses to return. Optimizing AJAX responses is important to improve performance, and making the responses cacheable is the best way to optimize them. |
|
|
Use GET for AJAX requests When using the XMLHttpRequest object, the browser implements POST in two steps: (1) send the headers, and (2) send the data. It is better to use GET instead of POST since GET sends the headers and the data together (unless there are many cookies). IE’s maximum URL length is 2 KB, so if you are sending more than this amount of data you may not be able to use GET. |
|
|
Do not scale images in HTML Web page designers sometimes set image dimensions by using the width and height attributes of the HTML image element. Avoid doing this since it can result in images being larger than needed. For example, if your page requires image myimg.jpg which has dimensions 240×720 but displays it with dimensions 120×360 using the width and height attributes, then the browser will download an image that is larger than necessary. |
|
|
Make favicon small and cacheable A favicon is an icon associated with a web page; this icon resides in the favicon.ico file in the server’s root. Since the browser requests this file, it needs to be present; if it is missing, the browser returns a 404 error (see "Avoid HTTP 404 (Not Found) error" above). Since favicon.ico resides in the server’s root, each time the browser requests this file, the cookies for the server’s root are sent. Making the favicon small and reducing the cookie size for the server’s root cookies improves performance for retrieving the favicon. Making favicon.ico cacheable avoids frequent requests for it. |
Other Tests Results
|
Check? |
Test |
|
Use jQuery and other common resources from Google or Microsoft CDN |
|
|
CSS Sprites is used to minimize number of images |
Functional Regression Testing
Before a major release a full regression test should be performed on all existing functionality to reduce the risk that a function is broken after it was originally tested.
Since testing must be systematical and it is hard to remember what should be tested each sprint needs to add its test scenarios to the check list.
As a guideline each product backlog item should have at least one documented regression test.
TEST: Registration Flow
Test related to authentication and registration.
|
Check? |
Test |
|
Register as a new user (test links in mail!) |
|
|
Login |
|
|
Logout (and test access to protected resource) |
|
|
Change forgotten password (test links in mail!) |
|
|
Change mail address for account |
TEST: Feature A
Test related to …
|
Check? |
Test |
TEST: Feature B
Test related to …
|
Check? |
Test |