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.

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.

Why QA Offshoring Pays Off with the Right Strategy

Here’s a heads up on outsourcing testing in a DevOps world.

Digitization has disrupted existing business models, processes, and strategies, but some factors continue to remain constant, i.e. cost, time-to-market, and experience. Of the three, customer experience has taken precedence, making quality assurance a non-negotiable constant.

Over the years, quality assurance has been associated with different implications including certifications and functionalities. Today, quality assurance is all about people or customers and their personal experience with a product or solution. This makes sense when we view the world from the perspective of the Internet of Things and digital transformation, where personal experiences define a brand’s efficacy. QA organizations, therefore, are evolving to include social and psychological impacts to value delivery. Value delivery includes cost, and time saved where QA plays a pivotal role in a project from its requirement stage to ensure that non-productive time spent in the last phase for testing is eliminated.

In its new avatar, QA is instrumental in developing and launching a successful project. QA is built into all aspects of a project and instrumental in process improvement as well as defect management in agile testing, security testing, accessibility testing, performance testing, and user acceptance testing. In an agile environment, the mantra is “test early and test often”.

Related: Improved time to market and maximized business impact with minimal schedule variance and business risk.

QA is an integral part of a project, from reviewing user stories with business analysts, as they are created to ensuring that they meet the ‘testable’ criteria. They create test cases well before the start of a sprint to facilitate a test-driven development (TDD). They will work side-by-side with developers and will be responsible for the entire deployment of the quality assurance environment.

With QA playing such a pivotal role in a project, the question which often arises is, ‘How would offshoring QA work? Will it be beneficial? And, what does it actually involve?’

Most companies that have their in-house or software development arms, will have a testing team in place. QA cannot be confused with this team. In the new world, quality assurance requires skills and experience which can only be met by seasoned QA professionals whose job is to focus on delivering best-in-class solutions.

Secondly, the cost and quality of software testing programming language can affect the overall cost of a project. In some cases, it is estimated that testing can cost up to 40% of a project’s overall cost. Intangible costs can include poor test execution, lowered customer satisfaction, higher operating costs, and increased business risk. CIO’s, therefore, at least in the last decade or so, have opted to offshore their testing work to save on both tangible and intangible costs.

Offshoring QA especially makes a lot of sense for SMBs with tight budgets. These companies normally defer QA to the end which results in a less stable product. Having a team that works within the budget makes more sense. In this model, the core team will be retained on a long-term basis and a flexible team can be added/reduced based on the ebb and flow of the project. This option provides faster ramp-up and flexible ramp-down of testing resources.

Also, the follow-the-sun model makes great sense for offshore testing. Imagine a team working on functionality in the day and another team across the world testing it the same day. The hours saved add up to make complete business sense.

When considering strategic business management off-shored quality assurance in software testing can result in better quality applications, reduce business risks, and improve existing critical testing processes. Having said that, the key to success is in finding the right offshoring partner. Companies that are considering offshoring their QA, along with looking at cost savings must look at the competencies and capabilities of the partner company.

Some critical factors to be kept in mind when considering offshoring are:

  • Cost-Efficiency

More often than not, the word offshoring is considered synonymous with cost savings but to actually reap the benefits of saved budget and time with exemplary results requires rock-star testers and not a pool of untrained workers offering cheaper rates.

  • Industry Experience

As we already know each industry is different and has its own unique business processes.  Having a team of great testers with no clue about a business will only end up slowing down the testing efforts. One must choose a team of QA professionals with strong industry knowledge to ensure that the areas with the highest level of business impact get the highest testing priority.

  • Technology Frameworks and Best Practices

QA professionals should ideally have some unique intellectual property and best practices that they bring with them. A team that has successfully completed multiple projects will have a set of best practices, accelerators, methodologies, and tool kits to accelerate the testing efforts and reduce time to market.

  • Cultural Fit

When considering offshoring, especially of testing services, cultural fit becomes paramount to the project’s success. Cultural fit is acquired only by working with partners who have managed projects in the geographies under consideration. It is only with experience that an offshore team can communicate, work at the required pace, and deal with issues as and when they arise. In addition, if you need a large managed service, it is also important to have an on-site lead to ensure accountability.

  • Agile is important

The role of testing in agile practices is already recognized and yet several organizations struggle to integrate testing and quality into their agile delivery methods. A partner who understands how testing ‘fits’ into the development effort will work to resolve problems on the go to ensure that the product is not delayed.

To summarize, when identifying a partner, a company must trust the partner’s suggestion on the engagement model. The QA partner should be able to mobilize people, knowledge acquisition, infrastructure, and processes. The next step would be for the independent QA and testing team to integrate seamlessly with the project team. The QA team should have the strong industry knowledge and translate this into the user experience. This knowledge will define the project’s overall flow.

