Signing a Contract with QA Company

Who is responsible for the quality of the final product: the in-house developers or the outsourced providers of software testing services? It all depends on the initial agreement. Let’s review the most common types of contracts that define the client-vendor relationship and responsibilities.

Who is responsible for the end quality?

Demands of an enterprise-level company may differ from those of a start-up. What they both share is the aim to receive a high-quality product in the end. Different types of cooperation models define different levels of responsibility from each side.

Dedicated team. The client hires an employee or a team from the QA company. The team may be responsible for Quality Assurance only, which does not necessarily mean all the bugs will be fixed, but it does mean the client has to receive a full bug report and recommendations for how to eliminate them. On the other hand, the in-house team may be responsible for fixing all the bugs, if it is given full access to the code and has a demanded level of expertise to perform this job. A Consulting Agreement and Work Order are the most common types of contracts signed in this type of cooperation.

Project-based cooperation. The client gives the whole project to the QA company to receive testing services. This type of cooperation may be versatile, depending on the workload, the client’s needs, and on the company’s expertise. Usually, the experts apply many testing techniques to fully examine the product in terms of its performance, convenience, and reliability. The vendor may be responsible for fixing all the found bugs upon the client’s demand. However, the client may have their own team of in-house developers, which explains why they may order QA services only, where testers just have to find a certain percentage of bugs and provide detailed bug reports. The contracts, signed in this type of cooperation in most of the cases, are NDA and Consulting Agreement.

Non-Disclosure Agreement

When the client chose the software testing company that they are going to cooperate with, a Non-Disclosure Agreement (NDA) is usually the first contract to be signed. It is important for the client to protect their idea and proprietary information from competitors. Depending on the priorities of both sides and what needs to be covered by the NDA, it may be signed by only one of two parties, or by both of them.

Collaborating on software development and Quality Assurance, confidential information covered by NDA may include but is not limited to:

  • the code, written or edited by programmers of the company-vendor;
  • passwords and credentials, if the client only orders testing services and provides the vendor with access to the existing software;
  • methodologies and communication channels that parties work by and use in the course of collaboration;
  • software utilities that vendor uses while working with the client software;
  • the information about project budgeting, ways of payment, and responsible legal entities;
  • analytical data, bug reports, and other documentation that is produced and/or used during the QA testing process.
  • personal information about hired team members and their roles in collaboration whatsoever;
  • the name of the company and/or the product that the vendor is working with.

Violation of any of the stated items in the NDA gives the offended party a right to press charges. After this, the trial sends subpoena and the further process totally depends on the violation severity. The most common punishment for breaking the NDA in the IT-services type of relationship is a penalty charge.

Every case is different, and sometimes, NDA is the only contract that seals the deal. Although, in most cases, there are additional contracts that support both sides in the course of collaboration to make sure they can trust each other upon the job done properly and on time.

The estimate

The estimate is not a contract, but this type of documentation is important to mention as it plays one of the most important roles in the client-vendor relationship. Before anything is done about the client’s software, the vendor has to define a likely cost and time that is expected to be spent on this QA testing process.

The estimate is composed based on the provided information about the service that the client wants to receive from the vendor. Estimated cost and time vary depending on the needed type(s) of testing to be done, the number of people involved in the process, the level of required expertise, and the chosen business model (project-based cooperation, dedicated team, staff augmentation).

Collaboration depends on whether the client agrees with the estimated numbers. Usually, both sides achieve consent after negotiations and decide upon the further way of doing a deal.

Consulting Agreement

When the client is ready to start a collaboration with the vendor, they both sign a Consulting Agreement (CA). This type of contract may be short if it is not the only official document signed in collaboration. On the other hand, it can be very long if it’s the only contract between the sides. In any case, a Consulting Agreement usually includes the following information:

  • the name(s) of the service(s) that the company provides to the client;
  • the maximum time that the vendor has to perform all their duties;
  • the estimated cost for the testing services, and potential ways of leveraging risks in case the responsible side experiences overheads and technical debt;
  • the consequences of the agreement breach;
  • the maximum length of the agreement and collaboration.

If the client-vendor relationship is continuous, like in project-based cooperation, there may be a need in more in-depth legal documentation to secure the whole process for both sides. Such cooperation implies multi-level development, testing, support, and maintenance services, from the very start until the very end of product development.

Work Order

Work Order (WO) is a bit similar to the estimate but it contains more details about the project’s workload, deadlines, and team members.

For example, if the client hires a dedicated testing team, the Work Order will state all the necessary information about the employees, including their level of skills, tech stack, and the term that they’re hired for.

If the client gives a full project for testing to the vendor, such a long-term collaboration will demand more detailed legal documentation. In this case, WO will be an additional document to the Consulting Agreement.

Service Level Agreement

Service Level Agreement (SLA) is a contract that obliges the vendor to perform their job at a predefined quality level. SLAs are optional and vary widely depending on the client’s business model: B2B or B2C.

  • B2B (business-to-business) cooperation is exactly how TestFort works with the clients. The company orders a pack of testing services from TestFort, signing Non-Disclosure Agreement, Consulting Agreement, and Work Order on demand. In such case, SLA is not necessary, because everything there is to know about the expected result is already stated in the CA and WO.
  • B2C (business-to-client) cooperation, on the other hand, may be established on the basis of SLA only. For example, Internet providers promise their clients to maintain connection 99% of the year, which is 361.35 days. Stating this, the provider is obliged to make sure the connection is stable most of the year but also has a right to switch it off in case of an emergency. However, only on the terms that it won’t be switched off more than 3.65 days per year in total.

SLA rarely figures in outsourcing vendor-client relationships, while the Consulting Agreement is its engrained part. The main issue with signing the SLA is that the client is not always aware of its existence, or vice versa, they think it’s necessary when it’s not. The other issue is the responsibility, that the client is not always ready to accept. SLA obliges not only the vendor to provide a high-quality service, but also a client to be available for negotiations upon the vendor’s need. SLA may state that a company-vendor has a right to immediately stop working on the project, if a client did not make a contact within N weeks. In such case, the whole cooperation is under the threat if the client disappears in the middle of the QA testing process.

Legal documentation is considered the key trust-factor in all business deals, but we believe that the easiest way to gain trust from the clients — is professionalism and diligence. Contracts usually play the role of a security tool for both sides, and if the job is done on the highest possible level of quality and transparency, the client always comes back and spreads a good word about the team.

This article was originally published on TestFort.



Head Of Business Development at QArea. I’m passionate about new technologies and how digital changes the way we do business.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sandra Parker

Head Of Business Development at QArea. I’m passionate about new technologies and how digital changes the way we do business.