QA in Cloud Environment – Key Aspects that Mandate a Shift in the QA Approach

Cloud computing is now the foundation for digital transformation. Starting as a technology disruptor a few years back, it has become the de facto approach for technology transformation initiatives. However, many organizations still struggle to optimize cloud adoption. Reasons abound – ranging from lack of a cohesive cloud strategy to mindset challenges in adopting cloud platforms. Irrespective of the reason, assuring the quality of applications in cloud environments remains a prominent cause for concern.

Studies indicate a wastage of $17.6 billion in cloud spend in 2020 due to multiple factors like idle resources, overprovisioning, and orphaned volumes and snapshots (Source parkmycloud.com). Further, some studies have pegged the cost of software bugs to be 1.1 trillion dollars. Assuring the quality of any application hosted on the cloud not only addresses its functional validation but also its performance-related aspects like load testing, stress testing, capacity planning, etc invariably addressing both the issues described above, thereby exponentially reducing the quantum of loss incurred on account of poor quality.

The complication for QA in cloud-based application arises due to many deployment models ranging from private cloud, public cloud to hybrid cloud, and application service models ranging from IaaS, PaaS, to SaaS. While looking at deployment models, testers will need to address infrastructure aspects and application quality. At the same time, while paying attention to service models, QA will need to focus on the team’s responsibilities regarding what they own, manage, and delegate.

Key aspects that mandate a shift in the QA approach in cloud-based environments are –

Application architecture

Earlier and to some extent even now, when it comes to legacy applications, QA primarily deals with a monolithic architecture. The onus was on understanding the functionality of the application and each component that made up the application, i.e., QA was not just black-box testing. The emergence of the cloud brought with it a shift to microservices architecture, which completely changed testing rules.

Multiple scrum teams work on various application components or modules deployed in containers and connected through APIs in a microservices-based application. The containers have a communication mechanism based on contracts. QA methodology for cloud-based applications is very different from that adopted for monolith applications and therefore requires detailed understanding.

Security, compliance, and privacy

In typical multi-cloud and hybrid cloud environments, the application is hosted in a 3rd party environment or multiple 3rd party environments. Such environments can also be geographically distributed, with data centers housing the information residing in numerous countries. Regulations that restrict data movement outside countries, service models that call for multi-region deployment, and corresponding data storage and access without impinging on regulatory norms need to be understood by QA personnel.QA practitioners also need to be aware of the data privacy rules existing across regions.

The rise of the cloud has given way to a wide range of cybersecurity issues – techniques for intercepting data and hacking sensitive data. To overcome these, QA teams need to focus on vulnerabilities of the application under test, networks, integration to the ecosystem, and third-party software deployed for complete functionality. Usage of tools to simulate Man In The Middle (MITM) attacks helps QA teams identify and overcome any sources of vulnerability through countermeasures.

Building action-oriented QA dashboards need to extend beyond depicting quality aspects to addressing security, infrastructure, compliance, and privacy.

Scalability and distributed ownership

Monolithic architectures depend on vertical scaling to address increased application loads, while in a cloud setup, this is more horizontal in nature. Needless to say that in a cloud-based architecture, there is no limitation to application scaling. Performance testing in a cloud architecture need not consider aspects like breakpoint testing since they can scale indefinitely.

With SaaS-based models, the QA team needs to be mindful that the organization may own some components that require testing. Other components that require testing may be outsourced to other providers, and some of these providers may include cloud providers. The combination of on-premise components and others on the cloud by the SaaS provider makes QA complicated.

Reliability and Stability

This entirely depends on the needs of the organization. An Amazon that deploys 100,000 times a day – features and updates of its application hosted in cloud vis-a-vis an aircraft manufacturer that ensures the complete update of its application before its aircraft is in the air, have diverse requirements for reliability stability. Ideally, testing done for reliability should uncover four categories – what we are aware of and understand, what we are aware of but do not understand, what we understand but are not aware of, and what we neither understand nor are we aware of.

Initiatives like chaos testing aim to uncover these streams by randomly introducing failures through automated testing and scripting and seeing how the application reacts/sustains in this scenario.

QA needs to address the below in a hybrid cloud setup are –

  • What to do when one cloud provider goes down
  • How can the load be managed
  • What happens to disaster recovery sites
  • How does it react when downtime happens
  • How to ensure high availability of application

Changes in organization structure

Cloud-based architecture calls for development through pizza teams, smaller teams fed by one or two pizzas, in common parlance. These micro product teams have testing embedded in them, translating into a shift from QA to Quality Engineering (QE). The tester in the team is responsible for engineering quality by building automation scripts earlier in the cycle, managing performance testing strategies, and understanding how things get impacted in a cloud setup. Further, there is also increased adoption of collaboration through virtual teams, leading to a reduction in cross-functional QA teams.

Tool and platform landscape

A rapidly evolving tool landscape is the final hurdle that the QA practitioner must overcome to test a cloud-based application. The challenge becomes orchestrating superior testing strategies by using the right tools and the correct version of tools. Quick learning ability to keep up with this landscape is paramount. An open mindset to adopt the right toolset for the application is needed rather than an approach steeped with blinders towards toolsets prevailing in the organization.

In conclusion, the QA or QE team behaves like an extension of customer organization since it owns the mandate for ensuring the launch of quality products to market. The response times in a cloud-based environment are highly demanding since the launch time for product releases keeps shrinking on account of demands from end customers and competition. QA strategies for cloud-based environments need to keep pace with the rapid evolution and shift in the development mindset.

Further, the periodicity of application updates has also radically changed, from a 6-month upgrade in a monolith application to feature releases that happen daily, if not hourly. This shrinking periodicity translates into an exponential increase in the frequency of test cycles, leading to a shift-left strategy and testing done in earlier stages of the development lifecycle for QA optimization. Upskilling is also now a mandate given that the tester needs to know APIs, containers, and testing strategies that apply to contract-based components compared to pure functionality-based testing techniques.

Wish to know more? Feel free to reach out to us.

Embrace inclusivity with digital accessibility

Why digital accessibility is important today

In today’s world, embracing inclusivity with accessibility is not only about being humane or legally correct but also makes a lot of business sense. Recent studies have shown that businesses can tap into an additional prospective user base of up to 15% to market their products. Persons with disabilities (PWD) are responsible for 25% of all healthcare spending in the U.S.

Businesses have increasingly become aware of the requirements of people who need accessible technologies to contribute to a work environment or who can also be prospective customers.

At Barclays, accessibility is about more than just disability. It’s about helping everyone to work, bank and live their lives regardless of their age, situation, abilities, or circumstances. – Paul Smyth, Head of Digital Accessibility, Barclays

What is digital accessibility?

The Web Accessibility Initiative (WAI) states that websites, tools, and technologies should be designed and developed so that even differently-abled people can use them. More specifically, these people should be able to perceive, understand, navigate, and interact with the Web and contribute to the Web.

Web Accessibility enables people with disabilities to participate equally on the Web. Broadly speaking, Web accessibility encompasses all disabilities that affect access to the Web, including:

  • Auditory
  • Cognitive
  • Neurological
  • Physical
  • Speech
  • Visual

