If you’ve ever read a fairy tale, you’re probably familiar with the concept of the fairy godmother. These magical beings materialize during tough times and bring good fortune to the story’s hero or heroine. But did you know fairy godmothers have a lot in common with quality assurance teams?

Until now, you’ve probably thought of QA in terms of exhaustive testing and meticulous attempts to break apps. But here at Infinum, our QA team consists of versatile, curious people who don’t let any part of the project fly under the radar. We become the project’s shadow that never leaves its side.

Some characters also need a bit more attention and care to shine, when good fortune runs out. In other words, QA becomes their fairy godmother.

Ready to work your QA magic? Here are ten practices to help you shield your project from harm and ensure that it lives happily ever after:

Once upon a time, there was a project. This project’s development time was estimated without even the design draft. After a while, the estimates were changed again and again, which made the project manager very unhappy. The designer was also sad. If he had been there, he could have helped estimate a more accurate time needed for development. But with the existing estimates, everything had to be rushed and changed on-the-go. With such little time, QA struggled to keep the project on track. They were already past the point of no return.

This disaster could have been easily avoided. The cursed team in this scenario forgot one basic rule: the planning and estimate phase serves as the foundation of any project. It’s critical to include the designer when creating time estimates – that allows everyone to agree on the optimal solution together, instead of having to go back and forth later.

In the prototyping phase, there are countless screens, states, flows and invisible micro-interactions. Therefore, a developer, PM, client or QA looking at the design could easily miss a critical element or misinterpret something. If any detail is unclear, it’s very difficult to discuss it, let alone identify or repair the problem. All of this can potentially lead to a wrong implementation, big design reviews, misunderstandings and other delays.

Remember, the designer knows his work best—which is why he should be the one interpreting it to other teammates. If face-to-face communication isn’t possible during the prototyping phase, discussions via Zeplin and InVision could be helpful.

In many cases, project deadlines or an agile project methodology requires fast development of smaller bits of an app. Under these conditions, development sometimes starts before the final design is approved.

That causes on-the-go changes, which are often poorly documented, hastily executed and require a lot of additional polishing to achieve the intended quality. This is hardly avoidable, but you should aim to do best with what you have – track which changes have to be made, why they are being made, question and discuss them, and make sure that they are implemented correctly whenever they have to be done.

The ideal solution? Do not start implementing anything until the design is finalized. By slowing down at the beginning of a project, you’ll save loads of time on the back-end. If you take the waterfall approach, it’s critical to ensure your design is ready in time. If you work agile, you can iterate design, but at some point, you should polish the feature and move on to the next one. Last but not least, it’s critical to set priorities for the entire team.

Zeplin is an extremely useful tool that includes the most technical information needed for implementing a feature according to the design. However, this tool should never be used in place of a team meeting with the designer. It’s worth repeating: The designer knows his work best.

Misunderstandings lead to mistakes, delays, and lower quality. Therefore, when the time comes to hand over design for implementation, it’s critical to hold a meeting that includes the entire team. This ensures everyone is up-to-date with current events and informed about all project details. During this meeting, the designer can provide further clarification and answer questions on the spot.

We all know there’s a huge gap between designers and developers—and not just in their professions. Whether it’s the way they approach a project, their interests or favorite ice cream flavor, designers and developers are often polar opposites. Despite their differences, they have to work together. That’s where you can jump in.

As QA, your role is to serve as the middleman between the designer and developer. Encourage both sides to learn from each other and make each other’s job easier. The key is to make sure they are communicating. Which brings us to our next tip…

Without developer-designer collaboration, implementation is kind of like shooting at a minuscule bull’s eye on a small target from a long distance…in the dark. If you’re skilled, you probably won’t miss the target completely. But why risk it? This is where good communication is key. Help them translate technical and design terms to each other until they become comfortable with the basic terminology. This will allow the team to solve problems efficiently and keep the project on track.

By fostering communication and collaboration between the designer, developer and the rest of the team, your project is set to be a booming success.

There will always be iterations in every project. Some big, some small, but changes are a fact of life.

At this stage, quite a few people are actively included in the project: designer, developers, QA, project manager, the client, and others. When any change occurs, all concerned parties should be properly informed.

Writing “@here” on a Slack channel does not qualify for “informed properly.” If the design changes, it’s important to update Zeplin and provide links to those screens where needed. It’s also vital to make sure that the project documentation isn’t scattered around and is always up-to-date. As QA, you should be aware of all changes and follow-up to make sure these updates are made.

In real life, users won’t be using software with dummy data. You’re not doing your designers any favors by using random test inputs. This is why it’s important to test out how the app will appear to the real user with real content in real situations. Sure, it will take more time, but your designer will be grateful and your product will be better.

Sometimes the app will be used in another language, in which the appearance could be significantly different. In this case, the UI issues could occur only with real data simulation. You won’t know if you don’t test it. So, don’t leave this one to chance. Use real data simulation when testing.

Prototype and implementation are never the same. This is why it’s important to conduct user testing with the “real thing” while implementing. Plus, this practice will provide valuable feedback for everyone involved. The designer can see his meticulously designed user experience in action; the QA can focus on the real user’s behavior, needs and expectations; and the developer can witness a custom UI element paying off, making all those long working hours totally worth it.

This process can also indicate if any further effort, changes or improvements would be worthwhile.

Of course, any conscientious tester will ensure the design is implemented properly and UI/UX are truly high quality. Even so, the designer should always have an opportunity to test any UI/UX-related tasks after implementation. That way, the need for big design reviews will be reduced, since most issues would be discovered and mended during this process. This is yet another way to ensure designers are included in the development process.

It’s important to work your magic throughout the project and to be the true fairy godmother to your teammates when they need you. If you follow these practices, your project is certain to live happily after ever.