How at Meesho we are speeding up Test Automation & applying a Test Driven Development (TDD) approach

Amrita Bose
5 min readDec 18, 2019

--

Guest Blog by Nilamber Singh, Software Development Engineer in Test (SDET)

At Meesho, we always think of the best approach while automating tests, and as basic as it might sound, the concept of reusability is often ignored. Reusability is such a basic and much needed feature that we decided to include it in test automation by the usage of dependency and dependency injection.

Here at Meesho, while testing a feature we often perform certain repetitive tasks as part of data generation, which is common across all the projects. For instance, placing an order, cancelling an order, manifesting, delivering the order, placing return and exchange requests, and more. To perform a test we often need to carry out the steps (as mentioned below) as a precondition to reaching a stage from where we can go ahead and start testing the new feature.

Even while automating tests, it’s essential that we don’t include the repetitive tasks as a part of automation. And if we don’t take care of that, it might result in unnecessary and un-maintainable chunk of codes which could have been avoided otherwise.

To solve this issue, we decided to build a dependency through which could handle these tasks elegantly without the QA (Quality Assurance) engineers having to worry about automating these pre-conditions. This solves the above mentioned problems and helps in speeding up test automation. This also includes the number of services that helps us perform the pre-steps.

Supply Utility, The dependency way to go !

As a result of Supply Utility, the test code is much more maintainable and QA engineers have been able to deliver feature automation much faster than before.

Not only automation, but also the dependency is integrated with UI (QA Portal ) via a Java service that allows QAs to perform the above tasks manually as well with just a few clicks. So no roaming around searching for data — just create your own data and begin testing right away!

Below is the explanation of how each feature has been able to help in automation and speeding up the process.

Placing an order

Placing an order requires multiple API calls at service level. Supply Utility provides just a single method to do all of that. For e.g: choosing multiple products for order, choosing payment mode (COD, Online, Mixed Mode ), and more.

Manifesting an order

Manifesting an order is a pre/mandatory step before an order can be marked shipped or delivered. It requires one to visit the supplier portal to perform further action on the order. With the dependency, all of this can be done with just a method/API/UI call.

Raising return/exchange request and order pickup

The order pick up after return or exchange is another step which is done in multiple steps. For e.g. first of all there needs to be a request raised for return or exchange and then the generated AWB number needs to be used for the order pickup. This is again simplified using the Utility.

Creating new supplier and adding catalogs

Sometimes there is a need to create a new supplier either domestic or international. But a new supplier renders no use unless some products/catalogs are added to new supplier and user can place an order from this supplier. Creating a new supplier is often a hassle as it includes integration of multiple services , KYC inclusion, etc. But all of this is handled in Utility so that QAs don’t have to worry about it anymore.

Excel- POJO Mapping

When automating, the most important step is to prepare data. We often use some data aggregators like Excel to store our test data, which then becomes an input to our test cases. It’s of utmost importance that we use proper ways to map our data from Excel into our test, so that they are easily accessible. Apache POI is one of the ways through which we can read our test data from Excel, but what about mapping them with our tests?

It’s okay to map them with individual variables but this becomes a problem when the test data is huge (say 100 columns). The code becomes unmaintainable and unreadable. This problem is solved by mapping the columns with POJO variables, the use of Java reflections comes in handy, the excel column names are mapped with POJO variable names.

So you just have to mention the excel and the Java POJO class, and the data will be mapped automagically. This also supports the creation of nested JSON Objects if you wish to create a JSON from POJO for testing.

The QA Portal

We all agree that not everything can be automated and also there are some use cases that don’t require an automation effort. So when there is an Utility to support basic steps in automation testing then why not use it to facilitate and speed up manual testing as well. The QA Portal facilitates all the features included in automation for manual testing as well. This speeds up manual testing and enables faster delivery. It’s well supported by a neat and easy to use UI.

The TDD (Test Driven Development) Approach

Since we spoke about all the ways of speeding up the test automation and its benefits, putting it to good use is another milestone. As we all know that manual testing can be a hard and tiring job. It becomes even more cumbersome, time consuming and error prone while testing a new feature where there might be multiple cycles of testing and retesting involved.

In those instances, the TDD approach is the best way to solve this problem. TDD involves building up of test automation suite for new features on top of existing regression suites. QAs responsible for testing are involved from the design discussions phase so that they are aware about the ins and outs and breaking points of application.

TDD usually involves test designing, test automation and test execution. By the time a feature is ready to be tested, the test suite will be ready to be executed on top of the new feature. Hence, it doesn’t matter how many bugs fixes and re-testing is required, test scripts are always there in the form of Smoke/Sanity/Regression suites to help with the testing and speed up the feature delivery time. These tests can always be used whenever there is need for regression testing — a feature thus providing speed and perfection.

Want to join Nilamber and help Meesho create 20 million entrepreneurs by 2020? Then apply here. We are hiring!

--

--