When an organization removes barriers by making its application accessible to its full potential, it will be an inclusive product, as millions of people with various disabilities can use it.

Mandated by Law – American with Disabilities Act (ADA)

One hears the terms “Section 508”, an amendment to the Workforce Rehabilitation Act of 1973 that requires that all Information Technology assets of the United States’ federal government be accessible by people with disabilities.

Also, ADA (American with Disabilities Act) the Title III requires that all private businesses that are open to the public be accessible to people with disabilities. There is a steady rise in the number of lawsuits filed over the years under this section, resulting from the growing awareness of the ADA Title III. Digital accessibility compliance helps organizations protect themselves against this rising trend of ADA Title III Federal lawsuits.

Foundation for accessibility

The web accessibility guidelines, technical specifications, and educational resources to help make the web accessible to people with disabilities are developed by Web Accessibility Initiative (WAI). They are an integral part of the W3C (World Wide Web Consortium), focusing on accessibility. Over time, the WAI has developed several recommendations, some of which are:

The latest edition of Web Content Accessibility Guidelines (WCAG) 2.1 has additional coverage for mobile and non-W3C technologies (non-web documents and software).

Four principles of accessibility

The WCAG guidelines lay down the four principles which are the foundation for Web accessibility: Perceivable, Operable, Understandable, and Robust (POUR for short).

Perceivable: The objective is to make content available to the senses, primarily vision, and hearing, via either the browser or through assistive technologies like screen readers, screen enlargers, etc. For the visually impaired who mainly rely on a screen reader to have the website’s content read, one needs to add an alternative text that provides a textual alternative to non-text content in web pages that makes the content perceivable. Another example is videos and live audio must have captions and a transcript. With archived audio, a transcription may be enough.

In this video example: Perceivable, the video page uses “voice recognition” and is also updated to use “speech recognition.” “Voice recognition” or “speaker recognition” is a technology that identifies who the speaker is, not the words they’re saying. “Speech recognition” is about recognizing words for speech-to-text (STT) transcription, virtual assistants, and other speech user interfaces. Together they allow a person with visual impairment to enhance their experience of the web.

Operable: The objective is to enable a user to interact with all controls and interactive elements using either the mouse, keyboard, or an assistive device. Most people will get frustrated by the inability to use a computer because of a malfunctioning mouse. Many people prefer to use only the keyboard to navigate websites. Whatever be the reason, either personal preference or circumstance like temporarily limited mobility, a permanent physical disability, or simply a broken mouse, the result is the same: Websites and apps need to be operable by a keyboard. For example, all links and controls on the web page must be accessible using the Tab key on the keyboard.

In addition, Operable principles allow users enough time to use and interact with the content. It also helps them navigate and find content. For example, if all rich, interactive features of the web page like dropdown menus, carousels, modal dialogs, etc., comply with the W3C’s WAI-ARIA 1.0 Authoring Practices recommendations, will ensure that users can easily navigate to the right content.

Understandable: The objective is to ensure that every functionality of web content is easily understandable. A user must be able to understand all navigation and other forms of interaction. To provide a user the best possible experience, every point of interaction deserves careful attention. Navigation should be consistent and predictable throughout the context of the website. Interactive elements like form controls should also be predictable and clearly labeled. For example, Instead of saying: “To postulate a conceit more irksome than being addressed in sesquipedalian syntax is adamantine,” it is better to say: “Being spoken to in unnecessarily long and complicated language is a pain.”

Despite knowing these basics, many websites lack structuring using headings, lists, and separations. Some even use overly complex language, jargon, and unexplained acronyms. It makes these websites difficult and unappealing for many people, including non-native speakers and makes them unusable for people with cognitive and learning disabilities.

Robust: People get familiar and comfortable with different technologies like operating systems, browsers, and versions of browsers with usage and time. Some people like advanced features, whereas many disable them. There are early adopters of new technologies while others are slow to adapt to the rapidly-changing currents in the flow of technological advances.

A User should have the freedom to choose their technologies to access web content. This allows the user to customize the technology to meet his needs, including accessibility needs. In some cases, it might take additional time and effort to develop web content, depending on the specifications of the technologies used. However, in the long run, it will produce more reliable results and increase the chances that the content is accessible to people with disabilities.

You might have experienced the frustration of being told your technology is out of date or no longer supported. Whilst frustrating, you’ve probably found a way around the issue – but what if you couldn’t because you rely on that technology to interact with the digital world.

Beyond the four principles

Web Content Accessibility Guidelines 2.1 are organized into three levels of conformance:

Level A – addresses the most basic features of web accessibility features.
Level AA – deals with the most common and biggest barriers for disabled users and is covered in most accessibility regulations globally, including the ADA.
Level AAA – the highest level of web accessibility will make the software or product accessible to the maximum number of users. However, these requirements are not entirely easy to conform to and can be focused on if your audience is primarily people with disabilities.

These levels are across all of the previously mentioned principles. Some of the key requirements include:

Google Aces Accessibility

Google’s investment in accessibility provides the company with an innovation edge in a broad array of products and services. Some of the innovations are:

  • Contrast minimums: a feature designed especially for people with low vision, and the feature also helps everyone see in bright light glare situations.
  • Auto-complete: initially designed for people with disabilities, now used widely by all users.
  • Voice control: although initially implemented for users with physical impairments is now widely adopted by millions of users for the convenience it provides
  • Artificial intelligence: originally integrated to provide visual context to users with visual impairments
  • Auto-captioning leveraging machine learning designed mainly for deaf users did not see many adopters in that target audience, as many feel it is still inadequate to meet their needs. However, advances in machine learning itself have found broader applications.

Get started with your accessibility program

Trigent’s Accessibility Assurance and Compliance Service can help you at the design stage itself with Design reviews and Gap analysis or later to assess compliance to WCAG 2.1 guidelines.

Wish to know more? Feel free to reach out to us

Fundamentals of testing microservices architecture

Increased adoption of digital has pushed the need for speed to the forefront. The need to conceptualize, develop, launch new products and iterate to make them better, much ahead of the competition and gain customer mindshare, has become the critical driver of growth. Adoption of agile principles or movement towards scrum teams for increased agility are all steps in this direction. Disruptive changes have also taken place on the application front with the 3-tier architecture of the late 90s and subsequent 2 tier monolithic architecture giving way to one that is based on microservices.

Having a single codebase made a monolithic architecture less risky but slow to adopt changes, the exact opposite of a services-based architecture. Microservices architecture makes it easier for multiple development teams to make changes to the codebase in parallel. By transforming an application into a distributed set of services that are highly independent, yet interdependent, provides the ability to create new services/functionalities and modify services without impacting the overall application. These changes can be achieved by teams cutting across geographies or locations and makes it easier for them to understand functional modules rather than the humongous application codebase. However, the highly distributed nature of services also gives them a heightened ability to fail.

Breaking it down

