<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=160269078105920&amp;ev=PageView&amp;noscript=1">
This service has been removed!
Service successfully added!
Sign up for our blog, talk to a specialist, or just send us an email

Integration of Stand-Alone QA Teams Into Mature Software Development Companies.

Tuesday 23 of October, 2018./ Reading Time: 6 minutes./ By Manuel Cubillo Arias

Achieving Quality Software.

Today’s software development market is under increasing pressure to deliver high-quality products to end users who are constantly looking for the next best thing — not only functional behavior but also innovation, look and feel, response time, compatibility and social interaction, among other requirements.

No matter the size of the company, the engineers in charge of creating software products have the responsibility to generate high-quality results. As a result, they must perform specific tasks on a daily basis to make sure the quality goals are accomplished.

Startup companies frequently try to achieve software quality by putting extra pressure on their developers, instead of the more logical approach of assigning a dedicated quality assurance (QA) team for that purpose. Even though this may be a cost-driven decision, it is one that often results in unforeseen difficulties with the process. The reason: overconfidence. The result is often something less than quality software output. 

The Right Way To Ensure Quality.

For mature software development companies, the situation is not as simple as asking developers to make the extra effort to meet quality standards.

The number of team members involved, the complexity of the development/release processes, the size of the code base or the number of products being developed are some of the key factors that lead these companies to choose stand-alone QA engineering teams. These stand-alone teams are both separate from the development group from a functional skill standpoint, yet included in the team within an Agile engineering model.

Setting up a stand-alone QA team within a mature software development company is not a simple, one-day task. Many aspects of the organization, the development process, and the products under development need to be thoroughly analyzed before implementing any changes in order to avoid operational challenges.

Understand your current development process.

Mature companies usually have a proven, well-defined development process that works. This is one of the main differentiators between mature companies and startups. Many aspects of their engineering process have been defined and improved over time and typically most of the team members are comfortable within that process.

Even though there’s no such thing as a perfect process, before trying to implement any changes, the company has to understand the current development process in all of its extension, in order to determine exactly where they are. Companies need to analyze the following important aspects.

1.What’s the development methodology being followed?

Implementing a QA process within Agile development requires specific considerations that are not necessarily a concern with more traditional approaches. Understanding the difference and identifying the real needs of each case will make a big difference.

2. How does the current release process work?

The frequency of the product releases will determine important details of the QA strategy. You will need to determine what to cover and the way it should be done, as well as the size of the required team and the tools that will be needed to accomplish the goals.

3. What kind of infrastructure is currently supporting the development and release processes?

Infrastructure often functions as the driving factor, determining the way the work gets done. Depending on what you have, activities can “hit a wall” sometimes sooner than expected. The same infrastructure that is currently working perfectly for development purposes might need some tweaks to support the introduction of a stand-alone QA team:

  • Dedicated testing environments are usually necessary to avoid conflicts generated by both software development and QA teams working on the same servers.
  • If the QA team is distributed geographically, or is not working at the same facility (i.e., a remote software engineering services partner), remote access to all the necessary resources is a must.

Those are just a couple of examples. However, the list can easily grow, depending on the specific conditions for each case.

4. What’s the current development team composition?

Adding a QA team into the process is not a matter of just getting some experts together and introducing them to the existing team. Even when the QA engineer’s work does not step over the software development tasks directly, day-to-day collaboration is a key factor necessary to accomplish real integration and successful results.

You will need to clarify who the right person is to escalate issues, and generally who is responsible for what, before bringing the QA team into the picture, in order to avoid issues during the integration of the new team members.

The QA team has to fit in with the current practices, without being a burden to the existing team members. Instead, QA team integration must be seen as a way to release developers from all those extra tasks that are not specifically part of their job. Integration is ultimately something that will let developers focus completely on what they should be working on — development.

Identify the testing practices already implemented. 

It is not possible for a software development company to survive without testing the products they create and introduce to the market.

There are always testing activities within the development process, starting with simple testing of what a developer executes before submitting code and ending with the typical user acceptance testing before going live.

In the past few years, many testing practices and technologies have emerged as a way to support developers in their pursuit of software quality:

  • Unit testing and a variety of tools to make it easier, no matter the selected programming language
  • Continuous integration of the code base as a way to detect any possible integration issues with less human intervention possible
  • The usage of staging servers for final quality certifications before pushing code to production

All of these are important practices and the introduction of a stand-alone QA team does not mean they will disappear. Rather, we must make the most of these practices in order to ensure the final product quality. Having a defined process for testing the code at the unit level and going through a continuous integration process during the development stage will ensure the QA team will receive a higher quality release that is less prone to incurring problems on the individual components.

These practices allow QA to focus more on system testing from a workflow perspective or to start looking for performance and security issues. However, a very important question needs to be asked: Who is ultimately responsible for product quality?

Definitively, everyone on the team shares product quality and it is this joint effort that will bring the expected quality to the final product. Taking advantage of the current testing practices will certainly help as long as QA and development understand they must work together to cover the areas each other is missing.

Define clear objectives for your QA team.

Once we understand the current process, a detailed definition of the expectations of the QA team must be done and, for this, the following questions should be answered:

1. What do we want to get from a QA process?

This question needs to be answered by defining tangible results that can be measured: detailed test case definitions, automated scripts or quality metrics, etc. This can also be complemented with some other aspects like team integration or visibility. Just remember to identify a way to size and evaluate the results on each case.

2. What’s already covered by the development team?

Identify all those items currently covered by the development team and the level of coverage currently provided. If you don’t have a way to determine the coverage, you may want to revisit your answer to the previous question.

3. What must be covered by the development team and what must be covered by QA?

Assign each item to one of the teams, according to your needs and situation. There may be some items that are hard to classify since no one in the team is a clear owner. Therefore, try an initial (justified) guess and tweak your decision in the future if necessary, but never leave an item unassigned.

Design a process to accomplish your goals.

When you have a clear idea of how your current process works, what the current state is, and what you want to get from the upcoming changes, identifying the improvement areas becomes an easier task.

Adding a QA team will require a new QA process to cover all of your goals; however, it should be integrated with the general development process if you want to get the most out of it. For the development of the software product, QA and development teams will need to collaborate closely and coordinate frequently to make sure the process is being followed and the resulting product has the proper quality coverage.

The clearer the process definition is, the easier it will be for the team to execute!

One important aspect in this area is to always keep the business side of the software product in mind. The engineers can easily go deep into technical details of the development and QA process, but not always pay the necessary level of attention to the business realities the software is intended to address.

Having a QA process integrated as part of the general development life cycle and making sure the engineering team understands it and is aware of the business side behind it, will increase the chances for success with your development process. 

Final Step: Make sure you have what you need to implement your process.

You can get to a single place following many possible paths; you can integrate a QA team into your development process in many different ways. There will always be budget limitations, existing contracts with certain vendors, or just the preference for certain tools within the team.

No matter what the conditions are, you need to make sure the team has what it needs to take the process from concept to execution. Tools and infrastructure may differ from one implementation to another, but they should not affect the outcome of quality software as long as the existing conditions allow the team to follow the defined process. The basic concepts always remain.

About Avantica.

If you are looking for a software partner who will work towards your own business goals and success, then Avantica is your solution. We offer dedicated teams, team augmentation, and individual projects to our clients, and are constantly looking for the best methodologies in order to give you the best results.

 Let's Start a Project Together

 

PREVIOUS
Balancing your Jenkins Workload on a Master/Slave Setup.
NEXT
Metrics and Decision Making in QA Teams.

YOU MAY ALSO LIKE