Incubation of Stark

OneShop-OneTest - 5 NatCos

-A twisted tale of selenese in Gotham City.

Imagine a situation when you hit buy product on amazon.in, it takes you to the cart page. But when you hit buy product on amazon.ca it takes you directly to the payment page.

Same codebase, same UI components, but 5 different websites configured with n number of permutations.

Each country has its own business use case, let’s name each country as a Natco (National Country). One Natco wants its user to see the cart page upon adding a product but another wants its users to see the payment page. One Natco wants to restrict some of its users from buying expensive products but another does not have any such limitation and the business cases are endless!

So what, Mr. Spidie can easily automate all of the user scenarios and will save everyone’s manual effort using any automation tool, that’s not a big deal.

He sits one night, decides not to call Mary Jane, and will finish his task. He found some fancy UI-locators, did 1000+ lines of code and the job is done. The next morning, once he kicked off the executions it failed, because of some random configurations done by the Content Manager or Business owner

Mr. Spidie broke up with Mary Jane and failed to accomplish the automation task.

Now Mr. Bruce got this project to automate this application and automation must work for all Natcos at the same time and with the same code base. Automating such kind of platform is a nightmare as you can only automate what you see.

Main problems –

1. The feature is turned on but is tuned in a different flavor (After login you need to confirm the login with OTP but another country does not restrict its users to enter OTP).
2. The same feature can be turned on for 1 Natco that could be turned down for another Natco. (Payment turned off for 1 country turned down for another)

But Mr. Bruce found a solution to the above-mentioned use cases. He observed that each Natco’s website uses a JSON generated by a CMS(Content Management System). Each Natco has a unique key, Mr. Bruce found that he can call an API with NATCO’s unique key to fetch the JSON. He decided to use this JSON in his automation script. He flattened this JSON and named it as configurationMap. He continued to call this map at any place to find what course of action is required to be performed in the following fashion.

But!! that lead to a situation: -

The user performs the following action

přidat do

Dodaj do koszyka

pridať do košíka

kosárba helyez

adauga in cos

додадете во корпа …

Nothing fancy above, the user is just performing add to basket but while sitting in different countries and hitting the same set of microservices at the same time. Mr. Bruce also faced this challenge where he was required to use translation in his automation script. For translations also there is a JSON, the same way we had for configurations. Mr. Bruce flattened it again and named it translationMap.

To make test cases easily understandable, Mr. Bruce used Cucumber, which is a well-known BDD (Behaviour Driven Framework) so that the test scenarios written by Spidie are also understood by Mr. Bruce.

Now cucumber runs on tags, consider tag to be a unique annotation which recognizes the test-scenario eg. Place Order as shown above. But tags can’t be constant for every Natco due to the above-mentioned problems (1 featured turned for 1 Natco might be turned off for another).

Suppose we have 4 payment methods, Natco1 supports credit card, and pay on delivery. Natco2 does not support pay on delivery. So the @pay_on_delivery will be executed only for Natco1, not for Natco2.

All tags to be executed are defined in Cucumber’s Runner class and this class extends a predefined class called AbstractTestNGCucumberTests. Some custom logics were defined, which reduced many if statements to a few.

Test executions for each NATCO were made possible using a Jenkins pipeline.

Problem 3 (No control on API response, Exhaustive tests)

All the user data such as user eligibility, user consents, reservation of items, login, payment methods, shipping methods, credit scoring, etc comes from HAL(Harmonized API layer, a 3rd party API layer, developed and maintained on another planet). HAL responses are similar to a chameleon’s color. So we can’t mimic every test scenario till the time we are in the space of HAL.

Now all the executions made above were done on Planet Earth, but we needed a space to run all our tests, where there is no gravitational force (external forces which restrict us to turn on any feature). For this we found the planet STARK. One can patch the API with a JSON supporting to their own environment or mock any API on a mock server to mimic there user scenarios.

But how is life on planet Stark?

. . . to be continued