Testing checklist for a Drupal website

July 9, 2013
Testing checklist for a Drupal website launch

When building a Drupal website, you need to ensure you have thoroughly tested the site before you turn it over to your client. If a client discovers a significant issue, it degrades their trust and can cost sales if the problem is enough to block a website visitor's ability to interact with the site.

At Digett, we thoroughly test every site we build. Over the years, we have built a checklist of items to test on a site before going live. 

I have filtered this list for items we test specifically for Drupal. We have another list of items that are tested even for a one-page static HTML site. 

Planned

These first items are just to ensure we've planned for a few items that have caught me off guard before on a Drupal site.

  • Test what happens when you add a level of navigation lower than planned — what if the client wants a page under a page you planned as the deepest you could go? Not that you have to allow for it in the drop down header navigation, but at least there is a plan. 
  • Ensure css takes into account html tags outside initial site content. No tables when launching the site, it doesn't reflect well if a client has to report a problem later when they try to add a simple table of data and the style is completely off because we forgot to plan for it. 
  • 301 redirects are in place to redirect old site paths to new Drupal site paths. We do these in the Redirect module.
  • WYSIWYG on main content pages provides a way for clients to align images left or right and css provides appropriate padding for each.
  • WYSIWYG image and file uploads work as expected and the client has appropriate permissions to upload.

Before launch 

  • Privacy policy link is in place if there are comments on the site (required since we use Mollom).
  • 404 (not found) and 403 (forbidden) display appropriate information and are customized appropriately.
  • Drupal Content Type settings: we turn off preview, we ensure revisions are turned on for all content types and we ensure the correct menu is available. 
  • Ensure Pathauto patterns are set appropriately for each content type. 
  • Xmlsitemap is configured and updating properly when content changes.
  • Meta descriptions/titles are in place and available for home page and views as well as normal content pages. For Drupal, it is important to always check pages created by Views. This is often missed on Drupal sites I've seen.
  • Robots.txt file correctly blocks nodes that should not be indexed (rotators, sidebar block promos, etc). We prefer to do this in the RobotsTxt module.
  • Client has enough permissions but not too much (based on your ongoing support with client). 
  • User passwords are set to strong passwords before launch.
  • If not a community site, ensure only admins can create accounts.
  • Ensure test content has been removed.
  • Ensure Google Analytics is in place and working (use real time function to ensure anonymous users are tracking); block your IP and client (if desired).
  • Disable development and unused modules.
  • Enable appropriate css and js aggregation (do this before testing site). Javascript aggregation can be especially problematic in some cases so ensure you test any pages with custom functionality.
  • Turn on Drupal cache (if not using Varnish).
  • Check error log and resolve issues.
  • We like to set error reporting to NOT show on screen for production sites — just write to log.
  • Ensure site search works as expected and that it is themed properly.

Right after launch

  • Clear all Drupal caches.
  • Run broken link checker to ensure production site has no broken links. We use the Link Checker module to assist with this process.
  • Ensure any staging or dev url paths are set to production (we use Pathologic to help catch these)

What else do you test for Drupal?

There are lots more items on our production testing checklist. The items above are just the main things we check for Drupal sites; SEO, browser testing and lots more are involved in launching any website.

Are there other pieces you test in Drupal when launching a site? Do you have questions about anything I listed? Let me know in the comments below. 

Check List designed by Stephane Thomas from The Noun Project

Comments

Thanks for your share !

Thanks for your share ! printed it already ... will be very useful :)

Glad it came in handy!

Glad it came in handy!

Great list! Thanks for

Great list! Thanks for blogging it.

>>> Javascript aggregation can be
>>> especially problematic in some
>>> cases so ensure you test any
>>> pages with custom functionality

Would you be willing to elaborate on this? What are some examples of problems you've seen?

C

Good List! One that tripped

Good List! One that tripped me up recently and is now on our list... Check that all Webforms and/or Rules-based notifications are in-place and set to go to the client's email address. We set them to our email address during development.

Ooh, good one. That's

Ooh, good one. That's actually already on our list, but JD didn't include it here. We don't use Rules frequently, but when we do it's very easy to forget to adjust email addresses.

@Artis: That one has caught

@Artis: That one has caught me too!

@Craig Hyatt: I've not taken the time to really dig deep on the issue, but I have several sites where if I turn on js aggregation, various jquery functions break. It isn't every site ... but I do have several that are this way. For this reason, I just check every new site to ensure this won't be a problem.

A big one that is often

A big one that is often missed is to ensure that all theme images are correctly compressed And that all pngs are compressed with a service like www.tinypng.org because default Drupal only handles jpegs.

Put credit card processor in

Put credit card processor in production mode.

Good one. That's one of those

Good one. That's one of those sneaky ones, especially when you don't do commerce sites often.

@Craig Hyatt - as one recent

@Craig Hyatt - as one recent example, on a site running the Adv Agg module (advanced aggregation and minimization) and the JQ Multi (allows you to run different versions of JQuery b/c this is a D6 site that the client wanted themed using Bootstrap), the Adv Agg module stops JQMulti from doing it's magic (the libraries don't get included at all), so anything depending on it dies. It works fine with no aggregation or the in-built aggregation.

We also found that Adv Agg killed the Rubik admin theme functionality. So though you get some nice features with Adv Agg over standard aggregation, it wasn't enough to warrant the hassles.

Clearing caches often sets

Clearing caches often sets off new changes, so after "Right after Launch: clear cache" I would recommend that people do a final QA walkthrough to catch new/different/broken functionality.

I also like to clear the drupal logs after clearing the cache and before QA so that I have a clear(er) record of anything that went wrong.