When we think of Gateway Migration, most leaders still envision a straightforward process: move the routes, update a few configurations, push it live, and move on. But beneath the surface, a botched migration can cause silent damage: lost trust, security holes, and operational slowdowns that compound quietly until they explode. 

Why do so many businesses fall into this trap? It’s because they see gateway migration as purely technical. Something for architects and DevOps teams to figure out in their corner. But the truth? Every migration is a high-leverage moment. It touches your customers, your brand, and your future growth. 

The Real Problem: Outdated Migration Mindsets 

A traditional API Gateway Migration is like trying to replace your airplane’s engines mid-flight. Without any clear instructions and using tools you don’t fully understand. 

Companies rely on manual processes, patchy documentation, and scattered tribal knowledge. They think they can simply replicate what they have, move it somewhere else, and expect it to work. But when you do that, you risk so much more than downtime. You risk your reputation. 

I once spoke to a CTO of a fintech company who described their manual migration as “building a new house without a blueprint, while trying to host a dinner party in it.” They lost customer trust overnight due to authentication errors and saw a 15% churn spike within weeks. 

Let’s be clear: your API gateway is not a back-office utility. It’s your frontline. It’s how customers experience your product;  from login to checkout. Every request passes through it, every second of uptime matters, and every vulnerability is a potential headline risk. 

The Hidden Costs of a Broken Gateway Migration 

When you think about Gateway Modernization, it’s tempting to focus on new features and shiny dashboards. But consider what happens if the migration fails or drags on: 

• Downtime and Lost Revenue: Every minute of downtime chips away at your bottom line. For large e-commerce platforms, a single hour of downtime can mean millions in lost transactions. 

• Broken User Journeys: Imagine a customer trying to check out and running into a gateway error. Or a partner API integration failing silently. You lose them and they rarely come back. 

• Security Risks: During migration, outdated configurations and manual processes create gaps. Attackers look for these windows. One overlooked misconfiguration can lead to data breaches, compliance fines, and brand damage that takes years to repair. 

• Opportunity Cost: Your teams get stuck firefighting instead of innovating. They spend cycles patching issues, troubleshooting errors, and rolling back partial migrations. Meanwhile, your competitors ship new features and capture market share. 

The worst part? Most of these costs don’t appear on your financial reports right away. They appear in the form of slower product velocity, lower NPS scores, rising customer support tickets, and gradually declining market relevance. 

Why Most Gateway Migrations Fail 

Traditional gateway migrations fail for a simple reason: they depend too heavily on human memory, manual scripts, and rigid one-size-fits-all approaches. 

Many enterprises believe they can simply “lift and shift” configurations. But APIs aren’t furniture. They’re living systems with interconnected policies, security layers, traffic rules, and rate limits. 

Manual migration often looks like this: 

• Copying JSON or YAML configurations manually. 

• Running untested scripts with partial coverage. 

• Fixing errors reactively during live traffic. 

• Relying on individual knowledge rather than systemic visibility. 

This is like trying to change the foundation of a skyscraper while tenants are still living inside. All without an architect’s plan. 

Why “Lift and Shift” is a False Economy 

The illusion goes like this: “If we just replicate configs, it’ll be fine.”
The reality? APIs are not furniture you can move from one house to another.  

They’re living organisms: arteries and veins carrying the lifeblood of your business.  

They evolve constantly: new rate limits, layered security tokens, policies shaped by customer traffic, regulatory changes, and partner demands. 

When you treat migration like copy-paste, you ignore the invisible dependencies that actually keep your system alive. 

Think of it this way: trying to “lift and shift” a gateway is like trying to replicate New York City by drawing its roads on a map but forgetting the plumbing, the power grid, and the telecom lines. On paper, it looks complete. In practice, the city collapses the moment people move in. 

Enter GUS: The Gateway Utility Service 

GUS doesn’t copy. It diagnoses, understands, and redesigns. It flips the script by treating migration not as a mechanical task, but as an engineering transformation. 

Think of GUS as an architect who refuses to renovate a skyscraper until he’s audited every load-bearing column, every fire exit, every piece of wiring. The tenants don’t feel a tremor but the building emerges stronger, safer, and more valuable than before. 

How GUS Works: 