At the core, a microservices architecture comprises of 3 layers – a REST layer that allows the service to expose APIs, the database layer, and the service layer. A robust testing strategy needs to cover all these layers and ensure that issues are not leaked to production. The further an issue moves across stages, the impact increases on account of multiple teams getting affected. Hence the test plan must cover multiple types of testing like service testing, subsystem testing, client acceptance testing, performance testing, etc. Subsequent paragraphs outline key aspects of service level testing and integration testing in a microservices architecture-based application landscape.

In service level testing, each service forming a part of the application architecture needs to be validated. Each service has dependencies on other services and transmits information to others based on need. In a monolith architecture, since connections are being established from one class to the other within the same Java Virtual machine (JVM), chances of failure are far lower. However, in a services architecture, these are distributed, driving the need for network calls to access other services and makes it more complex.

Functional Validation: The primary goal in services testing is the functionality validation of a service. Key to this is the need to understand all events the service handles through both internal as well as external APIs. At times this calls for simulating certain events to ensure that they are being handled properly by the service. Collaboration with the development team is key to understand incoming events being handled by the service as part of its functionality. A key element of functional validation – API contract testing, tests the request and response payload along with a host of areas like pagination and sorting behaviors, metadata, etc.

Compatibility: Another important aspect is recognizing and negating backward compatibility issues. This happens during the launch of a changed version of the service that breaks existing clients running in production. Changes that happen to API contracts need to be evaluated in detail to understand if they are mandatory and capable of breaking clients in production. An addition of a new attribute or a parameter may not classify as a breaking change; however, changes to response payload, behavior, error codes, or datatypes have the ability to break. A change in value typically changes the logic behind it as well. They need to be uncovered much earlier in the service testing lifecycle.

Dependencies: Another aspect of focus is external dependencies, where one would test both incoming as well as outgoing API calls. Since these are heavily dependent on the availability of other services and hence other teams, there is a strong need to obviate dependency through the usage of mocks. Having conversations with developers and getting them to insert mocks while creating individual services will enable testing dependencies without waiting for the service to be available. It is imperative to make sure the mocks are easily configurable without needing access to the codebase. Usage of mocks also drives ease in automation giving teams the ability to run independently with no configuration.

Bringing it all together

Once each service is tested for its functionality, the next step is to move onto validate how the various collaborating services work together end to end. Known as subsystem testing or integration testing, it tests the whole functionality exposed together. Understanding the architecture or application blueprint by discussions with the development team is paramount in this stage. Further, there is a strong need to use real services deployed in the integration environment rather than mocks used for external dependencies.

As part of integration testing, there is a need to validate if the services are wired very closely and talking to each other. The event stream and inter-service API calls need to be configured properly so inter-service communication channels are proper. If the service functionality level testing is proper, the chances of finding errors are minimal in this stage, since the required mocks created in the functionality testing stage would have ensured that the services function properly.

Looking in-depth, we find that the testing strategies for microservices are not extremely different from those adopted for a monolith application architecture. The fundamental difference comes in the way the interdependencies and communication between multiple services forming a part of the larger application are tested to ensure that the application as a whole function in line with expectations.

The Best Test Data Management Practices in an Increasingly Digital World

A quick scan of the application landscape shows that customers are more empowered, digitally savvy, and eager to have superior experiences faster. To achieve and maintain leadership in this landscape, organizations need to update applications constantly and at speed. This is why dependency on agile, DevOps, and CI/CD technologies has increased tremendously, further translating to an exponential increase in the adoption of test data management initiatives. CI/CD pipelines benefit from the fact that any new code that is developed is automatically integrated into the main application and tested continuously. Automated tests are critical to success, and agility is lost when test data delivery does not match code development and integration velocity.

Why Test Data Management?

Industry data shows that up to 60% of development and testing time is consumed by data-related activities, with a significant portion dedicated to testing data management. This amply validates that the global test data management market is expected to grow at a CAGR of 11.5% over the forecast period 2020-2025, according to the ResearchandMarkets TDM report.

Best Practices for Test Data Management

Any organization focusing on making its test data management discipline stronger and capable of supporting the new age digital delivery landscape needs to focus on the following three cornerstones.

Applicability:
The principle of shift left mandates that each phase in an SDLC has a tight feedback loop that ensures defects don’t move down the development/deployment pipeline, making it less costly for errors to be detected and rectified. Its success hinges to a large extent on close mapping of test data to the production environment. Replicating or cloning production data is manually intensive, and as the World Quality Report 2020-21 shows, 79% of respondents create test data manually with each run. Scripts and automation tools can take up most heavy lifting and bring this down to a large extent when done well. With production quality data being very close to reality, defect leakage is reduced vastly, ultimately translating to a significant reduction in defect triage cost at later stages of development/deployment.

However, using production-quality data at all times may not be possible, especially in the case of applications that are only a prototype or built from scratch. Additionally, using a complete copy of the production database is time and effort-intensive – instead, it is worthwhile to identify relevant subsets for testing. A strategy that brings together the right mix of product quality data and synthetic data closely aligned to production data models is the best bet. While production data maps to narrower testing outcomes in realistic environments, synthetic data is much broader and enables you to simulate environments beyond the ambit of production data. Usage of test data automation platforms that allocates apt dataset combinations for tests can bring further stability to testing.

Tight coupling with production data is also complicated by a host of data privacy laws like GDPR, CCPA, CPPA, etc., that mandate protecting customer-sensitive information. Anonymizing data or obfuscating data to remove sensitive information is an approach that is followed to circumvent this issue. Usually, non-production environments are less secure, and data masking for protecting PII information becomes paramount.

Accuracy:
Accuracy is critical in today’s digital transformation-led SDLC, where app updates are being launched to market faster and need to be as error-free as possible, a nearly impossible feat without accurate test data. The technology landscape is also more complex and integrated like never before, percolating the complexity of data model relationships and the environments in which they are used. The need is to maintain a single source of data truth. Many organizations adopt the path of creating a gold master for data and then make data subsets based on the need of the application. Adopting tools that validate and update data automatically during each test run further ensures the accuracy of the master data.

Accuracy also entails ensuring the relevance of data in the context of the application being tested. Decade-old data formats might be applicable in the context of an insurance application that needs historic policy data formats. However, demographic data or data related to customer purchasing behavior applicable in a retail application context is highly dynamic. The centralized data governance structure addresses this issue, at times sunsetting the data that has served its purpose, preventing any unintended usage. This also reduces maintenance costs for archiving large amounts of test data.

Also important is a proper data governance mechanism that provides the right provisioning capability and ownership driven at a central level, thereby helping teams use a single data truth for testing. Adopting similar provisioning techniques can further remove any cross-team constraints and ensure accurate data is available on demand.

Availability:
The rapid adoption of digital platforms and application movement into cloud environments have been driving exponential growth in user-generated data and cloud data traffic. The pandemic has accelerated this trend by moving the majority of application usage online. ResearchandMarkets report states that for every terabyte of data growth in production, ten terabytes are used for development, testing, and other non-production use cases, thereby driving up costs. Given this magnitude of test data usage, it is essential to align data availability with the release schedules of the application so that testers don’t need to spend a lot of time tweaking data for every code release.

The other most crucial thing in ensuring data availability is to manage version control of the data, helping to overcome the confusion caused by conflicting and multiple versioned local databases/datasets. The centrally managed test data team will help ensure single data truth and provide subsets of data as applicable to various subsystems or based on the need of the application under test. The central data repository also needs to be an ever-changing, learning one since the APIs and interfaces of the application keeps evolving, driving the need for updating test data consistently. After every test, the quality of data can be evaluated and updated in the central repository making it more accurate. This further drives reusability of data across a plethora of similar test scenarios.

The importance of choosing the right test data management tools

In DevOps and CI/CD environments, accurate test data at high velocity is an additional critical dimension in ensuring continuous integration and deployment. Choosing the right test data management framework and tool suite helps automate various stages in making data test ready through data generation, masking, scripting, provisioning, and cloning. World quality report 2020-21 indicates that the adoption of cloud and tool stacks for TDM has witnessed an increase, but there is a need for more maturity to make effective use.

In summary, for test data management, like many other disciplines, there is no one size fits all approach. An optimum mix of production mapped data, and synthetic data, created and housed in a repository managed at a central level is an excellent way to go. However, this approach, primarily while focusing on synthetic data generation, comes with its own set of challenges, including the need to have strong domain and database expertise. Organizations have also been taking TDM to the next level by deploying AI and ML techniques, which scan through data sets at the central repository and suggest the most practical applications for a particular application under test.

Need help? Partner with experts from Trigent to get a customized test data management solution and be a leader in the new-age digital delivery landscape.

4 Rs for Scaling Outsourced QA. The first steps towards a rewarding engagement

Expanding nature of products, need for faster releases to market much ahead of competition, knee jerk or ad hoc reactions to newer revenue streams with products, ever increasing role of customer experience across newer channels of interaction, are all driving the need to scale up development and testing. With the increased adoption of DevOps, the need to scale takes a different color altogether.

Outsourcing QA has become the norm on account of its ability to address the scalability of testing initiatives and bring in a sharper focus on outcome-based engagements. The World Quality Report 2020 mentions that 34% of respondents felt QA teams lack skills especially on the AI/ML front. This further reinforces their need to outsource for getting the right mix of skill sets so as to avoid any temporary skill set gaps.

However, ensuring that your outsourced QA gives you speed and scale can be a reality only if the rules of engagement with the partner are clear. Focusing on 4 R’s as outlined below while embarking on the outsourcing journey, will help you derive maximum value.

  1. Right Partner
  2. Right Process
  3. Right Communication
  4. Right Outcome

Right Partner

The foremost step is to identify the right partner, one with a stable track record, depth in QA, domain as well as technology, and the right mix of skill sets across toolsets and frameworks. Further, given the blurring lines between QA and development with testing being integrated across the SDLC, there is a strong need for the partner to have strengths across DevOps, CI/CD in order to make a tangible impact on the delivery cycle.

The ability of the partner to bring to table prebuilt accelerators can go a long way in achieving cost, time and efficiency benefits. The stability or track record of the partner translates to the ability to bring onboard the right team which stays committed throughout the duration of the engagement. The team’s staying power assumes special significance in longer duration engagements wherein shifts in critical talent derails efficiency and timelines on account of challenges involved with newer talent onboarding and effective knowledge transfer.

An often overlooked area is the partner’s integrity. During the evaluation stages, claims pertaining to industry depth as well as technical expertise abound and partners tend to overpromise. Due care needs to be exercised to know if their recommendations are grounded in delivery experience. Closer look at the partner’s references and past engagements not only help to gain insight into their claims but also help to evaluate their ability to deliver in your context.

It’s also worthwhile to explore if the partner is open to differentiated commercial models that are more outcome driven and based on your needs rather than being fixated on the traditional T&M model.

Right Process

With the right partner on board, creating a robust process and governing mechanism assumes tremendous significance. Mapping key touchpoints from the partner side, aligning them to your team, and identifying escalation points serve as a good starting point. With agile and DevOps principles having collaboration across teams as the cornerstone, development, QA, and business stakeholder interactions should form a key component of the process. While cross-functional teams with Dev QA competencies start off each sprint with a planning meeting, formulating cadence calls to assess progress and setting up code drop or hand off criteria between Dev and QA can prevent Agile engagements from degrading into mini waterfall models.

Bringing in automated CI/CD pipelines obviates the need for handoffs substantially. Processes then need to track and manage areas such as quality and release readiness, visibility across all stages of the pipeline through reporting of essential KPIs, documentation for managing version control, resource management, and capacity planning. At times, toolset disparity between various stages and multiple teams driving parallel work streams creates numerous information silos leading to fragmented visibility at the product level. The right process should focus on integration aspects as well to bridge these gaps. Each team needs to be aware and given visibility on ownership at each stage of the pipeline.

Further, a sound process also brings in elements of risk mitigation and impact assessment and ensures adequate controls are built into SOP documents to circumvent any unforeseen event. Security measures is another critical area that needs to be incorporated into the process early on, more often it is an afterthought in the DevOps process. Puppet 2020 State of DevOps report mentions that integrating security fully into the software delivery process can quickly remediate critical vulnerabilities – 45% of organizations with this capability can remediate vulnerabilities within a day.

Right Communication

Clear and effective communication is an integral component of QA, more so when DevOps, Agile, and similar collaboration-heavy initiatives are pursued achieving QA at scale. Effective communication at the beginning of the sprint ensures that cross-functional teams are cognizant of the expectations from each of them and have their eye firmly fixed on the end goal of application release. From then on, a robust feedback loop, one that aims at continuous feedback and response, cutting across all stages of the value chain, plays a vital role in maintaining the health of the DevOps pipeline.

While regular stand-up meetings have their own place in DevOps, effective communication needs to go much beyond to focus on tools, insights across each stage, and collaboration. A wide range of messaging apps like Slack, email, and notification tools accelerate inter-team communication. Many of these toolkits are further integrated with RSS feeds, google drive, and various CI tools like Jenkins, Travis, Bamboo, etc. making build pushes and code change notifications fully automated. Developers need notifications when a build fails, testers need them when a build succeeds and Ops need to be notified at various stages depending on the release workflow.

The toolkits adopted by the partner also need to extend communication to your team. At times, it makes sense for the partner to have customer service and help desk support as an independent channel to accept your concern. The Puppet report further mentions that companies at a high level of DevOps maturity use ticketing systems 16% more than what is used by companies at the lower end of the maturity scale. Communication of the project’s progress and evolution to all concerned stakeholders is integral irrespective of the platforms used. Equally important is the need to categorize communication in terms of priority and based on what is most applicable to classes of users.

Documentation is an important component of communication and from our experiences, commonly underplayed. It is important for sharing work, knowledge transfer, continuous learning and experimentation. Code that is well documented enables faster completion of audit as well. In CI/CD based software release methodology, code documentation plays a strong role in version control across multiple releases. Experts advocate continuous documentation as core communication practice.

Right Outcome

