Quality assurance is an important part of website redesign projects for several reasons. An experienced QA team can examine the work from different perspectives to ensure that it meets a client’s expectations and the needs of the people that will be using the solution.
Investing in QA and dedicating a proportionate amount of resources to the process often ends up saving clients both time and money in the long run; bugs are discovered and fixed earlier, and the overall quality of the implementation is enhanced. In order to maximize project quality and customer satisfaction, it is imperative for the QA team to be involved throughout the entire development phase of a website redesign project.
Incorporate QA Throughout Your Project
QA at Velir begins with a review of requirements written by one of our business systems analysts (BSA). This happens during the design phase and prior to implementation to make sure that the requirements are specific and unambiguous. Subsequently, when we begin testing, we can focus on testing functionality and not interpretation. Requirements will naturally be added or updated as development continues, but by then, the workflow has already been established, making the process smoother.
Align QA with Your Development Process
Throughout the build phase, our QA resources are allocated alongside our developers. We begin by writing test cases using the same requirements that developers use to build. As part of the test case writing process, we help expose any gaps or assumptions that may be present in the requirements.
Our experience helps us spot patterns based on what ambiguities or assumptions have caused defects in the past. We can tease these out before developers even start writing code.
By finding potential bugs in the requirements, we prevent them from making it into code, reducing the time it would otherwise take to fix these defects later on.
This also helps reduce the time developers spend interpreting a ticket, allowing them to focus on development.
The Specifics of QA at Velir
We use Jira to track the status of development tickets. As tickets are reviewed and requirements are ironed out, we begin to translate them into step-by-step tests – walk-throughs of a feature to validate that it meets the expectations of the ticket. We use Test Rail to host our test cases.
Each client has its own Test Rail Project and within that project, we add a Test Suite for each unique domain. We use a specific architecture and folder structure for each Test Suite - global elements, page templates, workflows, etc. - to keep the test plans organized as more tests are added. Each individual test case is tagged with its corresponding Jira ticket, the specific project name, and a priority. This allows us to map the test cases directly back to the requirements.
Utilizing the priority field, we can filter the body of test cases we want to run for a given scenario. For example, a high-level smoke test involves running a smaller number of test cases while a full regression test requires a more exhaustive set of cases. The goal is for a QA Engineer unfamiliar with the project to be able to look at a test run, understand the test coverage, and run the test in a logical way.
As development features are completed, QA then executes those tests. But QA’s involvement in a project doesn’t end with testing functional requirements. As part of QA, we test both content authoring capabilities and the end-user experience; our goal is to ensure that our client’s content authors can do their job effectively and that the created solution will be intuitive to use for end audiences.
Content Authoring & User Experience
We recognize that for any digital solution to be effective it needs to be adopted internally. A key part of this involves ensuring that the designed content authoring features are sustainable to use in the long run. We verify the creation of page templates and components, configuration, and publishing, as well as user permissions, authoring workflows, and personalization as applicable.
While the specifics of back-end testing on different CMSs are distinct, the process is the same. Our projects are built on one of three major Content Management Systems (CMSs) - Sitecore, Adobe AEM, or Drupal. Each member of our QA team has deep experience testing all three CMSs.
In addition to testing the requirements in tickets, QA must read between the lines and advocate for what the client and its different audiences need. While something may technically be functioning as expected, if the user experience (UX) is clunky - something doesn’t look right or work well for a visitor to the site - we make sure to highlight this.
User Acceptance Testing
Once tickets have passed QA, they are sent to the client for user acceptance testing (UAT). UAT issues discovered by the client will be triaged and dispatched to the appropriate team. An issue may be in any of the following areas: development, requirements, configuration, or content. It may also be an area where more client training on the solution is required or perhaps, a new feature/enhancement is identified rather than a bug with existing functionality. If a UAT issue is a development bug, then it will be assigned to a developer, fixed, and validated by QA and then the client.
Finally, before a release is deployed to the production environment, we run a full regression test on the entire site to ensure that everything continues to function as expected and that no new defects have been introduced.
The Role of QA in Support
Our long-term managed services offering includes a service to maintain and support our clients’ digital solutions. Our QA involvement here follows a similar streamlined process as with our project work. One distinction with our QA process for support work is that regression tests are run more regularly - often monthly, especially if new work is introduced. We do this as it is imperative to verify that no new defects have been introduced and that everything continues to function as expected.
There are times when a client comes to us to take over the support of an existing solution of theirs rather than having us build something new from scratch. When we inherit websites we didn’t originally build, our QA team gets involved upfront during this transition. We begin with onboarding and creating a test suite that describes the functionality of the current site.
This is the reverse of the typical project process, as we are using the test cases to document existing functionality instead of writing test cases based on functionality for a solution that is yet to be built. We then use these cases to run a baseline regression test to determine how the site is currently working. From there, the standard support process can begin.
Next Steps: Set Up Your Website Redesign for Success
QA is an integral part of a website redesign undertaking. Using a rigorous QA process that is aligned with every phase of the project makes it possible to roll out higher quality solutions that can meet business objectives and the needs of your audiences.
If you’re having trouble with the quality of your current implementation or would like to ensure that you do your next website redesign right, reach out to us and let’s chat about your goals. We’d love to identify ways that we can help you overcome your current challenges and get to the next level with your digital marketing efforts. In the meantime, you can contribute to the discussion by commenting below or follow us on Twitter, @Velir.