• Extraction & Analysis
  GUS doesn’t just scrape configs. It performs a forensic deep dive into every route, token, and policy. Every shadow dependency is dragged into the light, mapped, and assessed for compatibility. 

• Tailored Migration Framework
  Unlike rigid scripts, GUS adapts. Whether you need blue-green deployments, zero-downtime cutovers, or microservice-friendly designs, GUS bends to your business. Not the other way around. 

• Secure & Private
  In industries where compliance is non-negotiable, GUS runs entirely on-prem. Sensitive data never leaves your infrastructure. You modernize without opening new risk windows. 

Case Studies That Prove the Point 

• Payments Giant
  A global payments firm sat on 2,000+ routes they were terrified to migrate. With GUS, the entire move completed in 14 weeks without a single catastrophic incident. The payoff? 

• 40% faster checkout flows 

• 25% reduction in infrastructure costs 

• 60% fewer API-related support tickets 

• Telecom Provider
  This telco wasted two years and millions on manual attempts. Each “lift and shift” iteration broke in new ways. With GUS, migration time dropped from 18 months to just 5 months. They also escaped vendor lock-in that had quietly cost them innovation for half a decade. 

• Healthcare Firm
  Compliance audits had become a nightmare after every change cycle. Post-GUS migration, the firm passed audits with zero exceptions. Saving them from both regulatory fines and reputational fallout. 

The Strategic Advantage of Gateway Automation 

API Gateway Automation is not just “faster.” It is leverage. 

• Automated audits surface vulnerabilities long before go-live. 

• Consistent, repeatable deployments slash defect rates. 

• Dynamic policies adapt in real time to changing traffic. No midnight patches, no duct tape fixes. 

This is the difference between firefighting every month and iterating every week. Between survival mode and growth mode. 

The Cost of Doing Nothing 

Delaying modernization is not “safe.” It’s compounding risk. Every month spent on a legacy gateway is another month of: 

• Lost Deals. Partners walk away when integrations fail. 

• Innovation Lag . While competitors ship features, you patch holes. 

• Cultural Decay. Teams begin fearing change instead of driving it. 

One CTO put it bluntly after his firm’s migration failure: “We didn’t just lose uptime. We lost ambition.” 

Build the Future, Not the Past 

Gateway modernization is no longer optional. It’s foundational. With GUS, migration transforms from a liability into a growth lever. 

Here’s the offer to every leader reading this: 

• Audit your configs before they break in production. 

• Automate migration to protect customer trust. 

• Build a backbone that not only supports innovation but also accelerates it. 

Wrapping Up 

 Modernisation isn’t about keeping the lights on. It’s about laying the runway for your next decade of growth. And with GUS, that runway is clear, reinforced, and wide enough to carry your boldest ambitions. 

You can get Gus here: https://www.sandhata.com/contact-us

The post The Hidden Costs of Poor Gateway Migration And How to Actually Fix Them appeared first on Sandhata.

The post Sandhata’s DevOps Mastery: Digital Evolution Starts Here appeared first on Sandhata.

The post Unlocking Techno-Strategic Synergy: Solving Digital Dilemmas for Exponential Success appeared first on Sandhata.

When a single throw event is triggered, the data is processed without any issues. However, if multiple message events are thrown simultaneously, only the first one is successfully processed, while the others fail.  

This is because the message catch event is busy handling the first message event. 

We recently spotted this issue with Camunda 7’s message catch event. 

Unlocking The Solution To This Challenge 

Our team of experts fabricated a groundbreaking “Generic Message Buffering” logic, with which we’ve revolutionised the way messages are processed asynchronously, effectively resolving any scenario you may encounter.   

Fig. 1.1 unveils the powerful list of message catch events eagerly awaiting the trigger. 

Fig1.1

 In Figure 2.1, we present the logic for Generic Message Buffering. By sending a POST request, we can activate the BPM process described below. Additionally, we have the ability to specify the retry count and retry delay as request parameters. Once the request is triggered, we conduct a basic validation to ensure all necessary information, such as message name, payload, process instance id, and business key, is present.  

If all the required data is available, we proceed to send the message to its destination within the “Message Send Task” depicted in Figure 2.1.  

If the message is successfully picked up and processed by the message catch event, we encounter no issues.  

Fig2.1