Finally, it goes without saying that setting parameters for measuring the outcome, tracking and monitoring those, determines the success of the partner in scaling your QA initiatives. Metrics like velocity, reliability, reduced application release cycles and ability to ramp up/ramp down are commonly used. Further, there are also a set of metrics aimed at the efficiency of the CI/CD pipeline, like environment provisioning time, features deployment rate, and a series of build, integration, and deployment metrics. However, it is imperative to supplement these with others that are more aligned to customer-centricity – delivering user-ready software faster with minimal errors at scale.

In addition to the metrics that are used to measure and improve various stages of the CI/CD pipeline, we also need to track several non-negotiable improvement measures. Many of these like deployment frequency, error rates at increased load, performance & load balancing, automation coverage of delivery process and recoverability helps to ascertain the efficiency of QA scale up.

Closely following on the heels of an earlier point, an outcome based model which maps financials to your engagement objectives will help to track outcomes to a large extent. While the traditional T&M model is governed by transactional metrics, project overlays abound in cases where engagement scope does not align well to outcome expectations. An outcome based model also pushes the partner to bring in innovation through AI/ML and similar new age technology drivers – providing you access to such skill sets without the need for having them on your rolls.

If you are new to outsourcing, or working with a new partner, it may be good to start with a non-critical aspect of the work (for regular testing or automation), establish the process and then scale the engagement. For those players having maturity in terms of adopting outsourced QA functions in some way or the other, the steps outlined earlier form an all inclusive checklist to ensure maximization of engagement traction and effectiveness with the outsourcing partner.

Partner with us

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.

Trigent is an early pioneer in IT outsourcing and offshore software development business. We enable organizations to adopt digital processes and customer engagement models to achieve outstanding results and end-user experience. We help clients achieve this through enterprise-wide digital transformation, modernization, and optimization of their IT environment. Our decades of experience, deep domain knowledge, and technology expertise delivers transformational solutions to ISVs, enterprises, and SMBs.

Contact us now.

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.

Poor application performance can be fatal for your enterprise, avoid app degradation with application performance testing

If you’ve ever wondered what can possibly go wrong’ after creating a foolproof app, think again. Democrats’ Iowa Caucus voting app is a case in point. The Iowa caucus post-mortem pointed towards a flawed software development process and insufficient testing.

The enterprise software market is predicted to touch US$230,134.0m in 2021, and the revenue is expected to grow with a CAGR of 9.1% leading to a market volume of US$326,285.5m by 2025. It is important that enterprises aggressively work towards getting their application performance testing efforts on track to ensure that all the individual components that go into the making of the app provide superior responses to ensure a better customer experience.

Banking app outages have also been pretty rampant in recent times putting the spotlight on the importance of application performance testing. Customers of Barclays, Santander, and HSBC suffered immensely when their mobile apps suddenly went down. It’s not as if banks worldwide are not digitally equipped. They dedicate at least 2-3 percent of their revenue to information technology along with additional expenses on building a superior IT infrastructure. What they also need is early and continuous performance testing to address and minimize the occurrence of such issues.

It is important that the application performs well not just when it goes live but later too. We give you a quick lowdown on application performance testing to help you gear up to meet modern-day challenges.

Application performance testing objectives

In general, users today, have little or no tolerance for bugs or poor response times. A faulty code can also lead to serious bottlenecks that can eventually lead to slowdown or downtime. Meanwhile, bottlenecks can arise from CPU utilization, disk usage, operating system limitations, or hardware issues.

Enterprises, therefore, need to conduct performance testing regularly to:

  • Ensure the app performs as expected
  • Identify and eliminate bottlenecks through continuous monitoring
  • Identify & eliminate limitations imposed by certain components
  • Identify and act on the causes of poor performance
  • Minimize implementation risks

Application performance testing parameters

Performance testing is based on various parameters that include load, stress, spike, endurance, volume, and scalability. Resilient apps can withstand increasing workloads, high volumes of data, and sudden or repetitive spikes in users and/or transactions.

As such, performance testing ensures that the app is designed keeping peak operations in mind and all components comprising the app function as a cohesive unit to meet consumer requirements.
No matter how complex the app is, performance testing teams are often required to take the following steps:

  • Setting the performance criteria – Performance benchmarks need to be set and criteria should be identified in order to decide the course of the testing.
  • Adopting a user-centric approach – Every user is different and it is always a good idea to simulate a variety of end-users to imagine diverse scenarios and test for use cases accordingly. You would therefore need to factor in expected usage patterns, the peak times, length of an average session within the application, how many times do users use the application in a day, what is the most commonly used screen for the app, etc.
  • Evaluating the testing environment – It is important to understand the production environment, the tools available for testing, and the hardware, software, and configurations to be used before beginning the testing process. This helps us understand the challenges and plan accordingly.
  • Monitoring for the best user experience – Constant monitoring is an important step in application performance testing. It will give you answers to what, when, and why’ helping you fine-tune the performance of the application. How long does it take for the app to load, how does the latest deployment compare to previous ones, how well does the app perform while backend performances occur, etc. are things you need to assess. It is important that you leverage your performance scripts well with proper correlations, and monitor performance baselines for your database to ensure it can manage fresh data loads without diluting the user experience.
  • Re-engineering and re-testing – The tests can be rerun as required to review and analyze results, and fine-tune again if necessary.

Early Performance Testing

Test early. Why wait for users to complain when you can proactively run tests early in the development lifecycle to check for application readiness and performance? In the current (micro) service-oriented architecture approach, as soon as the component or an interface is built, performance testing at a smaller scale can allow us to uncover issues w.r.t concurrency, response time/latency, SLA, etc. This will allow us to identify bottlenecks early and gain confidence in the product as it is being built.

Performance testing best practices

For the app to perform optimally, you must adopt testing practices that can alleviate performance issues across all stages of the app cycle.

Our top recommendations are as follows:

  • Build a comprehensive performance model – Understand your system’s capacity to be ready for concurrent users, simultaneous requests, response times, system scalability, and user satisfaction. The app load time, for instance, is a critical metric irrespective of the industry you belong to. Mobile app load times can hugely impact consumer choices as highlighted in a study by Akamai which suggested conversion rates reduce by half and bounce rate increases by 6% if a mobile site load time goes up from 1 second to 3. It is therefore important that you factor in the changing needs of customers to build trust, loyalty, and offer a smooth user experience.
  • Update your test suite – The pace of technology is such that new development tools will debut all the time. It is therefore important for application performance testing teams to ensure they sharpen their skills often and are equipped with the latest testing tools and methodologies.

An application may boast of incredible functionality, but without the right application architecture, it won’t impress much. Some of the best brands have suffered heavily due to poor application performance. While Google lost about $2.3 million due to the massive outage that occurred in December 2020, AWS suffered a major outage after Amazon added a small amount of capacity to its Kinesis servers.

So, the next time you decide to put your application performance testing efforts on the back burner, you might as well ask yourself ‘what would be the cost of failure’?

Tide over application performance challenges with Trigent

With decades of experience and a bunch of the finest testing tools, our teams are equipped to help you across the gamut of application performance right from testing to engineering. We test apps for reliability, scalability, and performance while monitoring them continuously with real-time data and analytics.

