Great! :)
Thanks, we'll contact you soon.
Imagine you're a financial services company facing the urgent need to modernize a 20 year-old legacy desktop app. Said app is used daily by employees and is integral to their work; however, the application is at its breaking point, begging to be transformed into a modern-day web application.
Here are the challenges with this sort of undertaking:
In the world of web development, there are specific best practices associated with the buildout of a web application. The website development life cycle typically involves a lengthy process of information gathering (main goals, target audience, purpose, etc.) followed by the construction of a sitemap and wireframe; design of page layouts, review, approval; content creation; and finally, development.
Since this is a real story, we will share the approach we took to overcoming these obstacles, thereby illustrating an intriguing case study in modern-day web application development (read more about the case study here).
We leveraged two dynamic methodologies to solve our client's conundrum: feature level testing and test-driven development (TDD).
Feature level testing involves updating a piece of software with new features designed to make the product more useful, intuitive, and effective. Post implementation, proper testing of said new features is essential to the product's continued success. A classic example of a renowned brand performing feature level testing is Facebook, as they release a new, upgraded version of their web and mobile apps frequently.
In traditional software testing, code is developed and then tested to ensure it passes specifications. Test-driven development (TDD), however, employs the approach of writing "just enough" code in order to pass the tests. TDD is essentially developing and running automated tests before an application is developed; the purpose being to make the code clearer, simpler, and bug-free.
This article documents exactly how we engaged and worked with our financial services customer and leveraged the advantages of test-driven development and feature level testing to transform a 20 year-old piece of legacy desktop software, integral to the business and daily productivity of the employees, into a modern, integrative web application.
This story begins in 2011 when we partnered with our customer, a financial services firm in San Diego, to build their customer-facing website. Our quality work successfully launching their website opened the door to our second project, transforming a legacy desktop application into a web application. The focus of our second web app development project was updating an internal system used daily by our customer's employees.
Our customer was in a complicated, time-sensitive situation as they required employees to switch to the new application on a very short timeline. We were confronted with the dilemma that if anything were to happen to the original desktop application, our customer's employees would no longer have access to the system.
The internal legacy desktop app was originally written in Visual Basic 6 (Microsoft ended support in 2008) and run on Windows XP (Microsoft ended support in 2014). Furthermore, this desktop app was cumbersome; the original app utilized hundreds of screens with integrative tabs linked to an online system and directly to a database. Our only resources were the source code itself and access to one of the original developers. The difficulty of the project was compounded by the fact there were no requirements for building the new application.
Our goal in building our new app was to replicate the original desktop app's functionality and update the technology stack using Angular 7 on the front end, web API and .NET Core on the backend, and SQL server for the database. The new web app's purpose was to ensure a more integrated experience between the old desktop app and SalesForce, the two systems employees used daily. The app needed to allow employees to quickly open multiple screens and switch seamlessly between them without losing their place much like they could in a desktop application.
As a well-established software development company, we have an iterative agile workflow and set of best practices we implement to produce elegant applications sure to please our customers.
Best-case scenario, our customer has its own business analyst team available to help identify new application requirements. In that case, our development testing team works in parallel with the business analysts to go through test cases and ensure complete alignment, while the developers start pushing out the code. This amounts to an iterative process of synchronized testing and code development.
With very little information to work with, we endeavored to understand exactly what the app needed to accomplish. Our development team chose to implement a version of test-driven development (TDD) at a feature level, rather than a unit level, in order to come up with requirements for the new web app. Our goal was to have test cases ready in advance to assist and guide the development process.
Using test driven development best practices at feature-level led us to something a little different. Instead of using application requirements to build test cases (as is the standard), the team used the test cases to manufacture the requirements. While it may seem counter-intuitive, the idea was born out of sheer necessity--and a little bit of desperation. We were stuck!
We launched forward to gather test cases based on our understanding of the original application and the results became our version of "original" requirements. So how exactly did our team accomplish this "reverse engineering" process?
Our engineering team envisioned a scenario in which we tested the functionality of the old application and built the test cases prior to development. This "reversal" enabled our team to ask our customer's stakeholders and business analysts (BAs) more detailed questions in order to manufacture better requirements.
Fortunately, the customer had a clear understanding of which functionalities from the legacy desktop application needed to translate to the new web application. We underwent a multi-step process in order to extract these requirements and start the new web app's development process.
One of the earliest goals of our project was to switch employees to the new system as quickly as possible. In order to speed up the process, we moved certain pages from the old application directly into the new one allowing us to update the new web application's functionality quickly and seamlessly.
One of the challenges we encountered early on was how to effectively communicate our proposed changes to our stakeholders, who had expertise in different technical disciplines. We understood the importance of creating test cases up front to reveal our customer's requirements, however, we needed to demonstrate the benefits of test driven development and efficiency of our theory to stakeholders.
We were fully committed to building the exact digital web app our customer wanted. We had a tireless work ethic and a great theory on how to reverse engineer the requirements gathering process, but we also needed to determine the best method for extracting stakeholder information.
Here are some of the best practices we followed and identified as we worked through this project, which ultimately helped make it a success:
Although we started out with a different skillset than our customer's team, we found communication to be our best ally. By working closely with our customer, we were able to reverse engineer the product requirements and code them into a feature set that was exactly what they wanted.
Our initial website project in 2011 established us as a trusted business partner committed to our customer's success; however, our second project, the desktop legacy system modernization required us to demonstrate our focus, efficiency, and ingenuity once again.
We needed our customer assured we had their best interest at heart.
Here's an overview of our achievements during the process of upgrading the legacy app and developing a modern web application--one that employees were able to start using right away.
It's not every day you get to dig into a 20 year-old legacy application and upgrade it to a sleek, modern application, but our financial services customer needed their employees switched over to the new web app as quickly as possible.
The original application was written in Visual Basic 6, whose development environment can only run on Windows XP; support for these systems had long been discontinued by Microsoft, which led us to implement a solid, long-term solution.
The first big release for the application took place at the end of 2019 when we released a beta version to a small subset of users. This allowed us to test the implementation and receive feedback on the user experience and functionality of what has been built so far. Our next major milestone, the end of Q1 2020, will include the release of new UI/UX features and will be available to all end-users. This will also initiate a conversation to begin shutting off features of the old desktop application and get closer to completing migrating to the new web app.
Feedback so far has been overwhelmingly positive. The final completion date is set for December 2020. To date, we've been able to streamline the number of screens within the app by 80% as well as clean up and add several new functionalities. While the system is not yet fully implemented, we receive regular feedback from users and the reviews are positive. Our driving goal is continued enhancement of the efficiency and productivity of a phenomenal partner company.
Please sign up below to keep updated on the status of this project.
Integrant’s Vision is to transform the software development lifecycle through predictable results.