In a situation where the message catch event is already occupied processing another message, throwing our own message will result in failure. This is a common occurrence in real-time scenarios, and it is up to the developers to determine how the flow should be handled in such cases. 

In our specific case, the failed message will be caught by the boundary event. The error message will then be examined in detail within the “Read Error Message” process (Fig 2.1). 

In the event of an error, we can:  

• Distinguish between errors that require retry logic.  
• Determine if it is a business error or a technical error.  
• Necessitate the involvement of technical experts, if it happens to be a business error 

When encountering a retriable error, we make an attempt to retry the operation. The number of retries and the delay between retries is determined by the input request. 

Potential Scenarios In Re-try

In the context of re-try logic, there are two potential scenarios to consider: 

• In one of the re-try attempts, the message can be successfully delivered to the end system. 

Fig 3.1

• Alternatively, if the maximum number of re-try attempts is reached without success, the message will be marked as an error. 

 If the maximum re-try attempts have been exceeded and the message still hasn’t been delivered successfully, it will require manual re-processing (see Fig 3.2). 

Fig 3.2

  Key Advantages  

• Streamlined Error Handling: By effectively managing busy message catch events, we can significantly mitigate potential errors during data processing. 

• Efficient Data Re-processing: Our approach allows for a substantial reduction in the amount of data that needs to undergo re-processing. 

• Versatile Solution: Utilizing the same bpmn models, we can easily adapt and apply them to various similar use cases simply by modifying the message name. 

 Optimizing Efficiency 

 In order to optimize efficiency, it is vital that both the target BPM and the message buffering BPM are connected to a centralized database. This will allow for seamless integration and streamlined performance. Maintaining a unified database instance is key to achieving optimal results. 

The post Generic Message Buffering | Camunda 7 appeared first on Sandhata.

Tell us a bit about yourself

Hello, my name is Janani. I am from Chennai, India. In September 2020 I graduated from Dr. MGR Educational and Research Institute University with a degree in Engineering BTech (Information Technology). I really enjoyed my studies and am very proud to have secured the 2^nd highest marks in my year.

During my course, I studied SQL, Java, Web Development and also achieved Prelims Level in “BEC – Business English Certificate”.

What did you do once you graduated?

During the COVID pandemic, getting job as a fresher is like “a tough row to hoe”. [Note: See Janani’s Tips & Tricks for Freshers post.] But without losing hope and I continued searching and eventually found a job in a logistics company as “Executive Documentation – Back End”, which is a non-IT industry.

Even though this wasn’t my first choice of industry I threw myself into the role to gain knowledge and skills and learnt everything I could about shipping and logistics.

How did you come to join Sandhata?

Though I had a job now, I knew I wanted to work in IT, so I kept my IT skills up to date, and kept my profile active on all job sites as well as social media. Soon, by God’s grace, I was contacted by a recruiter and managed to get this role at Sandhata as “Trainee Analyst”.

How was your experience joining Sandhata during COVID?

I found the joining experience very smooth. I was happy and excited to receive my laptop and joiners kit before my start date! Whenever I had any question or needed support I reached out and got help quickly.

Which projects have you worked on since joining Sandhata?

My first task upon joining Sandhata was on web development, in which I got to use my skills gained at university. I have also worked on some internal Sandhata projects where I have made strong connections with my team mates and gained skills such as GIT, UI testing, HTML and more. During each of my different initial projects I was asked to deliver a mock project to test my knowledge and deepen my learning on each topic.

Recently I was posted to one of our clients where I joined a team working as a microservices developer on an exciting microservices project. It was so interesting, and I got exposure to tools such as Splunk, Kubernetes, JIRA, Postman, Hibernate, Maven, and Spring Boot. I have also worked on presentations and documents to help onboard other people to join the microservices team smoothly in future.

What is next for you, Janani?

I have recently done a certification course on Responsive Web Design and I am hoping to gain skills in other areas too, for example test automation, CICD, Integration, as well as presentation and writing skills.

“My time as Sandhata so far has nurtured my skills, helped me to gain confidence and realise how I can make my maximum contribution to Sandhata and our clients.”

My experience and perspective have broadened and the training I have provided others has strengthened my skills in many areas. Thank you, Sandhata, for supporting me.

Learn More

If you are interested in joining Sandhata, check out our careers page for the latest job openings and how to contact us.

The post We Are Sandhata – Meet Janani appeared first on Sandhata.

What is meant by Minimum Viable Product (MVP)?

A product which is delivered with just enough features/capabilities to satisfy a subset of users and validate a business use case. Once the product is released, the subset of users will provide feedback which will drive the direction and delivery of subsequent features (or halt development if the product does not appear to have viable business value). Products generally follow an iterative deployment model, and the product evolves through multiple deployments before the product is seen as ‘complete’.

Why is Minimum Viable Product such a powerful idea?

1. There is less upfront investment required.

Being able to deliver a product to real users without high upfront resource and system cost can often make the difference between being able to release a product and not! Where there is a low budget, creating a minimum viable product may be the only way you can deliver to real users.

2. You get fast feedback!

By releasing a working product to test you get real feedback from real users. This enables you (and them) to learn how they actually use the product rather than how you think it will be used or the capabilities discussed during requirements gathering. This is super valuable. You will also get hands-on experience from the activities required to deploy and run your product and may notice something which hadn’t been considered before.

3. It will help maintain momentum in your project.

When developers have their work used by real users and they get real feedback on it, it is very satisfying and motivating. Similarly, from the users perspective, being able to use a new product quickly and have a visible impact on the direction of the product is rewarding for the users and they will have renewed buy-in in the product.

4. You can check the business viability of the entire solution.

The purpose of Minimum Viable Product is to test business viability. It means we are able to validate what we are delivering. Is the product what we need? Does it deliver what we hoped it would? Will it solve their problem? Is it fit for purpose? How does it need to evolve? If we don’t do this business validation, we risk investing a lot of time and effort in a solution which may not satisfy the business need.

5. You can confirm (or reject) your hypothesis of the most important features to the user.

Real experience will inform your understanding of which features are really critical to users and therefore which features should get maximum focus during UX design and testing.

6. It gives you a better understanding of the product compared to spending more time on upfront design.

Spending time on product design is important of course, but no matter how detailed the design is, it is never possible to think of every user scenario at the design stage. You will be able to make better decisions about your product based on real world feedback and your understanding of how the product actually functions, compared to more thorough design and how you imagine your product will function. This helps greatly when planning future development work on your product, giving you much more confidence when designing and estimating enhancements.

7.  You can evolve your product over time to achieve a better end product.

Delivering a product to a set of users and getting feedback enables you to change and evolve the product design based on your experience of building and running it.

8. It is easier to spot features which are NOT required.

During the requirements gathering phase, lots of product features / ideas will inevitably come up (“Wouldn’t it be nice if…”, “How about we build something which can…”, etc.). It can be hard to get to the bottom of which features are mandatory and which ones are nice to have. We may end up over-engineering the solution and delivering things which aren’t really needed by the client or won’t add much value. By delivering an MVP quickly, both the project team and the users have got a much better foundation on which to decide which features are actually necessary in future iterations of release. Needless to say, the smaller, simpler, and less dependent the product is, the less development, testing, documenting, handover, deployment and maintenance is required.

9. You can validate the root cause of a perceived issue.

You may identify that something (which has previously been considered a problem), isn’t actually a problem which needs addressing. For example, perhaps the previous consensus was that a particular feature needs to be rewritten in X language (e.g. moved off mainframe), the MVP will give you the opportunity to validate the real root cause of this issue.

10. Batch sizes will be smaller, and you can deploy more frequently.

Delivering a smaller (lighter) product will enable you to make more frequent deployments as there are fewer moving parts. This aligns with reducing batch sizes allowing an iterative approach to product delivery, in line with DevOps principles.

11. Enable a culture of continual learning and improvement.

Following the MVP approach encourages a culture of experimentation and therefore learning for the whole team. This will result in better employee engagement, improved skills and ultimately better business outcomes.

12. Increased job satisfaction.

There are few things more motivating for a developer than seeing your hard efforts quickly rewarded with real users using your product and gaining value from it.

From reading the long list above, you may start to think that adopting the minimum viable product approach will solve all your problems! But this isn’t completely true.

Here are a few things you should bear in mind to ensure the MVP approach works for you:

