Outsourcing QA in the world of DevOps – Best Practices for Dispersed (Distributed) QA teams

DevOps is the preferred methodology for software development and release, with collaborating teams oriented towards faster delivery cycles augmented by early feedback. QA is a critical binding thread of DevOps practice, with early inclusion at the story definition stage. Adoption of a distributed model of QA had earlier been bumpy, however, the pandemic has evened out the rough edges.

The underlying principle which drives DevOps is collaboration. With outsourced QA being expedited through teams distributed across geographies and locations, a plethora of aspects that were hitherto guaranteed through co-located teams, have now come under a lot of pressure. Concerns range from constant communication and interworking to coverage across a wide range of testing types – unit testing, API testing as well as validating experiences across a wide range of channels. As with everything in life, DevOps needs a balanced approach, maintaining collaboration and communication between teams while ensuring that delivery cycles are up to speed and the quality of the delivered product meets customer expectations.

Outlined below some of the best practices for ensuring the effectiveness of distributed QA teams for an efficient DevOps process.

Focus on right capability: While organizations focus to a large extent on bringing capabilities across development, support, QA, operations, and product management in a scrum team, paramount from a quality perspective would be QA skills. The challenge is to find the right skill mix. For example, a good exploratory tester; good automation skills (not necessarily in the same person). In addition, specialist skills related to performance, security, accessibility also need to be thought through. The key is to choose an optimum mix of specialists and generalists.

Aim to achieve the right platform/tool mix: It is vital to maintain consistency across the tool stacks used for engagement. As per a 451 research survey, 39% of respondents juggle 11 to 30 tools so as to keep an eye on their application infrastructure and cloud environment; 8% are even found to use over 21 to 30 tools. Commonly referred to as tool sprawl, this makes it extremely difficult to collaborate in an often decentralized and distributed QA environment. It’s imperative to have a balanced approach towards the tool mix, ideally by influencing the team to adopt a common set of tools instead of making it mandatory.

Ensure a robust CI/process and environment: A weak and insipid process may cause the development and operations team to run into problems while integrating new code. With several geographically distributed teams committing code consistently into the CI environment, shared dev/test/deploy environments constantly run into issues if sufficient thought process has not gone into identification of environment configurations. These can ultimately translate into failed tests and thereby failed delivery/deployment. A well-defined automated process ensures continuous deployment & monitoring throughout the lifecycle of an application, from integration and testing phases through to release & support.

A good practice would be to adopt cloud-based infrastructure, reinforced by mechanisms for managing any escalations on deployment issues effectively and quickly. Issues like build fail or lack of infra support can hamper the productivity of distributed teams. When strengthened by remote alerts and robust reporting capabilities for teams and resilient communication infrastructure, accelerated development to deployment becomes a reality.

Follow good development practices: Joint backlog grooming exercises with all stakeholders, regular updates on progress, code analysis, and effective build & deployment practices, as well as establishing a workflow for defect/issue management, are paramount in ensuring the effectiveness of distributed DevOps. Equally important is the need to manage risk early with ongoing impact analysis, code quality reviews, risk-based testing, and real-time risk assessments. In short, the adoption of risk and impact assessment mechanisms is vital.
Another key area of focus is the need to ascertain robust metrics that help in the early identification of quality issues and eases the process of integration with the development cycle. Recent research from Gatepoint and Perfecto surveyed executives from over 100 leading digital enterprises in the United States on their testing habits, tools, and challenges. The survey results show that 63 percent start to test only after a new build and code is being developed. Just 40 percent test upon each code change or at the start of new software.

Devote equal attention to both manual and automation testing: Manual (or exploratory) testing allows you to ensure that product features are well tested, while automation of tests (or as some say checks!) helps you with improving coverage for repeatable tasks. Planning for both during your early sprint planning meetings is important. In most cases, automation is usually given step-motherly treatment and falls at the wayside due to scope creep and repeated testing due to defects. A 2019 state of testing report, shows that only 25 percent of respondents claimed they have more than 50 percent of their functional tests automated. So, the ideal approach would be to separate the two sets of activities and ensure that they both get equal attention from their own set of specialists.

Early non-functional focus: Organizations tend to overlook the importance of bringing in occasional validations of how the product fares around performance, security vulnerabilities, or even important regulations like accessibility, until late in the day. In the 2020 DevSecOps Community Survey, 55 percent of respondents deploy at least once per week, and 18 percent claim multiple daily deployments. But when it comes to security, 45 percent of the survey’s respondents know it’s important but don’t have time to devote to it. Security has a further impact on CI/CD tool stack deployment itself as indicated by the 451 research in which more than 60% of respondents said a lack of automated, integrated security tools is a big challenge in implementing CI/CD tools effectively.

It is essential that any issue which is non-functional in nature be exposed and dealt with before it moves down the dev pipeline. Adoption of a non-functional focus depends to a large extent on the evolution of the product and the risk to the organization.

