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 responsibility for generating 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 find their way to software quality by putting an added pressure on the shoulders of 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, one that often results in unforeseen difficulties with the process, startups will take this approach. The reason: overconfidence. The result is often something less than quality software output.
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. Both separate from the development group from a functional skill standpoint, yet inclusive of 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 nearly always have a proven, well-defined development process that works. That’s why they are still in business! 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 on 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, not only about what to cover and the way it should be done, but also about 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 not infrequently works as the driving factor to determine the way the work gets done and, 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 at all (i.e., a remote software engineering services partner is part of the model), 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 engineers’ 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.
If the current team composition doesn’t help you tell who is responsible for what (this is not the same as who is doing what) or who is the right person to escalate issues to, these details need to be clarified 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 with the current practices without being a burden to the existing team members. Instead, it must be seen as a way to release them from all those extra tasks that are not specifically part of their job and something that will let them 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, at some level, the products they create and introduce to the market.
Starting by simple testing of what a developer executes before submitting code and ending with the typical user acceptance testing before going live, there are always testing activities within the development process.
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; instead, we must get the most out of these practices in order to benefit 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, 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 the understanding of the current process is over, a detailed definition of the expectations of the QA team must be done and, for this, the following questions should be answered:
- 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, just to mention a few. 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.
- What’s already covered by the development team?
- From the previous point, 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.
- 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 none of the team is a clear owner. So, 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 turns into 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 in mind the business side of the software product. 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 chance 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. And the basic concepts remain.
Manuel Cubillo Arias is QA manager at Avantica Technologies. He has over seven years of experience in the software development industry, particularly in the area of Quality Assurance. Currently managing QA related projects for North America customers of the Nearshore software engineering services specialist, Avantica Technologies, he works closely with startups and the Software 500. Together with testing engineers located in the company’s software engineering centers in Costa Rica and Peru, he collaborates using both traditional and Agile methodologies.