Testing Rubric for Drupal Updates

This rubric is intended for Drupal Enterprise sites. Testing should be conducted in the stage environment. You can find the URL for your stage environment by looking in the list of aliases on your site node in Drupal Management - the stage URL will end in .stg.umn.edu. You must have a production environment in order to activate your stage environment. If your site does not yet have a production environment, then the stage environment will not be active regardless of the presence of a stage URL in Drupal Management.

Testing Rubric for Drupal Sites
Level Scenario Recommendations
1 This is just a security update and/or some rather small and benign module updates. No expected user changes. Spot check a few of your main pages.
2 There are some known changes that will result from this update. They can be visual and/or functional. The changes are likely coming from one or two modules, and those modules will be listed in the release announcement email sent to the Drupal Google Group so that testers know where to  focus (e.g., Folwell update).
  • Spot check your main pages.
  • Look through the list of modules being changed to see if they are installed on your site (Go to the Extend menu in the admin toolbar and then type in the module name).
    • If you do not have any of those modules installed, then you are done.
  • Check pages that are specifically using those modules for visual issues.
  • Create a test page (or pages) that use that module to ensure no problems occur.
3 There are many module changes in this update that could impact your site. It is better to check your site over generally to ensure that it is working.
  • Optional - If you are a developer who is comfortable reading logs, you may wish to enable dblog while testing. Please be sure to uninstall it once your testing is complete.
  • Spot check your main pages.
  • Look through the list of modules being changed to see if they are installed on your site. (Go to the Extend menu in the admin toolbar, and then type in the module name.)
  • Visually check at least one page for every content type (comparing it to the production page). You might want to check your main landing pages as well.
  • Look for examples of different paragraphs. You should concentrate on the ones associated with module updates.
  • Attempt to create, modify, and delete a page for each content type, filling in as many of the fields as possible. If they allow paragraphs to be added, add/edit as many of them as you can that are commonly used on your site.
  • Check site critical views to make sure they are working properly.
  • Visually check if Folwell components are impacted on your site (comparing it to the production site).
4 This is a substantial change that might affect backwards compatibility with code. In-depth, time-consuming testing is warranted. You may need to plan multiple testing sessions. Good examples of this include moving to Drupal 10, or changing php versions.
  • Optional - If you are a developer who is comfortable reading logs, you may wish to enable dblog while testing. Please be sure to uninstall it once your testing is complete.
  • Visually compare as many pages on your site as you can with your production site.
  • Attempt to create, modify, and delete new test pages for all of your content types and as many paragraphs as you can. (This means custom paragraphs as well as Folwell paragraphs.)
  • Check site critical views to make sure they are working properly.
  • If the changes have an impact on a particular Folwell component, test that component with possible combinations. 
  • If your site has any of the following functionalities, you should test these features as well:
    • Workflows (draft, needs review, published, archived).
      • If your site has multiple user roles, test from each role.
    • Migrations/Feeds (your site is pulling data from external sources).
    • Webforms.
    • Sending emails.