Enhancing scalability and editorial experience
The customer, a leading university in the US, was looking for a long-term, scalable solution for its websites. We also had to keep in mind the editorial experience and the maintenance needs of the sites, considering that the end-users were new to Drupal.
About the customer
Established in the mid 19th century, the customer is a public research university and a flagship educational institution in the United States. It is among the 131 institutions in the "R1: Doctoral Universities – Very high research activity" category of the Carnegie Classification of Institutions of Higher Education.
The university’s digital team was having a hard time managing multiple websites built using pure PHP, because the solution wasn’t easily scalable. Their team was having to replicate the code in multiple repositories, test these independently, and then deploy them one by one.
With this process, each consecutive change or feature request led to larger release cycles and declining performance. Not only was the development code redundant, each site also had its own redundant test automation code, making it difficult to maintain both.
Personalization capabilities were among the major features that they were planning to add to the site. The effort involved in implementing personalization would have increased exponentially without the use of the appropriate framework and tools.
Even small changes related to the editorial workflow moderation were difficult to accommodate within a reasonable time span. Independent additions to the websites had begun resulting in inconsistent user experiences.
They were looking for a framework that could resolve these problems.
The Axelerant QA team has gained years of experience on a number of projects, including those where Drupal was used as the backend, decoupled Drupal, and testing the Drupal API. Considering the out-of-the-box editorial workflow moderation that comes with Drupal and the flexibility it offers in developing custom features, Drupal was a good choice to meet the customer’s requirements in this instance.
Phase 2 (onwards)
Create the first site using the designed solution primarily with Layout Builder. Validate the Drupal application and verify the migrated content.
Create subsequent sites in Drupal using Acquia Cloud Site Factory (ACSF) and Cohesion, and migrate content. Validate the subsequent sites and verify migrated content in Cohesion components.
Phase 1 consisted of creating the first site using the solution identified, and using Layout Builder for site-building. Acquia Cloud Site Factory (ACSF) was used to create scalable and maintainable websites. The QA team took a logical approach to testing features on multiple websites. They studied the various templates and profiles implemented using ACSF and came up with test scenarios, including the regression test suite.
In the subsequent phases, the client decided to go ahead with Cohesion DX for a better site-building experience. Testing was carried out using a combination of testing types, like exploratory and automated testing using Behat. The automation framework was designed keeping in mind the need to run the same scripts on different websites.
New roles and the related workflow could be added out-of-the-box, with just basic smoke tests being executed. Both Layout Builder and Cohesion DX provided authors and editors with a world-class user experience, allowing them to build pages with ease.
By leveraging their experience with testing, the QA team was able to deliver what the customer needed at a quick pace. The automation framework helped them test multiple websites without having to duplicate scenarios for each site, allowing them to rapidly roll out multiple new sites.
Rapid onboarding to new tools
At Axelerant, we encourage continuous learning. One of the ways we do this is by organizing regular internal webinars and show and tell sessions.
As a result of this, the QA team wasn’t entirely inexperienced with using either Layout Builder or Cohesion, even though this was one of the team’s first projects involving both these tools. By adopting the stay project-ready attitude religiously, the team was able to ensure that the project did not suffer any downtime in either phase, even when new tools were introduced.
After migrating thousands of nodes, the QA team began testing using its migration testing strategy and checklist. These have been developed over six years of experience in various types of migration projects, where the destination platform was Drupal.
The team was posed with challenges in both Phase 1 and 2, as they had to test the migrated content for Layout Builder and then Cohesion. However, the testing strategy to verify migrations was generally applicable to these tools as well. Any specific learnings and observations pertaining to both the tools were captured additionally.
Verifying the features related to personalization using Acquia Lift was a new aspect for the QA team. The team primarily focused on identifying all test scenarios related to personalization beforehand, and sought training on using Acquia Lift.
The key question when testing multi-site projects is how to perform feature and regression testing on multiple sites that share the same codebase but have different databases and themes. The organic approach of creating a test strategy by using our years of experience in testing multisites made this a straightforward task, ensuring faster releases of multiple websites in parallel.
These are some of our learnings and insights gained through this engagement: