A Twist on Test-Driven Development to Transform Our Customer’s Legacy Desktop Application into a Modern Web App 


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:

  • No prior specifications available for use in building the web application
  • No business analyst available to consult
  • Only original source code running in Visual Basic 6, which was released in the 1990s and runs on Windows XP (both of which are no longer supported)
  • Only one developer from the original team who is familiar with the code

The Setup

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.


Not quite finding the right solution?

The Twist on Classic Test-Driven Development

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.


Challenges Imposed by the Upgrade Project


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.



The Standard Approach to Software Testing & Development


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.


Our Theory and Alternative Approach


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?

Feature Tests to the Rescue!

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.

  1. Our engineering team sat with our customer's internal stakeholders and SMEs to understand each obligatory feature and exactly how it should function 
  2. Our quality engineers went to work building the test cases surrounding the "requirements"
  3. Engaged in additional discussion to guarantee the test cases were on target
  4. Developers began writing the code
  5. Developers and quality engineers began testing the code against the test cases

We hear you. We want to create a solution specifically for you.

Selling a Test-Driven Development Variation


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.


Communication and Best Practices are Crucial


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:


  • We carefully determined which features were priorities and needed to be in the screen, and which did not.
  • We realized early on that many product features were changing in the upgrade from the original app to the new web app. This led to high-level discussions with upper management, helping us identify what was in scope and what could be made lower priority.
  • When in doubt about a feature or functionality, we advocated for the best and most effective long-term strategy.
  • The process of test-driven development and the feature testing we undertook highlighted the importance of a dedicated business analyst. We did receive a BA halfway through the project, which ultimately helped keep things high level and prevented us from getting bogged down by the technical details.


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.

The Benefits We Achieved!


Time Savings, Efficiency, Cost

A Little Bit of Luck!

Increased Clarity and Transparency

1

4

2

  • Using testers earlier in the process (rather than waiting for development) meant better utilization of resources.
  • This led to fewer missed bugs (which would have occurred if we failed to capture one-off or nuanced scenarios).
  • Fortunately, we were able to leverage one of the original developers for this project.
  • Without him, it would've taken much longer to understand the code.
  • Creating the test cases first meant less room for error when interpreting individual requirements.
  • Less time spent going back and forth about the requirements.


More Coverage of Product Features

3

  • Instead of testing the original application as a "black box," we adopted our interpretation of test-driven development to build as many agreed-upon new features as possible.
  • This meant we could include any one-off or unique situations that may have been overlooked using only "black box" testing.


Do you have questions about web application services?

Conclusion

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.


To recap our process:

  • With seemingly no good options in sight, we were determined to find a solution.
  • We tried an unconventional interpretation of test-driven development (TDD) which worked out well for the customer. Our innovative testing method instilled confidence and showed we, too, were committed to their respective business vision.
  • Progress on this project is ongoing, even today. We are fortunate to have our customer as a partner and grateful for our continued collaboration.


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.

Ready to see what kind of solutions we can create for you?

 Contact us today!  

Copyright © 2020. All rights reserved.