Allow us to help you lead in the world of apps. Request a demo now.

Bandwidth testing for superior user experience – here’s how?

The bandwidth Testing process simulates a low internet bandwidth connection and checks how your application behaves under desired network speed.

Considering a scenario where a specific application’s home page always loads in milliseconds in office premises this may not be the case when an end-user with low network speed accesses the application. To enhance user experience and get to know the application load times at specific network bandwidth speeds, we can simulate it and identify specific component/service call which is taking more time and can be improved further.

Prerequisites:

Bandwidth testing using Chrome browser. You should set your ‘Network’ panel in the chrome browser as per the below requirements.

Setup:

  1. Go to Customize and control Google Chrome at the top right corner and click More tools, then select Developer tools
    • Or press keyboard shortcut Ctrl + Shift + I
    • Or press F12
  2. Then click the ‘No throttling’ dropdown and choose Add… option under the Custom section.
  3. Click Add custom profile
  4. You will need to enter profile name in order to click on Add button. For example, ‘TestApp 1 MBPS’.
  5. Fill in the Download, Upload, Latency columns as below and click Add.

Example for 100Kbps:

Download (kb/s)Upload (kb/s)Latency (ms)
10050300

Example for 1Mbps:

Download (kb/s) Upload (kb/s)Latency (ms)
102451250

Example for 2.5Mbps:

Download (kb/s)Upload (kb/s)Latency (ms)
2600150030

Configuring Chrome is a one-time affair. Once Chrome has been configured for bandwidth testing, use the same settings by selecting the profile name [TestApp 1 MBPS] from the No Throttling drop-down.

Metrics to be collected for bandwidth testing:

  • Data transferred (KB)
  • Time taken for data transfer (seconds)

Using Record network activity option in the Chrome browser, you can get the above attributes.

Note: Toggle button “Record network log”/”Stop recording network log” and button “Clear” are available in the network panel.

It is best practice to close all the non-testing applications/tools in the system and other tabs from Chrome where the testing is performed.

Steps for recording network activity:

  1. Open Developer Tools and select the Network tab.
  2. Clear network log before testing.
  3. Make sure Disable cache checkbox is checked.
  4. Select the created network throttling profile (say ‘TestApp 1 MBPS’).
  5. Start recording for the steps to be measured as per the scenario file.
  6. Wait for the completion of step and page is fully loaded to check the results
  7. Data transferred size for each recorded step will be displayed down in the status bar as highlighted. The size will be in byte/kilobyte/megabyte. Make note of it.
  8. Time taken for data transfer will be displayed in the timeline graph. The horizontal axis represents the time scale in a millisecond. Take the
  9. Maximum time. Take approximate value from the graph and make note of it.

Here is the sample screenshot taken for login process of snapdeal application page in which specific js component (base.jquery111.min.js) loading took 4.40s and also while searching for any product searchResult.min.js took 4.08s which can be improved further for better user experience.

This Bandwidth Testing Process helps in every possible way to improve user experience by identifying specific component or API calls which are taking more time to load and it helps developers to fix those specific components.

Your application’s performance is a major differentiator that decides whether it turns out to be a success or fails to meet expectations. Ensure your applications are peaked for optimal performance and success.

Trigent’s experienced and versatile Quality Assurance and Testing team is a major contributor in 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.

Responsible Testing – Human centricity in Testing

Why responsibility in testing?

Consumers demand quality and expect more from products. The DevOps culture emphasizes the need for speed and scale of releases. As CI/CD crisscrosses with quality, it is vital to engage a human element in testing to foresee potential risks and think on behalf of the customer and the end-user.

Trigent looks at testing from a multiplicity of perspectives. Our test team gets involved at all stages of the DevOps cycle, not just when the product is ready. For us, responsible testing begins early in the cycle.

Introduce the Quality factor in DevOps

A responsible testing approach goes beyond the call of pre-defined duties and facilitates end-to-end stakeholder assurance and business value creation. Processes and strategies like risk assessment, non-functional tests, and customer experiences are baked into testing. Trigent’s philosophy of Responsible Testing characterizes all that we focus on while testing for functionality, security, and performance of an application.

Risk coverage: Assessing the failure and impact early on is one of the most critical aspects of testing. We work along with our clients’ product development teams to understand what’s important to stakeholders, evaluate and anticipate risks involved early on giving our testing a sharp focus.

Collaborative Test Design: We consider the viewpoints of multiple stakeholders to get a collaborative test design in place. Asking the right questions to the right people to get their perspectives helps us in testing better.

Customer experience: Responsible Testing philosophy strongly underlines customer experience as a critical element of testing. We test for all promises that are made for each of the customer touchpoints.

Test early, test often: We take the shift-left approach early on in the DevOps cycle. More releases and shorter release times mean testing early and testing often that translates into constantly rolling out new and enhanced requirements.

Early focus on non-functional testing: We plan for the non-functional testing needs at the beginning of the application life cycle. Our teams work closely with the DevOps team’s tests for security, performance, and accessibility – as early as possible.

Leverage automation: In our Responsible Testing philosophy, we look at it as a means to get the process to work faster and better. Or to leverage tools that can give better insights into testing, and areas to focus on testing. The mantra is judicious automation.

Release readiness: We evaluate all possibilities of going to the market – checking if we are operationally ready, planning for the support team’s readiness to take on the product. We also evaluate the readiness of the product, its behavior when it is actually released, and prepare for the subsequent changes expected.

Continuous feedback: Customer reviews, feedback speaks volumes of their experience with the application. We see it as an excellent opportunity to address customer concerns in real-time and offer a better product. Adopting the shift-right approach we focus on continuously monitoring product performance and leveraging the results in improving our test focus.

Think as a client. Test as a consumer.

Responsibility in testing is an organizational trait that is nurtured into Trigent’s work culture. We foster a culture where our testers imbibe qualities such as critical thinking on behalf of the client and the customer, the ability to adapt, and the willingness to learn.

Trigent values these qualitative aspects and soft skills in a responsible tester that contribute to the overall quality of testing and the product.
Responsibility: We take responsibility for the quality of testing of the product and also the possible business outcomes.

Communication: In today’s workplace, collaborating with multiple stakeholders, teams within and outside the organization is the reality. We emphasize not just on the functional skill sets but the ability to understand people, empathize with different perspectives, and express requirements effectively across levels and functions.

Collaboration: We value the benefits of a good collaboration with BA/PO/Dev and QA and Testing – a trait critical to understand the product features, usage models, and work seamlessly with cross-functional teams.

Critical thinking: As drivers of change in technology, it is critical to developing a mindset of asking the right questions and anticipating future risks for the business. In the process, we focus on gathering relevant information from the right stakeholders to form deep insights about the business and consumer. Our Responsible Testing approach keeps the customer experience at the heart of testing.

Adaptability & learning: In the constantly changing testing landscape, being able to quickly adapt to new technologies and the willingness to learn helps us offer better products and services.

Trigent’s Responsible Testing approach is a combination of technology and human intervention that elevates the user experience and the business value. To experience our Responsible Testing approach, talk to our experts for QA & Testing solutions.