1. The scope of the MVP needs to be such that is enables you to assess the business viability of the product. If the product has too few features or poor UX and users do not use it, then it does not serve the purpose of the MVP.
2. Make sure you consider the product end goal when choosing the technology and architecture solutions. Otherwise you may get to the point where you cannot iteratively deliver the features required without redesigning part of your system.
3. Receiving feedback on the product and evolving the product needs to be seen as an expected part of the project delivery and planned for accordingly. If no further changes are made to the MVP, then it is just a product, not a minimum viable product!
4. If your system does not utilise deploy and release automation, or if you are not able to use consistent, available environments you may find that the cost of release is quite high. In this scenario, multiple iterative releases (as required for an MVP) may result in high costs and overheads, reducing the value of smaller batch sizes.
5. If your product does not pass the business viability check, you should abandon the project. This means the effort spent on this MVP will not result in any business value. However, you may have saved yourself the effort of building and delivering the full solution before coming to the conclusion that this product is not useful.

Overall there are many ways in which an MVP approach can be beneficial for you and your business, however it is not a magic bullet. I suggest you take each scenario on a case by case basis and find what works for your project.

I hope that seeing your project objectives through the lens of the MVP approach will give you an alternative perspective and help you to find more ways of delivering quick wins for your project. Good luck!

The post Do you want to achieve quick wins? (Hint: Focus on Minimum Viable Product) appeared first on Sandhata.

The DevOps Innovation Platform project was launched in August 2016. We began by building a very simple application, called Sandhata Bank, using public APIs available from the Open Bank Project. This meant we didn’t have to build an entire banking back-end.

The foundations

The first few weeks were spent designing and building the environment, configuring our Docker setup, and building a Continuous Delivery pipeline framework using Jenkins.

From there we have continued to integrate open source tools, including:

• Gradle for build automation
• SonarQube for quality control
• Junit for unit testing
• Karma and Selenium for web testing
• BIRT for transactional dashboards
• Zabbix for monitoring

Enterprise products

Once we had a good working open source model, we started to incorporate enterprise-licensed products. We have analysed the market and sought to include the products we believe are industry-leading in various areas.

So far, in addition to the many open source products, the Platform features:

• AWS as a cloud provider
• digital.ai Deploy for deployment automation (formerly XebiaLabs XL Deploy)
• digital.ai Release for release management (formerly XebiaLabs XL Release)
• IBM Rational Test Workbench for Message Based Test Automation & Service Virtualisation
• CA DevTest for Test Automation & Service Virtualisation
• TIBCO BWCE for micro services
• CA Test Data Manager for test data management
• CA Agile Requirements Designer for Requirements Modelling & Test Case Design
• CA API Gateway or API Management
• TIBCO Spotfire for KPIs and business intelligence

DevOps principles

From the very beginning, we have followed DevOps principles of continuous improvement and collaboration in working as a team. We started out using Phabricator as our task management system, while following Agile practices (sprints, scrum meetings etc). We have since progressed to using Agile Central as our task management system as it offers more mature features.

This open way of working has allowed us to evaluate more than 30 different tools and has given each team member responsibility for their area of focus and the tools available.

The DevOps Innovation Platform project has been a great opportunity for every member of the DevOps Platform team to work with many new technologies and gain a real breadth of skills. Each person has been involved in researching the wide spectrum of new technologies and building POCs to gain deeper understanding of the products, whilst helping to ultimately decide which tools should be included.

Continuous customer feedback

I personally have found this process incredibly interesting, and a great opportunity to get my hands on some of the hottest tools around. With each tool and process addition to the Platform, we have demonstrated these to our clients, and their feedback has kept us eager to keep going.

Our conversations with clients and partners have been so enriched by this Platform, as it allows us to easily demonstrate our understanding and experience of each focus area, that it is a springboard for meaningful discussion.

Plug-and-playground

The other brilliant aspect of this Platform is that it is a working, complete real-life application ecosystem. So when new tools come along, we already have the perfect playground to download, install, and play around with the tool to get up close and personal with it. As we already have hands-on experience with the tools, we can provide better, completely personalised advice to clients based on our breadth of experience with the different toolsets available.

We are working on enhancing the Platform as I write, and adding new features and tools all the time.

I look forward to keeping you up to date with our new additions as they come through!

Want to know more?

Take a look at the Platform page or contact us on +44 20 7680 7105 for a no-obligation product review.

The post How we built a Live DevOps Innovation Platform appeared first on Sandhata.

A passion for technology

