Client: Wizards LLC
Industry: Gaming
Location: Atlanta
URL: http://magic.wizards.com/, http://wpn.wizards.com/, http://community.wizards.com/

What is the Story behind this Project?

This engagement was to provide Extended Maintenance Services for Acquia’s client, Wizards of the Coast LLC. The individual sites that came under the engagement were MTG, WPN and Wiz-community. Technical development included site and feature enhancements such as mobile enhancements and site performance improvements, along with code level defect resolution and migration of the website content.

Overview

WIZ – MTG
Wiz WPN
Wiz Community

Axelerant provided Maintenance Support, which included implementation of ongoing maintenance and enhancements to Wizard’s Websites, at Wizard’s or Acquia’s direction, that are stable, production ready, including resolution of bugs and issues documented and prioritized in the backlog, as guided by Wizards or Acquia.

Goal & Solution

Axelerant provided maintenance development support for backlog issues, which were organized as sprints per month with scheduled releases. A total of 16 sprints were released.

The following was the tweaked QA SCRUM methodology employed with respect to Wizards:

  1. At the start of each sprint, in the team huddle meeting, QA needs to ask regarding the list of tickets from JIRA that will be targeted first by Dev for fixing.
  2. QA needs to go through the tickets and reproduce the issue in production with the steps stated by client.
    1. If the steps don’t involve functionality to be tested or are in generic technical terms (for eg: fix a module), then request the relevant developers to get in a quick discussion and understand the functionality to be tested.
    2. If still there are ambiguities (open queries) present then collate them & get them clarified from client / BA at the earliest.
  3. After getting a complete understanding of the ticket to be tested, request the developer to get into a quick call to formalize and agree on the test strategy to effectively test the ticket.
    1. In the call, cover the positive scenarios that can be tested in depth.
    2. Cover the test data that would be need to test the scenarios
    3. Discuss the prerequisites that would be needed to test the scenarios, for e.g. User credentials.
    4. Discuss the negative and regression testing scenarios to be tested.
  4. Dev mentions that the ticket is ready to test (providing the environment details, Dev or Test projspace) in wizard’s slack channel.
  5. As QA, first execute the positive and critical scenarios related to the ticket’s objective.
    1. If issue/s has been encountered, then mention the steps to reproduce along with screenshots in wizard’s slack channel. If Dev is unable to understand the issue, then get into a quick call at the earliest.
    2. After an issue is fixed and ready to be tested, QA needs to perform retest at the earliest and provide the update to Manager and Dev through wizard’s slack channel.
    3. As soon as all the positive scenarios are tested successfully with multiple users (if applicable) and on multiple browsers (desktop & mobile), inform the Manager and Dev through wizard’s slack channel. List out all the notes in the summary as well, for e.g., any scenario which couldn’t be tested and its reason.
  6. Continue testing with the remaining scenarios, i.e., negative and regressions ones.
    1. If issue/s has been encountered, then mention the steps to reproduce along with screenshots in wizard’s slack channel. If Dev is unable to understand the issue, then get into a quick call at the earliest.
    2. After an issue is fixed and ready to be tested, QA need to perform retest at the earliest and provide the update to Manager and Dev through wizard’s slack channel.
    3. As soon as all the negative and regression scenarios are tested successfully with multiple users (if applicable) and on multiple browsers (desktop & mobile), inform the Manager and Dev through wizard’s slack channel. List out all the notes in the summary as well, for e.g., any scenario which couldn’t be tested and its reason.
  7. After all the scenarios are tested successfully for the ticket, provide a quick summary of the different users and browsers used to test (include the environment URL).
  8. PR request is raised by Dev and updated in JIRA. The client pushes the code changes in QA Env and updates the same in JIRA.
  9. As soon as a ticket is available to test in QA Env, confirm with Dev regarding the environment URL. If administrator, moderator and authenticated user credentials aren’t working in QA Env, then request the Dev to provide ULIs for the respective user.
  10. For testing a ticket in QA Env, perform the steps 5 to 7.
  11. In JIRA, Dev mentions that the ticket has been successfully tested in QA Env and then moves the ticket in UAT queue for deployment in Staging.

Business Requirement Delivered

Highlights

  • 16 sprints were delivered with an average of 22 story points per sprint.
  • Implemented enhancements to Desktop, Mobile and Tablet endpoints for 3 sites

Technology and Solution Stack

  • Drupal 7.27
  • PHP 5.3.3
  • My SQL
  • Apache

Mantesh contributed a patch to Troll module as part of the wiz-community support – https://www.drupal.org/node/136225#comment-9339995

Drupal-specific Modules & Info

  • Workbench module
  • Forums
  • Organic groups
  • Views Slideshow

Provide extended maintenance services after contracted site build and delivery.

SPARK

A CONVERSATION