A look inside Quality Assurance at Effective
By: Artem Mezdrin
Tags: Best Practices, QA, Testing, Effective, Quality Assurance

In my previous article Effective QA Best Practices, I showed the tip of the iceberg called Quality Assurance. Here I’d like to show you what software quality means for us and what baseline we use.

As you may know, QA is more than just the last line of defense between the end-user and a poor digital experience. No matter whether the product is a mobile app, web app, AR/VR environment, wearable, or another device connected to the web or other devices, QA at Effective is a critical part of ensuring a high-quality user experience across the entire customer journey.

“The role of QA at Effective is to ensure that customer interaction at every touchpoint throughout their journey are implemented the way they were designed.”

The customer journey encompasses all the interactions the user has with a product as well as the marketing and support elements around that product. The interactions along the journey are referred to as touchpoints. The journey’s first touchpoint is when the user first becomes aware of the existence of the product; and it continues on through regular use and follow-up. For example, we always collect feedback to help us improve the product. That’s another touchpoint!

The role of QA at Effective is to ensure that customer interaction at every touchpoint throughout their journey is implemented the way they were designed.

There are, of course, parts of QA that are purely product-centric and software-centric — that’s what we’ll focus on in this article.

For Effective, quality is both functional (conformity with given design and specifications) and structural (compliance with non-functional requirements and standards of software architecture) parts which include a lot of components. We base our definition of quality on ISO 25010. To check various quality attributes we use traditional types of manual and automated testing, such as functional, UI, usability, performance, compatibility, some other types.

As a great addition to the mentioned ISO 25010, we apply a “three perspectives” approach. For the entire QA process, it’s a frosting on the cake to achieve the most holistic overview of the product added to the default QA activities. Through our experience, we check the product as a software test engineer (checking it against the specifications and trying to purposefully break it), as a user (playing the role of a target persona) and as a business stakeholder (assuring the product as a whole, as well as its parts, ultimately helps achieve business and product goals).

To understand the value of the QA process we need to align it with a product creation lifecycle:

Our QA process covers nearly every part of it, from the beginning to the end. It’s not just a single “Testing” phase after the product is done; it’s a holistic iterative process that goes alongside with UX and UI design production (QA engineers make sure design deliverables are holistic and comprehensive so that our developers can focus on creating code) and software development. In the long run, it saves a lot of time and eliminates heavy back-and-forth processes close to release. Additionally, being an important part of many touchpoints also adds a lot of joy into QA’s work and creates an overall positive and productive environment.

Since the QA process goes through all disciplines and project activities, therefore all project teams including engineering, management, design, even business-stakeholders work on quality. The engineering team performs design reviews and helps make executable specifications complete. The design team performs visual QA of implemented features. Business stakeholders provide feedback during sprint demos. Future users of the application test it as well.

In some cases, design deliverables aren’t enough to cover all aspects of a product. It may happen every once in a while, especially when a product consists of complex subsystems and all of them are related to each other on different levels. We prepare test cases for this and we do it right after the design review and before development. It allows us to be ready for testing in time and create executable specifications for developers which are a combination of finalized UX and UI deliverables with described behavior and steps of user actions. The level to which we detail these specifications depends on the project size and complexity. These specifications are handy for development as direct instructions and expected behavior and for verification of implemented features. For test-cases management, we use TestRail which allows us to keep executable specifications updated and assign tasks for team members. Depending on the product scale and complexity, we prepare solutions for automated testing which can save a lot of client’s resources in the future.

And finally, to make sure we’ve made a top-tier product, we perform verification and validation activities during the entire product development process, starting with research and finishing with the release. These activities help us understand how we match the acceptance criteria. To perfect the QA process, we focus on certain metrics to measure process quality. We compare sprints, releases, or even projects with each other to see what we can improve. We have test plans for all projects and measure executed/not executed test cases, test cases passed and failed, defects density, and removal efficiency. As a final step, we gather the customer’s feedback as a high-priority metric, using surveys and retrospective meetings.

By combining our own testing methods, based on a deep understanding of the client’s business needs, with traditional ones, we invented a new modern QA process framework oriented to the fast, flexible, successful, and high-quality development of any digital products.