Ruminating on Shadow Testing or Shadow Mirroring

Shadow testing is a software testing technique that involves sending production traffic to a duplicate or shadow environment. This allows testers to compare the behavior of the new feature in the shadow environment to the behavior of the old feature in the production environment. This can help to identify any potential problems with the new feature before it is released to all users.

The following diagram from the Microsoft GitHub site illustrates this concept.

The following blogs/articles explain this concept in good detail:

• https://microsoft.github.io/code-with-engineering-playbook/automated-testing/shadow-testing/
• https://github.com/opendiffy/diffy
• https://blog.markvincze.com/shadow-mirroring-with-envoy/
• https://reshadat.medium.com/test-apis-without-writing-tests-with-twitters-diffy-8dfad1d92b5

Ruminating on Consumer Driven Contracts

One of my teams has successfully implemented the paradigm of consumer driven contracts in a recent digital transformation program. We were very happy with the Pact framework and the OOTB integration available in Java (Spring Boot).

Anyone still not convinced on using Consumer Driven Contracts should peruse the below link without fail - https://docs.pact.io/faq/convinceme

The fundamental advantage of  Consumer Driven Contracts is that only parts of the API that are actually used by the consumer get tested. Hence any provider behavior not used by current consumers is free to change without breaking tests.
When you are about to change the contract of a popular API, you can quickly check which consumers would be affected and where to focus your efforts on.

It is important to remember that Pact should not be used for functional testing...it is to be used only for contract adherence. Pact can also be integrated into your CI-CD process, wherein you run all the consumer contracts as part of the build. 

Ruminating on the V model of software testing

In the V model of software testing, the fundamental concept in to interweave testing activities into each and every step of the development cycle. Testing is NOT a separate phase in the SDLC, but rather testing activities are carried out right from the start of the requirements phase.

• During requirements analysis, the UAT test cases are written. In fact, many teams have started using user stories and acceptance criteria as test cases. 
• System test cases and Performance test cases are written during the Architecture definition and Design phase. 
• Integration test cases are written during the coding and unit testing phase. 

A good illustration of this is given at http://www.softwaretestinghelp.com/what-is-stlc-v-model/