Engineering

The difference in approach to quality assurance in a software house and a product company

Testers and quality assurance specialists without work experience in more than one IT company may not take into account these two important factors when looking for a new place of employment: the type of a company and the way it runs the business. Of course, there are many companies that do not fit into the typical archetypes, the method of software development or work culture in such companies mix many known solutions, but in general, we can distinguish three types of IT companies:

  • a product company that produces its own proprietary software, has dedicated teams in which the roles are very intertwined
  • a software house that usually works on the basis of outsourcing, creating custom software, often for a specific period of time
  • a startup, which is a company at the beginning of its activity, often without an adopted work model, looking for financing

The most frequently chosen places of employment are companies with an established position, so we will discuss product companies and software houses in this article. Work in each of them can take a completely different form, also in the sphere of interest of a quality assurance specialist. The nature of this work may change over time, because a change in the project life cycle, or the project itself, sometimes enforces a different approach to quality assurance. After gaining several years of experience and working in both types of companies, I have come to the following conclusions.

It's easier to start a career in a product company

Product companies are not as open organizations as software houses that are usually small, close-knit organizations with less than 100 employees. Working on one or two projects binds the entire organization together and makes the same people perform different roles. There is nothing strange in the fact that the team leader is also a scrum master, backend developer and key account manager. This means that people who are employed in such companies can get to know many different forms of work on the product, get to know them inside out and finally focus on something that interests them the most. They also have the opportunity to raise their qualifications completely from scratch, because product companies like to hire a less qualified employee at the initial stages of product development to train and specialize them in a given project. It is no different with a beginner quality assurance specialist who has the opportunity to train for the profession under the supervision of a colleague with more experience, or a developer specializing in a specific technology, who will provide them with basic information at the beginning of their career path, and the effect of this learning depends on the tester themselves. In such companies, independence and willingness to learn are strongly emphasized. In a software house, which creates products for other organizations, more experience is expected at the start, because the image of the entire company may depend on how effectively QA works.

Contact with the users

More frequent contact with the users of the product company is the consequence of the large overlap of duties. Often during our work, we have received questions from customers - including business customers - about the product. In a software house, there are usually dedicated people specializing in such conversations. In a product company, testers, as one of the best people who know the product inside out, may have the opportunity to talk to users, support the technical helpline and the sales and marketing team.

Greater project variability

In-depth product knowledge that results from longer work on one project, of course, comes at a price. People working in product companies often complain about stagnation, lack of challenges or little prospects for further development. It also seems impossible to move to another project, because the company may not have one, already have a complete team, or be reluctant to sort employees as a part of internal projects due to company policy. In a software house that makes a living from opening and running many parallel projects, such a situation is less frequent. In the event of burnout after several years of working in one environment, you can ask for a transfer, and it is also beneficial for the company itself, because it retains an experienced employee who is less willing to leave the current job. It is true that projects in a software house often last 6-12 months, because that is how long it takes to build a product which is then maintained by the client himself. But in Appunite, which focuses on a long-term relationship with the client, the situation is quite different. Some projects are developed and maintained here up to 7 years, which ensures deep product knowledge of employees, including quality assurance specialists, and allows for the development of competence and transition of the gained experience to another project.

Other development opportunities

This point is the result of the previous one. Due to a lower chance of changing the project in the product company, there is also less chance of development within the company in which you currently work. Software House not only allows you to change the team, but also to learn a completely new technology. In product companies that create their own applications, the knowledge of technology is often very unified, because it is easier to develop many products in one technology. In the event of an employee's indisposition, he or she can be temporarily replaced. The cost of maintaining tools is reduced too. Software houses create products for external clients, whose requirements can be extremely different. For this reason, the composition of used technologies in the company can be very diverse, which makes it much easier to develop when the team changes.

Different focus on automated testing

The subject of automated testing in companies is strongly dependent on the company’s policy and the stage of the project life cycle. Some product companies don't bother with it, others consider it a nice addition, some need it due to the importance of the project’s quality, which may affect the company's budget and ensure the stability of operation. In a software house, due to the usually short duration of the project, there is no emphasis on creating such tests, many companies prefer to hire junior QA/testers, who will deal with manual tests, which are a priority in the initial stages of application development due to the rapid growth and variability of the product. In Appunite, owing to the longer project support time, automatic testing is one of the requirements for the proper product quality control. The size of the project after two years is so demanding that the appropriate level of manual tests would take up most of the tester's working time, and yet, there is always a new increment to be checked and other duties of the daily work to be taken care of. For this reason, all testers in the company focus on the development of automatic tests of various types that increase the quality of the increment, shorten the time needed to conduct tests and, as a result, bring additional profit to the company. After all, it is well known that time is money.

Transition of the product into maintenance phase

Larger product companies often create ad hoc applications, needed for marketing reasons or to collect data useful in other products, which are developed in a short period of time, and quickly move to the maintenance stage. They are not developed further and do not require quality control from the development team, thus, a quality assurance specialist becomes unnecessary for such a project. It is not uncommon in such situations to terminate the contract with QAs who were employed only for such projects and there are no plans to implement them in the subsequent ones. As I have mentioned earlier, many product companies, of course, do not dismiss employees because the experience gained in the workplace is valuable for both the employee and the employer, and it is better to train such a person and keep them close to you, than to give it to the competition. Software house adheres to a similar policy, with the difference that even short projects do not end in layoffs, but transfer the workers to “the bench", until a new project is found or they are transferred to an existing one right away. Thanks to that, the maintenance phase is not identified in such companies with the end of cooperation, but with the beginning of something new.

Resistance to failure

A failed project for a product company can mean financial stability issues if the company is small and running up to three projects at a time. The loss of one of them can often lead to layoffs, including quality assurance, which in the event of a crisis can be a burden for such a company. A software house, due to its focus on opening new projects, is more resistant to this. A quality assurance specialist that has gained experience in one project can be transferred to another without much loss for the company and even bring profit due to having a bag of experience that may be valuable for the future user. This creates a sense of stability and allows you to focus on improving your skills instead of looking for a new job.

Summary

Product companies and software houses create many opportunities for testers, but each of them offer different perspectives. Product companies are a good starting point for a beginner quality assurance specialist, who needs to be implemented in a stable work environment. Software house is great for quality assurance specialists with experience, looking for challenges and focusing on self-development.