Keeping these critical factors in mind, and with a well-defined strategy in hand, a successful QA offshore engagement is possible. Add one more ingredient, i.e. trust, and the project is set up for success.

The Role of QA in an Agile Model

Quality Assurance & Software testing over the years has mostly been treated as an isolated function in project development. However, in agile methodology, testing is an integral part of the software or system development lifecycle.

Agile methodology involves continuous iterations of both the development and software testing activities for a project. It requires the involvement of all the developers working on a project to work in parallel with the testing team, to ensure that the business requirements of the customer are met on schedule.

Among teams that do not adhere to the agile manifesto, the role of the tester is limited to writing test cases, executing them, logging the defects, and verifying them. But in agile methodology, the tester works as a part of the development team and ensures that software quality assurance is built into the end product by working closely with the development team.

With the agile methodology gaining popularity, system testing, or application testing as a process, has transformed and testers today play a key role in the overall project development process. This requires testers to not only have strong testing skills but also good domain knowledge. Testing engineers, therefore, need to get adjusted to this new test strategy of rapidly changing requirements.

Key attributes of testers working on an Agile model are as follows:

Testers need to do a lot more than just building test cases:

The testers in the traditional waterfall model are involved at the end of the project when the coding is complete when the QA is expected to execute the test cases to verify if the built features match the requirements or not.

But in the Agile model, the QA adds more value to the project. Her role is not just restricted to the building and execution of the test cases but works closely with the developers, BA, Product Owner, and so forth. In this scenario, the QA can write acceptance test cases for the Product Owner and work and interact with the Product Owner in order to ask questions and clarifications regarding the business requirements.

Testers need to collaborate and coordinate with the developers and the end customer:

In an Agile model the QA tester needs to continuously provide the testing feedback to the customer and in turn collect feedback from them after each sprint. Agile testers need to look from different perspectives i.e. end-user, business, developer, support and in order to achieve this, the quality assurance needs to coordinate with all of them. In some cases, the QA tester works as the Proxy Product Owner too to help them to develop the acceptance criteria for their user stories.

In the Agile model, developers and testers at times collaborate to write test cases as the acceptance criteria. The coordination among the team especially quality assurance and developers reduces doubts and ensures that all are on the same page. Also it saves the coding time of developers.

Testers need to have automation testing skills:

It is always an add-on if a tester knows about automation testing tools. Testers with automation skills can help prepare the test scripts and test plans for better coverage which helps in an agile project with a sprint of 2-4 weeks. Automation also helps during the regression testing of the project by providing quick feedback.

Every time a new build is given for testing the QA can run the automation scripts and provide rapid feedback on whether the new features, as well as the old features, are working correctly or not.

Testers help in estimation:

The QA always writes the test cases/scenarios for an application which covers both the happy path and unhappy paths. This helps for accurate estimation of user stories based on the clarity they have after identifying the positive and negative flows.

Testers needs to participate in demos:

After the completion of each sprint, a demo is given to the customer and other stakeholders of all the features completed in that sprint. As we know, a typical sprint lasts for 2-4 weeks and in such a short span all the people involved are busy in completing their own things; the developers are busy in developing the assigned user stories and the QA is busy testing the released items, clarifying the questions from Product Owners and automating the same. In such a short span the developers sometimes find it difficult to finish the complete functionality of the assigned user stories. So the developers sometimes consult the QA as they have a better understanding of the application. Hence it would be a good practice if the demo to the client is carried out by the QA and thereafter quality assurance can answer all the business related questions coming from the client. This way the developers can take care of technical queries from the customer.

Testers need to analyze the requirements:

The QA in the Agile model, is in a good position, after the BA to analyze requirements because the application is always used by the QA from the end user’s point of view. Hence the QA helps the customer by providing them timely feedback based on their testing experiences.

The QA should be a part of all the retrospectives and review meetings to contribute to overall process improvement and requirement understanding.

To summarize, the QA is an important and integral part of the team who is involved in all phases of the software development cycle. To put it in the right perspective, testers do more than “Just Testing”!

Embed Software Product Testing in your DNA

As software product development is getting complex with the demand for breakthrough features and functionalities, software testing techniques are getting even more complex. The introduction of new features opens the door for many test case scenarios. Besides, there are various combinations of platforms, browsers, and devices that need to be tested for each scenario.

We know software product testing is not a new fad; it has seen its fair share of transition from manual testing to test automation and likewise testing tools have also evolved. However, as the market is abuzz with innovative products and platforms, businesses are constantly slogging to be front runners in efficiency and customer experience. Testing is no longer a ritual but a market readiness strategy for any respectable product or application.

