Web Development QA (Testing) for Custom Websites

How Our Team Manages the Process of QA Prior to Launch

Quality Assurance

We approach quality assurance (QA) from many angles. A website with a content management system (CMS) behind it requires a comprehensive test plan.

Theme QA is a review between design/user experience, business owners, and Bear Group to make sure that what was designed was implemented. Photoshop is not HTML, so iterative adjustments may be needed once the site is built. We spend a lot of time in this phase, especially for mobile sites doing cross-browser testing, and we typically use Browserstack to try many different combinations of browser, operating system, and device. This is the area in which we see the most bugs or improvements during testing, but they are also the quickest to resolve.

Site-building quality assurance (QA) is a highly iterative process of taking the design and site map and teasing out the administration/CMS components needed for content types, fields, navigation, views, taxonomy, and more. Adjustments are quick to make and happen throughout the build process with input from editors, front-end developers, and the technical project manager (TPM). For modules that have complex configuration -- for example, the Workbench workflow module that creates many scenarios for the publishing process -- we often will use more formal QA methods.

E-commerce sites pose tangible QA challenges, and we complete end-to-end testing for each site. This means that we place live credit cards through live gateways and verify that funds are visible in the client’s bank account before sites go live.

In a content management system (CMS), you can easily change all text and images, so content issues are never really bugs—they are revisions. They can often be addressed immediately by copy editors or others using the system. The CMS workflow process has two steps for checks prior to content publication, so the person with Publishing keys ultimately has the responsibility for content QA.

As new modules are written, there is always a detailed QA process to verify that the functionality is correct. This QA process is especially important for any integrations that introduce system interdependency. Professional testers lead this QA process, which typically has written supporting documentation and test specs.

The deployment process—moving code from staging environments to live production— is one of the highest-risk tasks for any website. Our development environments encourage best practices and safe places for developers to work out the details.

  • Our code is all stored in version control systems, generally Git, for easy rollback. We track code with tickets.

  • Developers work in local environments and commit code to our repository, where it is pushed to a staging server for testing and client review.

  • We use automated build systems and dev/stage/production tiers with exact replica environments.

  • We use a hands-free, repeatable process for deployment to ensure reliability, with several check-and-balance points.

However, a code update on production can still trigger database updates, permission issues, misconfiguration, or caching issues -- there are many ways for things to break in a highly visible way. We use deployment verification tests—usually manual—to spot-check the important parts of the website just after deployment to ensure that all key areas of the site are functioning perfectly.