Guide on how to integrate external Quality Assurance into existing team?

Scaling up your project team is not an easy task — finding the right people is definitely a challenge, but it’s not the only factor contributing to an efficient and well-performing group. At Startup House, we already did the hard work by acquiring the top brains that are available, but the final piece of the puzzle is actually up to the owner of the team. From my experience, integrating external quality assurance into an already existing team can be tricky, as there are several barriers to overcome on more than one plane. But all this is worth the effort!

Why well-integrated Quality Assurance is important? 

A well-integrated tester can provide high value to the team and to the project itself, boosting the quality, as well as confidence in the project and its deadline dates (which are only getting tighter and tighter as everyone’s striving to disrupt the market these days). On the other hand, a poorly integrated one can cause frustration. 

Having experienced both of these scenarios on my own, here I would like to give you some tips helping to deliver promised value, with a bonus of high satisfaction for a Client and a team.

Introduce the QA to the product and the team

The two first things that the QA needs to know at the beginning of the project are: what it is about, and who to ask about it. An introduction to the product should ideally occur on the first day of the tester’s work, and should involve someone who can lay out not only the current tasks, but also the goals of the product. Additionally, the introduction needs to include getting to know the people. It can be very complicated, when e.g. there’s a frontend problem, but you don’t actually know who the frontend guy is. While you’re at it, make sure that the QA is given all the necessary accesses ;)

Include the tester in the project flow

Some might assume that the tester will take care of themselves from now on, but there’s a very important matter to address — the flow. If there was no Quality Assurance team before (as in most of the cases), the flow probably doesn’t take into consideration any quality assurance schemes and processes or it only involves the project manager/product owner or another person as the means of quality control. The best solution to this is to have the QA actually propose an adjustment to the flow — the key factor here is that, ideally, all parties should be comfortable with the changes. I say “ideally”, as sometimes that’s not achievable due to different expectations. 

Document A LOT

Documentation is the key to a well-tested application. There might be an urge to skip the documentation and just implement as much as possible, but it won’t be long until the point where someone doesn’t know how the feature should look like or how it should perform. It’s really hard to imagine a long-term project (and we all wish for our projects to be long-term, don’t we?) without a proper knowledge base. After all, this is what does the quality assurance team do — we compare the expectations with the results. For the most part, that is. From the quality assurance’s point of view, there are 3 main areas of documentation that we use (yeah, there’s also a repository, but I’ll skip that, as it’s more of a developer’s domain):

Knowledge base

The knowledge base should centralize all knowledge of the team members about the application, provide descriptions to features, designs, flows, etc. (along with quality assurance documentation). There’s no need to reinvent the wheel here — a simple set of pages on Confluence or some other tool will do, as long as it’s kept up to date. 

Tickets

There’s also the fact, that testers heavily rely on the description of tickets — if there is very little to no description in the implemented tickets, it’s much harder to determine if the feature is done or not, which makes us, testers, way less effective. A story with a proper description, linked design and proper acceptance criteria that the whole team contributed to are a dream to work on (while also producing less bugs, as the devs have a clear description of what to implement).

Accesses

Another great practice for managing documentation is implementing a password manager — it centralizes all the accesses, provides an easy way to share them and have control over who has access to what. Also, there are free options of such tools, so what’s your excuse to not use it?

Keep everybody in the loop

Keeping the team informed about recent events in the project seems like a no-brainer. Yet, I’ve had cases, where I learned about what the deadline for the release is only because someone mentioned it in conversation. Same goes for major decisions which are made during in-house meetings, but never make it to the remote guys. The effect of such communication issues is twofold. The first and most obvious way is that lacking needed information, the person doing their job (not only a QA), may not do it correctly, e.g. not performing testing before release because they didn’t know there was one coming up. The second one is psychological — imagine being kept away from crucial information because of a different legal relationship with the company you work for. Of course, mistakes happen, but repeatedly failing to deliver necessary information might make the affected person feel left out.

Make sure that everyone feels like a part of the team

Contrary to the previous points, this one is actually the most frequent to be done right. Especially when working with remote specialists, it’s not hard to alienate them. However, in most of my projects, working with the client’s team has been a true joy, as I was treated exactly like an in-house person would be. After all, we’re all working for a common goal, so being nice to each other definitely helps.

Listen to the feedback

Being professionals in our fields, we tend to have many observations about the project and processes. Even if it’s not explicitly in our area of expertise, having worked on a great deal of various projects, we are able to accurately assess the quality of the processes. After all, this is one of ways we can improve the quality of the project. Unfortunately, despite our best efforts, our ideas and suggestions are sometimes turned down or simply ignored. Of course, this also goes for all the team members, and not only the QA. Listening to your team can be very beneficial, as most of the time, the team members genuinely want the project (and product) to succeed.

As proven by the tips above, it’s not easy to integrate all the people in a team, with special focus on external Quality Assurance. Unsurprisingly, most of the them repeat one thing — communication — although in various forms. Information is the key to how a quality assurance tester works — by comparing the desired result to the actual one, we assess the quality of the outcome. If by a lack of communication we take away some of the information, it automatically impacts the end result of our work.

If you want to know more about tips how to build product teams, feel free to read how Startup Development House hire top 5% tech-talents and integrate them into teams.

If you want to hire our Quality Assurance specialists for your project, feel free to contact us: hello@start-up.house