New age start-ups have taken the market by storm, as the demand to release quality products faster has become increasingly important. Delay in launch of a product and you succumb to laggard status, while a minor defect and you invite customers and social media scalpel.

Given the demand and shift towards high-quality standards, a large number of software testing companies in India are investing time and money to improve customer experience and satisfaction. Be it a cloud platform or on-premise platform, Software product testing companies make use of the latest technologies and tools to get insights and feedback about the quality of their product. You can embed product testing either as an extension to your internal team or engage an independent validator whose approach would be structured and unbiased.

Outsourcing software product testing

The best strategy to address software product testing is to engage an offshore independent testing vendor. It would not only provide an independent eye but also reduce investments in terms of resource utilization. Other benefits would include greater return on quality assurance, augmented efficiency, flexibility, and minimized revenue cycle.

Before outsourcing your projects to software performance testing companies, do thorough research to see if the company has the required skills, experience, and expertise. It is important to find the right vendor with the right profiling in the performance testing strategy, as it would help your company optimize products and meet the high-quality standards of today’s demanding customers.

Ensuring maximum test coverage and managing timeline – Software Quality Assurance

What is Software Quality Assurance?

“Quality Assurance” is the calling card for a software testing services provider. No matter how robust a software application is, its failure to perform at a critical instance can prove fatal to clients. Through the lens of history, it has been observed that enterprises spend more on bug fixes as compared to developing software applications.

Though an in-depth analysis of quality is outside the scope of this post, I will give a round-up on “Quality Assurance” by ensuring maximum test coverage as a means of achieving sustained client relationships.

One of the common challenges for a software testing team is to deliver projects within the time-frame yet ensure maximum test coverage. Software testing is not a one size fits all solution for problems as testers have to drill deeper to explore bug fixes that can damage the quality of an application. Though a solution to this is not readily available, however, we may need to arrive at one, based on the project circumstances/needs.

Before I set out for a solution, let us explore some of the possible risks/outcomes of not meeting the time-frame/maximum coverage:

a) Time Frame Overshoot: Time Consuming Delivery, Client Dissatisfaction, Extra Cost, Extended Time to market

b) No Coverage: No confidence in product quality, buggy product, user dissatisfaction, extra cost in fixing issues and re-releasing the product, etc.

“Time Limit” is a management activity, but from a tester’s perspective, we run on a pretty tight schedule and have to focus primarily on ensuring maximum coverage within the prescribed time limit. We have to ensure the application performs its function time after time. And to achieve this, we can develop a few handy utilities/tools like the one I have described below:

1) Develop a complete test suite, which includes:

  1. Test case for all functionality of the application
  2. Critical Functionality of the application being identified and filterable
  3. Prioritize test case as high/medium/low

[Benefits]: Allows to “Pick & Choose” test cases for execution based on:

  1. Critical module/function
  2. High Priority test cases
  3. Regression testing cases based on Change/Bug Fix in the current build

2) Optimize test scenarios:

  1. Eliminate repetitive and non-valuable tests that may yield the same results as other tests in the suite.
  2. Effective Coverage: Focus on combination testing using orthogonal array-based mathematical model tools like All Pairs, PICT, etc., and Decision Tables.

[Benefits]: Provides minimum scenarios covering all possible combinations which are non-repetitive and valuable in predicting the result.

3) Automated  Regression Suite – Automate all possible regression test cases

[Benefits]: Ensures execution and coverage of all mandatory flows without much manual intervention, even during crunch situations

4) Focused Testing: Apart from the above in case we have a very tight deadline, it is always preferable to focus the testing efforts on some critical areas like:

  1. Areas that may be vulnerable to changes and yield more bug fixes
  2. Areas that have yielded more bugs in the past
  3. Areas which are exposed to the End User or User Critical


All the above utilities applied together will provide a cohesive framework to guide a tester or a development team to maximize test coverage and achieve greater quality within the stipulated time limit. However, it also depends on the tester’s knack for choosing the “Minimum most test cases” to draw upon insights that can help solve similar issues.

In the process, if the user over emphasizes minimizing the test cases to meet the time limit or if the area of focus is incorrect, he may miss out in terms of coverage and may lead to under testing. Hence the tester should wisely balance in choosing the right focus area and the right test cases for the build and plan to execute them within the given time frame. If the tester feels that the selected/shortlisted test cases cannot be run in the given time frame, it is always advisable to buy more time. And in case that is not possible, it’s prudent to alert the stakeholders about what test cases have been ignored and which modules are under-tested.

Ignore “Quality Assurance” in your services road-map and you do so at your own peril.