In order to make distributed QA teams successful, an organization must have the capability to focus in a balanced and consistent way across the length and breadth of the QA spectrum, from people and processes to technology stacks. It is heartening to note that the recent pandemic situation has revealed a positive trend in terms of better acceptance of these practices. However, the ability to make these practices work, hinges on the diligence with which an organization institutionalizes these best practices as well as platforms and supplements it with an organizational culture that is open to change.

Trigent’s experienced and versatile Quality Assurance and Testing team is a major contributor to the successful launch, upgrade, and maintenance of quality software used by millions around the globe. Our experienced responsible testing practices put process before convenience to delight stakeholders with an impressive industry rivaled Defect Escape Ratio or DER of 0.2.

Test our abilities. Contact us today.

Improve the quality of digital experiences with Performance Engineering

Quality at the heart of business performance

“In 2020, the key expectation is fast, reliable, and trustworthy software.” *

As businesses embrace the Agile/DevOps culture and the emphasis on CI/CD is growing, quality assurance is seen as a standalone task, limited to validating functionalities implemented. When QA and Testing is an afterthought in an Agile/DevOps culture, the result is a subpar consumer experience followed by an adverse impact on the revenue pipeline. Poor customer experience also directly impacts brand credibility and business equity. While UI/UX are the visible elements of the customer experience, product, or service performance is a critical element that is often neglected. Performance Testing identifies the gaps that are addressed through Performance Engineering.

Small steps, significant gains – the journey towards Performance Engineering

The deeper issue lies in the organization’s approach towards quality and testing – it is considered an independent phase rather than looked upon as a collaborative and an integrated approach. Performance engineering is a set of methodologies that identifies potential risks and bottlenecks early on in the development stage of the product and addresses them. It goes without saying that performance is an essential ingredient in the quality of the product, there’s a deeper need for change in thinking – to think proactively, anticipate early in the development cycle, test and deliver a quality experience to the end consumer. An organization that makes gradual changes in its journey towards performance engineering stands to gain significantly. The leadership team, the product management, and the engineering and DevOps at different levels need to take the shift-left approach towards performance engineering.

Make Performance Engineering your strategic priority today

Despite the obvious advantages, performance testing is typically a reactive measure that is addressed after the initial launch. However, organizations need to embrace performance engineering measures right from the design phase, start small, and take incremental steps towards change.

Covid-19 has rapidly changed the way consumers behave globally. Businesses caught onto remote working; consumers moved shopping, entertainment, banking, learning, and medical consultations online. Consider the quantum jump in usage triggered by the pandemic.

The dramatic increase in the use of digital services has covered decades in days.**

Companies that adopted scalability and performance centric design have moved swiftly to capture the market opportunity.

With multiple user-interfaces across sectors being the norm and the increasing complexity of digital experiences, it is critical for businesses to get it right the first time in order to gain and retain customers’ trust.

As cloud migrations continue, whether rehosting the app on an IaaS or rebuilding a new approach, performance engineering ensures that migrated systems withstand sudden surges in usage. According to a Sogeti and Neotys report, 74% of the load testing infrastructure is operated in the cloud today. Cloud infrastructure providers ensure reliability but they may not be aware of the performance metrics that matter to the business and their impact. As organizations move from monolithic systems to distributed architectures provided by an assortment of companies, corporate leaders need to recognize the importance of performance engineering and embrace it to deliver the right solutions for the first time.

Our approach to Performance Engineering philosophy

At Trigent, we put the customer experience at the heart of planning the entire testing cycle. Our performance engineering practices align with ‘metrics that matter’ to businesses in the DevOps framework. While testing identifies the gaps in performance, the onus of architecting it right lies on the DevOps engineering team with proactive inputs from QA and Testing.

Performance engineering is also a way of thinking, the ability to plan for performance at the time of design, right at the beginning. As for quality, besides testing for functionality, anticipating potential bottlenecks helps us assess the process in its entirety in the beginning.

Asking some of these customer-centric questions early on shifts the perspective right at the outset. Ask them early, and you’re on your way to a performance engineering culture.

Parameters that matter

‘Will my application meet the defined response-time requirements of my customers?’

Consider an app that doesn’t respond within the expected standards of the customer; the chances of that application making it to the customer’s phone screen is pretty slim.

‘Will the application handle the expected user load and beyond?’

An application that tested well with 10 users may fail when that number is multiplied by a thousand or two.

We take the viewpoints of multiple stakeholders, consider parameters that matter to the customer, and assess impact early on.

Customer experience matters

Performance Engineering takes into account the overall experience of the end-user and their environment.

Asking pertinent questions such as ‘Will my users experience acceptable response times, even during peak hours?’ or ‘Does the application respond quickly enough for the intended users?’ does well to anticipate potential pitfalls in network usage and latency.

