How to Integrate Third-party Code Without Worrying About QA

Software development has become a very integrated activity over the last decade, where instead of one large piece of code developed in-house, a lot of small pieces flow and fall in place like pieces of a puzzle, to shape the final product. Such integrations and collaborations have been necessitated by a lot of drivers in the market such as: Need for faster time to market, leverage domain expertise from specialists rather than building everything in house, feature rich product, technology advancements that make such integrations seamless and possible. For a long time now, cross group collaborations within a company have been encouraged to promote resident experts in a specific area, ease of code maintenance, modular functionality etc. Many of us almost always see such integrations in areas such as login functionality, payment processing, installation and setup. In the more recent years such integrations have extended bounds with ISVs now willing to integrate external code bases with theirs to compete and maintain an edge in the marketplace.

Besides some areas, a few others that have always been excellent targets for external interfacing include analytics, testing and reporting. The world of application development is now opening several doors for such external integrations. Having looked at some of the striking advantages such integration brings, one cannot miss the inherent challenges in such third party collaborations. Based on the experience of dedicated QA teams https://testfort.com/dedicated-software-qa-team with hundreds of projects behind them, we can review some, as well as appropriate strategies for solving such problems.

Challenges and some mitigation strategies:

Challenge: Quality of Code

This is a huge challenge since you have a third party team that is working on giving you the source code. Very often, product teams’ face challenges in imbibing coding standards within their own team. In such scenarios, how do you ensure code quality from an external team where you do not have complete visibility into and control on?

Mitigation Strategy:

• Define clear protocols and coding standards to use and ensure they are consistent with what is being used in house.
• Define metrics for measuring code quality and associate them with Service Level Agreements (SLAs) to reward (for met and exceeded expectations) and penalize (for expectations not met).
• Define and implement quality gates/checkpoints, before integrating third party code into your code base.

Challenge:

Getting the external team to understand your business requirements, time, cost and quality constraints and effectively customize their code to meet your needs.

Mitigation Strategies:

• Involve the external team sooner than later in your product development life cycle and engage them in all important business and product conversations, including any field trips, client visits.
• Encourage free flowing yet managed communication channels between your business team and external team. It says managed as unless this is monitored, the entire flow can soon become very haphazard.
• Ensure transparency of communication at all times and insist such interactions from their end also to understand their product timelines, challenges if any.
• Get the third party team to spend adequate cycles on using your product hands on; unless this is done, they will only get a theoretical view of the product and will not be able to deliver a quality integration piece.

Challenge: Defect Management

Disconnected defect management practices often result in huge gaps in timelines to fix defects, incomplete defect fixes, ineffective handoffs between teams etc. all of which lead to delays in project timelines and increase in project total costs.

Mitigation:

• Establish clear defect management protocols at the start of the project including acceptable timelines, entities involved in the hand shake between the two teams, tools to use etc.
• Define service level metrics around number of defects, type of defects, severity of defects, defect fix timelines, regressions etc. at various stages in the product lifecycle.
• Get the third party team to spend adequate cycles on using your product hands on; unless this is done, they will only get a theoretical view of the product and product development and defect fixes will not be comprehensive.

Challenge – Maintenance of external code, post the initial release is often a huge challenge.

Mitigation:

• Think about code sustenance upfront. If you want the external team to continue to own the code, understand and align their release cycles to yours, so their code is up-to-date in user features and functionality, use of technology, defect management etc.
• If code is to be transferred to your team, ensure you have the right team identified for training and take over; have one person assigned from the external team for future questions and clarifications.

Having talked about some of the core challenges and mitigation strategies, let’s now look at some vital quality gates that need to be implemented in the product team in addition to the quality checks done by the external team before and after code integration.

• Static analysis of code – This is important to ensure the code meets the standards defined by the product team and is safe and free of vulnerabilities before it can be integrated mainstream. Code needs to be scanned especially from a security standpoint at this static level, to ensure no malicious snippets are being integrated. Such static analysis can either be done manually or with the use of home grown or commercial code scanners. Such scanners run through all possible execution paths of the code and spit out issues / errors, warnings, vulnerabilities etc. This is a great checkpoint before code integration happens and is also one of the right situations at which Service Level Metrics can be enforced.

Dynamic Analysis of code: At the dynamic level when the code is run, the following checks become important at the black and white box levels:

• API level checks – automated tests at the interface level and database level to ensure interfaces work fine, are secure, have the right schemas and are consistent with the core product architecture and technology.
• Performance Testing – check for configuration files, setup files etc. to ensure the right parameters are being used. If the integrated external code is not on par with the core code, it can often pull down the performance of the entire product. This is also one of the right stages for the product team to mandate SLAs to the external team.
• Functional testing and UI testing at the black box level to ensure the E2E functionality works fine, the UI is consistent overall and that the integration points are not apparent to the end user. Solid integration testing herein needs to be undertaken to ensure a seamless end user experience. If the external team has done specific customizations to align with your product line, such customizations also need to be tested for.
• Security Testing – This is one of the most important aspects to check for to ensure no vulnerabilities have been introduced, especially when third party code (on which the product team may not have complete control) is being integrated into your mainstream code.

In short, third party code integrations are becoming the need of the day to enhance your core product’s functionality. Do not be intimidated by the challenges it poses. Be aware of them and attack them at the very early stages to fully benefit from such external code; for which, as you have seen above, quality assurance right from the early stages is a very important wand.