A beautiful line came into my mind while I was writing this article “Happiness lies in the joy of achievement and the thrill of creative/quality effort.” We all expect the best from the world, so why shouldn’t we deliver our best? These checklists for Drupal site testing will attempt to help you deliver the best quality work with regards to Drupal site development, while following QA standards.
While doing development work, we reach a high level of intensity in continuous collaboration between stakeholders – including business analysts, developers, testers, and clients throughout the production process. Testing becomes an essential component of each and every phase of the developmental process, with quality being “baked in,” through constant feedback, to the project at every stage of its development.
We have been working on progressively larger and more complex web applications and CMS implementations. As a result, I have increasingly been involved in developing a reliable and repeatable testing methodology to support this growth. Additionally, large-scale systems have higher visibility and receive a larger amount of traffic. This obviously exacerbates any slip-ups made during the QA process by an order of magnitude. For these reasons, I tend to employ a multi-faceted approach comprised of several principles and artefacts when defining a QA strategy for a particular implementation.
In order to follow QA standards we need to follow below mentioned steps:
Checklist For Drupal Site Testing
When building a Drupal website, QA needs to ensure that he/she has done thorough testing on the site before submitting it to the client. While doing beta testing, if the client finds any critical issue, it deters their confidence and could be costlier. What if that specific issue is a show-stopper/Blocker that can restrict a user from visiting the site?
At our organization, we have 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.
Drupal site testing before launch
- 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 that 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.
- 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 permission, 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.
- 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.
Drupal site testing 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)
Drupal Site Testing Techniques
We have found in many situations that writing a series of test cases over the course of feature development is a great way to ensure that no stone is left unturned from a testing perspective.
There are many different schools of thought regarding the proper format/structure/level of detail for a test case. Generally speaking, I have had the most success:
- keeping them short and concise
- starting with the most critical and highly visible site features and functions, and
- Iterating from there onward as timeline and budget allow
This process continues to help us get on the same page with customers about how their system is/will function, and provides an opportunity to revisit/adjust requirements as needed in some cases. It encourages the broader group of stakeholders to get involved in the testing process and provide valuable/unique perspectives that might not otherwise be heard. Test cases can be an invaluable tool for onboarding and workload distribution amongst project team members.
I’ll also identify the most important test cases and run through them each time code changes are deployed to an existing site.
It’s important to set expectations early in the project, regarding which browsers/versions need to be supported. Whenever possible, I review a client’s analytics to have a better understanding of what their visitors are using.
You should start cross-browser testing fairly early on in the theming process (in case any major issues), and ramp up significantly towards the end of the project as changes to the design are less frequent/substantial. Your site might not look exactly the same in all browsers, but it should look professional.
There is some degree of ongoing “fuzzy testing” that has to take place during the development lifecycle. Generally speaking, common sense prevails. There are some basic litmus tests that should administer perpetually during the development lifecycle:
- Does this feature make sense to end users?
- Can someone understand how to use it without instructions?
- Can users get where they need to be in a minimum number of clicks?
- Is it fairly easy for an administrator to utilize this feature?
None of these questions are particularly revolutionary or complex – you just need to ensure that you are constantly asking them.
Develop a shared understanding of accessibility requirements with your stakeholders, particularly if 508 compliance is a requirement.
Some common considerations include:
- Does all of your content have a text equivalent (i.e. alt text for images, transcripts for audio/video, etc)?
- Can your navigation menus be traversed by someone using a screen reader?
Things that are assumed to Work
When you’re writing requirements for a Drupal project, a lot of things get glossed over or left over because it’s assumed that Drupal core will handle them, or that they will ‘just work’. It’s important to remember these during the testing process:
- Core Drupal Features
- Integration with APIs
- Import Scripts
- Admin UI
- Admin Workflows
- MAIL SERVERS