Technology has always fascinated me. There is something almost tantalisingly powerful about it that draws me in. So, entering into IT was a choice I made purely out of passion – unlike countless others. I’ve was pretty sure about this choice even in high school and I have not regretted it once.

From high school to college

As I’ve always been pretty strong-minded about my goals, choosing a focus in high school was a piece of cake. Two years of dedicated hard work later, I secured the score I wanted and then decided to continue my learning journey. I started pursuing B-Tech IT at Panimalar Institute of Technology.
For me, as for most people, the college years were the best times of my life. College taught me all I needed to know to start off a career in the realm of IT, equipping me with sound knowledge in UNIX, Java, JMS, and admin support. I trained to become a software test engineer working on various stages of testing across the project lifecycle.

Choosing a specialism

If there was one thing I was sure about, it was this: The world outside of college – especially the world of software engineering – is peppered with competition. I knew I needed a little something “extra” to create a place for myself in the job market. I spent a reasonable amount of time researching and exploring the options available to me, and eventually narrowed it down to the field of Analytics. Hence, I went for a post-graduation in Business Analytics at SSN College of Engineering. That’s where I was introduced to the world of Big Data Science; the art of interpreting numbers and coming up with innovative solutions to various data related issues. The tools I came to learn included R, SAS, MYSQL, and Excel.

Life and career at Sandhata

I’d done my graduation and post-graduation, both with honours. Now I was equipped to step out into the world.

Being selected to work for Sandhata Technologies has been a bonus in more ways than one. It has given me the perfect head start in my career. Also, as a Sandhata consultant, I’m exposed to an array of responsibilities and diverse experiences. Currently, my work is focussed on testing as a QA Engineer, helping to deliver projects within tight deadlines. I’m learning a wide range of new technologies, and I am already a Certified Associate Developer in RIT.

Life at Sandhata is a mix of wonderful things. There is so much to look forward to. The work culture here is amazing and I’m happy to say that I’m one of those few fortunate people who have managed to make great friends in their workplace. My colleagues are fun and my superiors are very friendly.

Choices make the future

I really must say that so far, the choices I’ve made in my life and career have always led me to where I want to be. From high school to workplace; I’m happy to see how far I have come. But still, my journey has just begun. There are many more cross-roads yet to come, and lots of choices to be made. Whatever our journey looks like, I’m sure we can all learn some valuable lessons along the way – and make the career choices that are the best for us in the end.

Learn more
Want to know more about Sandhata careers, or discuss how we can support you through testing and project delivery? Contact us to have a conversation with me or one of our other experts today!

The post From College to Career appeared first on Sandhata.

The first input for anyone involved at the ground level, be it a tester or a developer, is the functional specification. A developer goes through this functional specification and usually there will be a few rounds of brainstorming or discussion sessions to understand the requirements so that they can come up with a technical design. A tester goes through the functional specification and comes up with a test plan document detailing the level of coverage, when it will be tested, in scope and out of scope items, any assumptions or limitations, acceptance criteria, and so on. Just like a technical design is input to the actual development, a test plan is input to the actual test scripting that happens later on. So, at this level, it’s pretty much a similar path for both a developer and a tester.

A developer develops the solution based on the design document. The tester, however, needs additional inputs before they can develop the test scripts. This is the design document. The design document is an important additional input to a tester. It helps the tester to understand the solution intricacies and reaffirm or revisit the touch points for the testing tool to the solution. It also helps in scripting new scenarios, thus improving test coverage and solution reliability.

From a developer’s point of view, any additional checks may not feel very important. When a developer unit tests a solution, to be honest it goes with a few assumptions about the code they developed, such as a mandatory field will always have a value; database connections will always be available. A tester, on the other hand, has to consider the solution from a what-if perspective. What if the field does not come at all? What if the database connections are not available? These questions, when posed to a developer, help to build a robust solution that handles all possible scenarios gracefully.

This what-if approach is one important skill I learnt when working as a tester. When back into development, it helped me to build a solution that handled scenarios gracefully. Even for a single field addition, I now ask the questions: are there any scenarios where this field may not be part of the input at all? how is it expected to be handled? is this scenario handled in the source system or is it handed in the target system? As a result, there is no scope for a missed valid or invalid scenario.

