The NIMBUS journey started four years back, right after the Lodging team based in Bengaluru grew from a handful of team members to close to a 100.This team was tasked with building a next-generation lodging platform for shopping and booking hotel properties. This effort was tracked under the program named PHOENIX and the platform itself later evolved into what is today known as Content Services for Lodging (CSL).
As we all know, with growth comes the challenges of scalability. Even with Phoenix/CSL, we noticed that the processes that were working well with limited number of people started showing signs of strain. One such item was automation testing.
With multiple teams working on this, many splinters of automation testing were created, and very soon each one of these started looking significantly different that the rest. That’s when we decided to build an automation framework that would bring in standardization across all aspects of automation. This includes faster automation (data driven testing, debug), ease of execution (test case tagging), smooth analysis (html reports) and post execution metrics (result analytics).
Why name it NIMBUS?
When we started this effort, we realized we were building something that can also be used outside the scope of the program (PHOENIX) we were working on then. We wanted to choose a name that would be closely associated with the program, irrespective of where it will be used in the future. PHOENIX, which is an immortal bird in Greek mythology, has always been associated with a halo around its head – called NIMBUS. That name seemed appropriate for the framework that we were creating.
Hurdles Along the Way
There are many ways to go about building a framework, but we wanted to achieve it in such a way that there is no dependency on the current project/component(s). Hence, we relied heavily on the extensions that SoapUI provides called Event Listeners.
The best thing about this approach is that the framework elements completely run in the background, making any existing project instantly realize few benefits of the framework, without any additional changes. To achieve this, we had to understand the ins and outs of the SoapUI workflow; the fact that SoapUI had an open-source version of the tool helped us tremendously.
Packaging this framework in a way that eliminates the need to do many manual steps to onboard new project(s), was another challenge. We went through multiple iterations over a period of three years, to arrive at the way NIMBUS is packaged currently, which makes it extremely easy to launch and use.
Key Features and Benefits
Some of the areas where NIMBUS helps add value is a s follows:- Faster Automation: Data-driven testing, makes test automation faster by parametrising the tests, and feeding data sets from an excel sheet
- Ease of Execution: Tagging of test cases and choosing what to execute via run time parameters, allows great flexibility during execution, making it a great test framework for CI/CD integration
- Powerful Reports: NIMBUS creates simple and efficient HTML reports for every execution, without having to make any changes to existing SoapUI tests
- Results Storage: The tool exposes data storage capabilities of ‘Extent’ reports that paves the way for building analytics capabilities, and determining the effectiveness of test executions