‘Where are the bottlenecks in my multi-user environment?’

Understand the real environment of the user and their challenges to provide a quality user experience.

Early Focus

The non-functional aspects are integrated into the DevOps and an early focus on performance enables us to gain insights into architectural issues.

‘How can we optimize the multi-user application before it goes live?
‘How can we detect errors that only occur under real-load conditions?

Quick course corrections help optimize performance and make the product market-ready. Besides faster deployment, quality assurance gives our clients an added advantage of reduced performance costs.

Architect it right

‘What system capacity is required to handle the expected load?’
‘Will the application handle the number of transactions required by the business?’

Important questions like these focus on architecting the product for performance. As part of the performance engineering methodology, our teams consistently check and validate the capabilities at the time of developing the product or scaling it up. We take the shift-left and shift-right approach to anticipate, identify, and remove bottlenecks early on. Getting the architecture right enables us to deliver and deploy a high-quality product every time.

Performance engineering done right is sure to improve the planning-to-deployment time with high-quality products. Plus, it reduces performance costs arising out of unforeseen issues. A step-by-step approach in testing makes sure organizations move towards achieving performance engineering. Talk to our experts for scalable performance engineering solutions for your business.

Learn more about Trigent software testing services.


Reference:
* The State of Performance Engineering 2020 – A Sogeti and Neotys report
** Meet the next-normal consumer – A McKinsey & Company report

Outsourcing Testing in a DevOps World

Software products today are being developed for a unified experience. Applications are created to perform and deliver a seamless experience on multiple types of devices, operating on various platforms.

Additionally, the growing demand for launching products at pace and scale is pushing businesses towards ensuring that they are market-ready in shorter time frames. The prevalence of Agile/DevOps practices now requires testing to be carried out simultaneously to development. Continuous development, integration, testing, and deployment have become the norm. Testers are now a part of the development process, testing the features, releases, and updates in parallel as they get developed.

The testing & deploying of a multi-platform product in a fast-paced environment requires expertise and complimenting infrastructure to deliver a unified experience. Add multiple product lines, constant updates for new features, a complex deployment, a distributed user base, into the mix, and your search for an outsourcing partner could become a daunting task.

We share some considerations that can guide your decision making — drawn from our experience of working as outsourcing partners for some of our clients, helping them deliver quality products on time.

Criteria our clients applied before selecting us as their outsourcing testing partners

Need for staff augmentation vs. managed services

You can choose staff augmentation if the requirement is short term and the tasks are well defined. In the case of a long term project, it is best to opt for managed services. Managed services suit best if the project requires ongoing support and skill sets that are not available with the business but are vital for the product or project. It also fits well for long term projects that have a clear understanding of outputs and outcomes.

Agility of the vendor’s testing practices

Agile/DevOps methodologies now drive a healthy percentage of software development and testing. Can the vendor maintain velocity in an Agile/DevOps environment? Do they have the processes to integrate into cross-functional, distributed teams to ensure continuous integration, development, testing, and deployment?

Relevant experience working for your industry

Relevant industry experience ensures that the testers involved know about your business domain. Industry knowledge not only increases efficiency but also guides testers to prioritize testing with the highest level of business impact.

Tools, frameworks, and technologies that the vendor offers

Understand the expertise of the vendor in terms of the tools, frameworks, and technologies. What is their approach to automation? Do they use/recommend licensed or open source tools? These are some considerations that can guide your evaluation.

Offshoring – Onshoring – Bestshoring

Many vendors recommend offshoring processes to reap benefits from cost savings. But does offshoring translate to an equally beneficial proposition for you? While you can best ascertain the applicability and benefits of offshoring, it is advisable to go for a mix of the three. In a managed services engagement, right shoring (a mix of onsite & offshore), ensures that the coordination aspects are dealt with by the vendor.

Reputation in the market

Ascertaining the reputation of the vendor in the market can be another useful way of evaluation. Reading independent reviews about the organization, understanding the longevity of their existing engagements (Customer stickiness), references from businesses that have engaged with the vendor earlier, number of years the organization has been in business are some of the factors that can be applied.

Culture within the organization

The culture of your potential partner must be broadly aligned with your organizational culture. The vendor should identify with your culture, be quick to adapt, be ethical, and gel well with the existing team. The culture within the vendor organization is also crucial to ensure that the employees are respectful of their commitments and stay accountable for assigned responsibilities.

Low-cost vs. high-quality output

Engaging with people who have the experience in the required domain and technology, working on a customized delivery model, within stipulated timelines, come for a premium. But are more likely to deliver value compared to a low-cost fragmented solution with inexperienced manpower, little or zero knowledge on domain-specific skills and technology, and an unsure commitment to timely delivery.

Do you know of other factors that influence decision making in terms of identifying the right outsourcing partner? Please share your thoughts.