Learn more about responsible testing in our webinar and about Trigent’s software testing services.

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

Accelerate CI/CD Pipeline Blog Series – Part II – Test Automation

In part I of this blog series we spoke about Continuous Testing (CT), CI CD and that Test Automation is a key to its success, how to leverage test automation to enable coverage and speed. Let’s get an in-depth understanding of why it’s essential.

Why Automation of Testing is Essential for CI CD

Code analysis tools, API testing tools, API contract testing tools, Service virtualization tools, performance assessment tools, and end-to-end automation tools are all parts of CT. However, test automation is one of the key enablers of CT as:

  • It allows us to execute tests in parallel, across multiple servers/containers, speeding up the testing process.
  • It frees engineers from repetitive tasks, enabling them to focus on value-adds.
  • It helps validate the impact of even minor changes continuously.

Characteristics of a Good Automation Framework

For test automation to be effective, it must be supported by efficient frameworks. The frameworks provide a structure and help integrate and realize the efforts of a distributed team.

  • Test frameworks must support various languages, browsers, and techniques to make them future-proof. They must possess an Agile testing environment to support the continuous delivery pipeline.
  • The testing platform must be scalable to support as many tests as needed.
  • The platform must support compatibility tests on simulated devices to cut down the cycle.
  • The environment should maximize automation, i.e., trigger tests, analyze results, and share test information across the organization, in a fully automated manner.
  • The testing platform must include security features such as encryption of test data and access control policies

Characteristics of Trigent’s AutoMate Test Automation Framework

Reinforced by globally renowned partners, Trigent’s testing focus is aligned with the current business environment and offers cost benefits, performance, and agility.

As niche test automation experts, we have significant experience in open source and commercial testing tools. Our extensive library of modular, reusable, and resilient frameworks simplifies scenario-based automation. We provide on-demand testing and next-gen scheduling.

Features and benefits
  • Accelerated script development: Script/test cases development effort reduced up to 60-80% in comparison to traditional test automation approaches. Reduces Test Scripting Complexity.
  • Modular and reusable framework components: Reduced dependency on tool-specific resources. Ability to kick-start automation quickly. It supports reusable components. Reduced Test Automation maintenance costs. Allows multi-browser, multi-device testing.
  • Easy test script maintenance: Ease of test execution. Easy to make changes and maintain scripts in the long run. Improved error and exception handling. Supports multiple scripting languages.
  • On-demand Testing: Sanity, Smoke, Integration, Regression, etc. Provides effective test data creation on the go.
  • Hybrid Model: Modular test framework built using JUnit or TestNG. Integrates with multiple test automation tools. Allows a common way of handling multiple test types.
  • Scheduling and customized reporting: Send test results to ALM. Integrates with Test Management tools to track your test plans effectively.
  • Leverages new tech trends: Leverages AI/ML utilities & tools that allow for effective Test Impact analysis and test selection. Integrates with CI/CD tools to enable automated executions. Allows parallel executions to reduce test execution time

Learn more about Trigent software testing services or test automation services

Accelerate CI/CD Pipeline Blog Series – Part 1- Continuous Testing

Given its usefulness in software development, Agile methodologies have come to be embraced across the IT ecosystem to streamline processes, improve feedback, and accelerate innovation.

Organizations now see DevOps as the next wave after Agile that enables Continuous Integration and Continuous Delivery (CI/CD).  While Agile helped streamline and automate the entire software delivery lifecycle, CI/CD goes further. CI checks the code often, and the tested chunks are integrated, sometimes several times in a single day, to create a stream of smaller and frequent releases through CD.

As a principal analyst at Forrester Research puts it succinctly: ”If Agile was the opening act, continuous delivery is the headliner. The link that enables CI/CD, however, is Continuous Testing (CT).

What is Continuous Testing?

Continuous Testing is a process by which feedback on business risks of a software release is acquired as rapidly as possible. It helps in early risk identification & incremental coverage as it’s integrated into the delivery pipeline. Continuous Testing is achieved by making test automation an integral part of the software delivery pipeline. It’s seamlessly interwoven into the software delivery pipeline (not tagged at the end).

Though CI/CD enables speed-to-market, inadequate end-to-end experience testing can turn it into a liability.  A key aspect of CT is to leverage test automation to enable coverage and speed.

Test Automation – Continuous Testing’s Secret Success Factor

Automation of tests is the key to ensure that Quality Assurance is as continuous, agile, and reliable.  CT involves automating the tests and running them early and often.  It leverages service virtualization to increase the test coverage when parts of the business functions are available at different points in time.

Automated Testing binds together all the other processes that comprise the CD pipeline and makes DevOps work. By validating changing scenarios, Smart automation helps in faster software delivery.

In part II of the blog series we will talk more about why test automation is essential for CI/CD Testing, and automation framework.

Learn more about Trigent software testing services or test automation services

Trigent excels in delivering Digital Transformation Services: GoodFirms

GoodFirms consists of researched companies and their reviews from genuine, authorized service-buyers across the IT industry. Furthermore, the companies are examined on crucial parameters of Quality, Reliability, and Ability and ranked based on the same. This factor helps customers to choose and hire companies by bridging the gap between the two.

They recently evaluated Trigent based on the same parameters, after which they found the firm excels in delivering IT Services, mainly:


Keeping Up with Latest Technology Through Cloud computing

Cloud computing technology has made the process of meeting the changing demands of clients and customers. The companies who are early adopters of the changing technologies always achieve cutting-edge in the market. Trigent’s cloud-first strategy is made to meet the clients’ needs by driving acceleration, customer insight, and connected experience to take businesses to the next orbit of cloud transformation. Their team exhibits the highest potential in cloud computing that improves business results across the key performance indicators (KPIs). The Trigent team is instilled with productivity, operational efficiency, and growth that increases profitability.

The team possesses years of experience and works attentively in the cloud adoption journey of their clients. The professionals curate all their knowledge to bring the best of services to the table. This way, the clients can seamlessly achieve goals and secure their place as a modern cloud based-enterprise. Their vigorous effort has placed them as the top cloud companies in Bangalore at GoodFirms website.

Propelling Business with Software Testing

Continuous efforts and innovations are essential for businesses to outpace in the competitive market. The Trigent team offers next-gen software testing services to warrant the delivery of superior quality software products that are release ready. The team uses agile – continuous integration, continuous deployment – and shift-left approaches by utilizing validated, automated tools. The team expertise covers functional, security, performance, usability, accessibility testing that extends across mobile, web, cloud, and microservices deployment.

The company caters to clients of all sizes across different industries. The clients have also sustained substantial growth by harnessing their decade-long experience and domain-knowledge. Bridging the gap between companies and customers and using agile methodology for test advisory & consulting, test automation, accessibility assurance, security testing, end to end functional testing, performance testing the company holds expertise in all. Thus, the company is dubbed as the top software testing company in Massachusetts at GoodFirms.

Optimizing Work with Artificial Intelligence

