In-house Tool for Performance Testing

In the software development cycle, testing is one of the important criteria. There are many tools available in this space for testing such as Junit, Jmeter, manual, automation, and many performance testing tools. Some of these tools are third-party tools and have a cost-heavy license for the company to manage. For small start-up companies, these license costs can be unbearable. We analyze a tool to make the process easier and more cost effective. 

About the Tool

Every team and company has different requirements and applications built out. The objective is to create a tool in the most customized way which is easily configurable and expandable to test current and future applications.

The tool can have two parts. One part can be making a main interface web page where developers/testers can fill in the details and start testing. The other part can be the onboarding template page, where the team can onboard new applications, templates, and stacks so that it appears on the main interface page.

Testing Tool Main Interface Page

The testing tool main page can include a form that consists of things like app name, duration of the test, number of transactions per seconds, and by selecting app name, it should give options of data that this app needs to condition. Finally more importantly which stack is intended for testing, it can be mq, Kafka Kafka, any RDMS or NoSQL or Big Data table, or any rest API too, or as simple as hitting an application with the request.

Behind the scenes, this page can be developed using any UI framework like HTML, javascript, or react.js, or using angular js.

This can be a simple restful web services application running in any cloud container. The web service just takes all the details that the tester submitted, and classifies which stack it needs to target. After that, build requests accordingly and use simple Scheduler Executor frameworks for running for a certain duration and configuring thread pools and hit targeted stack/destination until the duration and transactions achieved in the loop.

If the intended app is running, it should be getting the request, you can validate your test or also monitor the performance of your applications. For example, if your actual MQ is a consumer of the queue, then this tool publishes messages to that MQ queue, and your app should be receiving those messages. Another example, if your app is reading hourly data from Mongo DB or hive table, your tool can load data in those tables, and your app whichever reads data from this table can be tested.

Onboarding Template Page 

In this section, we can go through how to onboard the template. For example, you are testing application A, your application A is a Kafka consumer streaming application, which reads from the topic a certain JSON format data, for the tool to test this app we must push the messages to that Kafka topic with expected JSON structure and format.

As illustrated in the sample picture, the Onboarding page should have details in the form like app name, template your testing, in this case, it is JSON, you will provide sample JSON format that this app is looking for. And followed by your onboarding page will have sections like what fields in the JSON you want to customize, and also put features like validations, etc. And then more importantly what stack it is intended to test, in this case, it is Kafka, so you can specify Kafka's topic name and also env. In some places, not all users will have access to publish on that topic. So there will be pre-requisites steps to follow, for your test user it an individual user or an app-specific user you have to get access to. Once, all this is met we can onboard this complete information like a template, you can either store this template information in a specific test database or simply put it in S3 like a key-value, where the key can be app name and the value can be entire template information in JSON format you design.

This onboarding app can be hosted in a simple cloud container or any webserver. The technology that you can use to develop these tools are – for UI components you can use react, angular or simple HTML and javascript. The server-side code could be a simple rest application, where it intakes onboard requests, and puts them in any data store, can be a database or S3.

Teams can onboard their application template and stack to test. Now when the main testing tool interfaces page loads, you can select the app name, and load all details prefilled like what fields it whats you test, stack, env, topic name, etc. You can now select the duration and transaction per second and test.

If you have noticed your main interface page make a get call based on the app name you selected, and get those template information from S3 or wherever you stored. Both pages are tied together, this unique idea can give more flexibility in adding more and more apps to test. The illustrated pictures just a sample mocked page for you to visualize the context of what this article is talking about. More features can be added here and make it more customizable and configurable for your testing needs and purpose. This tool servers multiple target areas for testing that can be used for testing certain use cases or can be used even for stress and load testing.

Benefits of These Tools

Now let’s say you are developing an app that is intended to target geographically many customers. For instance an eCommerce website, how would you know your tool can sustain peak volumes. Without benchmarking and testing the load, there are high chances it will crash and will end up with a bad reputation. Now most companies do realize this and they use licenses Softwares like BlazeMeter, Jmeter, etc. do this. But in most cases, you don’t need to bear the high licensing costs if you already use this idea and used it as your own in-house tool. This tool allows you to perform tests on your app similar to production volume and sees how it sustains. This gives you a chance to tune your applications.

You would be interested to see whether my app can read huge volume data, any issues, or do we need to tune the code, etc, all these factors can be nailed out. This will help to put your app in production with the right resources and capacity needed to support your live customers. This saves the reputation and cost of the company.

Another area this tool plays a significant role in big data, machine learning, and artificial intelligence side, how do you know your Artificial code is fast enough to render information that customer is looking for. Over billions and billions of data stores in bid data stores, how can you achieve faster response time and service level agreement time? This is where these tools can come in handy where you can load billions of data in those tables and see how your lookup works. Depending on the results you get a chance to restructure or tune the code.

Other than cost and reputation advantages, one more significant advantage is time efficiency. This tool helps so many tests to run simultaneously and fastens the testing cycle. Saves time for developer and tester as they no more needed to write a special test code targeting different apps. All they have to do is onboard the app they want to test, specify the required template, stacks and they are good to go.

Another advantage of eliminating dependencies, in most organizations there has to be some level of engagement to get load testing done, it's either handled by a separate team or an external vendor team. It is sometimes hard to get that resource time and alignment and teams struggle in this process bottlenecks. With this tool, you can use and run the load test whenever you want without any dependencies and this saves indirectly your time too.

Finally, this article is intended to give hints on how the teams can be self-reliant and use these kinds of tools which saves companies time, reputation, and lots of money. This is a basic idea but this can be expanded and used as per individual team needs.