The other area of improvement I noticed after my stint as a tester was the way I looked at my unit testing scenarios. When unit testing, we tend to create one test case and modify the inputs to test the scenarios. Or we create multiple unit test cases. With the one test case approach, I would not have the input data for all the conditions that I have covered in unit testing. With the multiple unit test cases, in few cases it leads to redundancy. In the automation testing tool that I have used, we had a possibility of data driving the tests. So you always have a record of the data you have used in testing. I have taken this point into my unit testing and I now try to data drive my unit tests wherever relevant so that I have a record of the data I have used for testing. Before I start my unit testing cases, I pause to think. Is there a possibility of data driving my unit tests? Or would it be a better approach to have individual cases?

Another area that I felt was largely ignored but extremely useful was discussions between a developer and tester. It is only when the tester raises a defect that the tester and developer actually interact to resolve the issues. Some of the scenarios scripted by the tester could be invalid and some of the defects raised by the tester may be incorrect. So, there is a lot of friction between a developer and a tester when testing commences. But both these roles are important and both work towards a common goal. I have personally seen a lot of benefit when a tester is involved in discussions with the developer and involving testers in discussions as a developer.

My perception of testing has changed a lot after this experience. It helped me to understand how a functionally competent tester can help to improve the overall product quality. This blog has been from a middleware interface automation testing perspective. Hence, some of the documents or terminologies used might be different to a general application testing and development perspective and management levels.

Want to learn more? Download our technical paper Test Tools and SAP.

The post Testing from a developer’s perspective appeared first on Sandhata.

Although many custom tools in the market will integrate with most of the test automation tools to create customised reports, an open-source tool is an obvious choice to begin with. For our requirement, a business intelligence and reporting tool (BIRT) is the best fit as it is an open-source Eclipse product, it doesn’t need advanced web application development skills and anyone with HTML, JavaScript or Java knowledge can build the reports and deploy them to an application server to be able to access the data via a browser. With BIRT, you can create a variety of reports such as lists (with relevant data grouped), documents, charts and so on.

BIRT architecture has two main components – report designer and a runtime component. The latter facilitates the design’s deployment on to an application server such as Apache Tomcat. An additional chart engine component exists for integrating charts into the application (I haven’t still explored this feature yet). For proof of concept, I have downloaded Eclipse Mars 4.5 that comes with BIRT designer. If you have already installed Eclipse, you can download the BIRT plugin. Depending on your data visualization needs, you can either design a report with the sample templates or start with a blank page and add items from the palette in the designer via drag and drop. Also, you can create a library for reusable custom templates.

In a nutshell, there are three main design steps. First, create a data source for report. I have to connect to an Oracle database (which is where our automation test tool publishes the results) although BIRT supports multiple data sources such as web service, an xml file, a flat file or even another application that can provide you with relevant information. Second, create a data set such as a query to get the required information from the data source. Third, create the page design to present the information in an efficient way. You can also create HTML links to navigate between multiple reports or add filter/sort criteria on the data to be viewed. I have created a web page that will present a form to the user (containing list boxes and a calendar widget to select the dates) to help them to select certain criteria based on what information will be gathered or grouped in the background. The best part of the tool is the support for JavaScript /Java. You can customise the page, for example by adding event handlers on the user operations or add any validations or calculations to be performed, before presenting it. Eclipse enables you to preview the report using an HTML browser.

There are different packages available to download BIRT runtime. I chose to download the BIRT sample viewer WAR file from the BIRT site and deploy it on the Tomcat server. The sample viewer adds web-based viewing capability for BIRT designs, which means it takes care of basic functionality such as a table of contents, pagination, exporting the results to PDF and so on. If you wish to enhance the existing viewer, you can download a suitable runtime package. Since I’m working on a very basic requirement, I have added sample viewer to my Tomcat server and copied my report design to the Tomcat’s webapps directory. Once the Tomcat server is restarted, the report can be accessed via a browser. These are a few initial basic steps, and many features of the product can be leveraged based on the requirement.

BIRT reporting can be very useful, especially in continuous integration scenarios such as when multiple regression test packs have to be run before releasing the software to next level. It enables the management team to make informed decisions quickly based on the current test status. However, BIRT is not just limited to reporting, it can also be utilised across various SDLC phases where data visualisation is vital.

The post BIRT for Test Reports appeared first on Sandhata.