Artificial intelligence has been the emerging technology for many industries during the past decade. AI is defining technology by taking it to a whole new level of automation where machine learning, natural language process, and neural networks are used to deliver solutions. At Trigent, the team promises to support clients by utilizing AI and providing faster, more effective outcomes. By serving diverse industries with complete AI operating models – strategy, design, development, and execution – the firm is automating tasks. They are focused on empowering brands by adding machine capabilities to human intelligence and simplifying operations.

The AI development teams at Trigent are appropriately applying the resources to identify and govern a process that empowers and innovate business intelligence. Besides, with their help with continuous processes enhancements and AI feedback systems, many companies have been increasing productivity and revenues. Therefore, helping clients to earn profit with artificial intelligence, the firm would soon rank in the list of the artificial intelligence programming company at GoodFirms.

About GoodFirms

GoodFirms, a maverick B2B Research and Reviews Company helps in finding Cloud Computing, Testing Services, and Artificial Intelligence firms rendering the best services to its customers. Their  extensive research process ranks the companies, boosts their online reputation and helps service seekers pick the right technology partner that meets their business needs.

Getting to Know the Salesforce Agile Accelerator

Agile, in simple terms, is a principle of being open-minded and dynamically evolving with the changing needs of the world. Now, how to accelerate the agile process using Salesforce? Agile Accelerator is the answer.

***Before I go ahead, let us see how the whole world is now following Agile. For example, each country’s response to Covid-19 required emergency responses and almost overnight changes with the way things were done, setting up containment zones, medical containment, and treatment zones, and mass evacuation of the students and citizens stuck abroad. All these are dynamic inclusions of protecting humanity!! Interesting topic but will cover it in detail in another blog separately***

Customers worldwide are developing and managing their software products and applications on Agile, which has led to a tremendous demand for project management tools, like JIRA. It has become increasingly efficient, improving accessibility, and economically viable for most companies to build and maintain their software on the cloud. It gives them an edge of 24/7 accessibility, transferring maintenance-related challenges to a highly competent service provider.

Salesforce has won over a large share of clients in this space, ensuring efficiency, accessibility, dynamic licensing, platform availability for complex products/projects, and a maintenance perspective.

Salesforce Agile Accelerator

In its nascent stages, it was a platform called ‘Grand Unification System (GUS)’  built by the Salesforce team to help manage their product backlogs, sprints, user stories, defects, etc. It is tailored for agile development and scrum and typically reserved for social networking. This product helped Salesforce as a company to be what it is: A major market reckoner in Cloud Services.

The Agile Accelerator is a managed application available via AppExchange, an evolved version of the GUS with the expertise of providing a single source of truth! With Agile Accelerator, we have a single application for the entire project management. It also provides easy collaboration with the help of Chatter – a real-time app that helps users to connect, engage, and share information within the organization.

Advantages:

  • Ability to integrate backlogs with standard Salesforce objects like Accounts/Cases etc. is super-efficient and easy.
  • Provide tracking options for backlog or sprints in Kanban view on both mobile and desktop. 
  • Ensures a single sign-on to track backlog as well for the application, obsoleting SSO applications.
  • Collaborate with cross-functional teams, share updates, and work to get done anywhere, any device, without leaving Salesforce.

A snapshot view of the application

With various tabs for various project needs like creating and maintaining profiles, collaboration with Chatter, Reporting, Requirements view with Unified wall, and product tags, creating and managing teams, planning sprints, builds and releases and themes:

Feature Comparison: When compared with the present market leader, JIRA, on key features, Salesforce has a definite edge on parameters like Reliability, Availability, Performance, Trainings (both online and offline), ease of implementation, scalability, ROI, and Pricing.


And, with most customers giving a 10/10 rating to renew services with Salesforce Agile Accelerator, will it be safe to assume this might be the end of other major project management tools?

We have to wait and watch.

Put The ‘Q’ Within Your DevOps

The recent industry report estimated worldwide software failure costs to be USD 1.1 Trillion. A 2018 study by the Consortium for IT Software Quality maintained that for the US alone, the cost of defective software was USD 2.84 Trillion. These relative costs of fixing errors post a software release is unarguably higher than if they were uncovered during the design phase.

The 2019 Accelerate State of DevOps report maintains, “DevOps will eventually be the standard way of software development and operations.”  This is indeed true as enterprises acknowledge three factors: increased demand for superior quality software, faster product launches, and better value for tech with optimized software delivery performance. However, in today’s competitive landscape, is this enough to succeed?

Enterprises need something extra—the strategic integration of QA (Quality Assurance) with DevOps. While DevOps brings speed, innovation, and agility, its success lies in adopting the right QA strategy.

Devising the optimal QA strategy – DevOps

The success of Dev-Q-Ops depends on a robust QA strategy and essential best practices to boost rapid development and deployment of DevOps applications.

Earlier, the interaction between developers and testers was minimal, and both groups relied largely on their interpretation of the written / implied requirements without largely validating their understanding amongst themselves. Consequently, this led to too many back and forth arguments, counter-arguments that compromised, not just the quality, but the speed of product deployment too.

Today, most good DevOps implementations include strong interactions between developers, rigorous, in-built testing that comprehensively covers every level of the testing pyramid–from robust unit tests and contracts to API tests and functional end-to-end tests. However, the shifting of lines between what is ‘tested’ by the testers and what is automated by the developers often blurs the test strategies and approaches; thereby according a false sense of good test coverage.

Testing, both automated and manual, are continuous processes that remain active throughout the software development cycles. A definite change in mentalities is required to adopt continuous testing and continuous delivery. The Dev-Q-Ops culture is expected to lay the foundations for this and serve as the much-needed value add to your business.

It is then imperative to introduce a balance and adopt a QA strategy that not only ensures the right coverage and intent of testing, but also leverage automation to the maximum extent. The QA strategy should always be assessed on whether it helps attain vital DevOps metrics. Some examples of how the metrics can be effectively improved are:

  • Lead Time for Changes, where for example, the approach is on early identification of defects through testing early; leveraging the test pyramid, and undertaking improved impact analysis leading to better identification of ‘necessary’ coverage.
  • Deployment Frequency through facilitating the right automation spread throughout the test pyramid, deploying improved test environment and test data management and initiating parallel testing through rapid environment deployments and teardowns.
  • Time to Restore Services through shared monitoring of operational parameters and ensuring the ability to narrow down on change and impact, and thus regression, by leveraging AI.
  • Change Failure Rate by ensuring for example, risk identification, customer experience, and touchpoint testing and monitoring customer feedback and usage.

Effective execution of Dev-Q-Ops also enables Continuous Testing (CT) to easily zero-in on risks, resolve them, offer feedback and enhance quality.

Therein lies the importance of a structured QA strategy. It not only lays the foundations for a consistent approach toward superior quality but also enhances product knowledge while alerting enterprises to questions that would otherwise have remained unanswered. So, to release high-quality products without expensive rollbacks or staging, it is imperative to add the ‘Q’ to your DevOps.

In conclusion, new-age applications are complex. While DevOps can quicken their rollout, they may fail if not bolstered by a robust QA strategy. QA is integral to the DevOps process and without it continuous development and delivery are inconceivable.