Robotic Process Automation (RPA) is a component based, on-demand, software solution that replaces repetitive, monotonous tasks.
The beauty of RPA is that being a bespoke component-based solution, it can fit in your current environment absent replatforming the existing infrastructure.
As a software engineer, I have managed many development projects, large and small. While it is true that larger developments may have more components, it does not necessarily mean that smaller development projects are less complex or require less discipline in the production process. We previously discussed some of the guiding principles that govern our RPA development process. In this article I want to discuss how we utilize Test Driven Development (TDD) to support Rapid Application Development (RAD) to deliver high-quality, affordable RPA solutions.
What is a Bot?
Let me provide an example of an application we are looking at putting into production, with some obfuscation aimed at preserving our clients’ confidentially.
Departmental cost allocation data is currently being submitted to SharePoint via InfoPath. The data is manually merged into a single file and subsequently imported into SAP.
We built three components to automate this process. First, we employed Python to perform a form of data scraping known as report mining. This allows us to capture information from human readable reports, such as the data being submitted via InfoPath. Second, we are pushing this data into another component, programmed in C#, that combines and arranges it into a structured format. The third component (also programmed in C#) utilizes an Application Programming Interface (API) to populate SAP.
Although many RPA projects are aimed at reducing workload, in this case, the client’s objective was to automate the process so that, rather than getting these updates imported monthly, it could be done daily with a high degree of accuracy and no additional effort by her staff.
The Agile Methodology
We employ Agile. It is an iterative, incremental project management approach that is being employed in many professions. Its roots, however, grew out of the software engineering discipline. Software development projects are always highly dynamic. User requirements are almost always changing before the product is complete. Agile brings discipline to that chaos. It helps manage customer expectations and preserve programmers’ sanity.
It prescribes continuous delivery of product. The project life span is divided into equal short timeframes called Sprints. Each Sprint starts with a specific, well defined goal. At the end of each Sprint, delivered product and team productivity is analyzed. This provides end-users with the opportunity to change scope before the next iteration begins, and for development teams to adjust production schedules as necessary to accommodating changing conditions.
Agile is widely embraced, but what has always worked well for me is that a ‘delivered product’ is the measure of progress. Setting short-term, achievable goals, builds team momentum that fuels innovation.
Test Driven Development
Nothing will destroy momentum, or a client relationship, quicker than delivering a faulty product. In software development, testing is a crucial component of the development lifecycle. Many different paradigms have been introduced to test a software, such as black box testing, white box testing, integrations testing, sanity and smoke testing, regression testing and so on. For RAD projects, we employ TDD in combination with Unit Testing.
Unit tests are little piece of code that are developed to examine each component of an application at a granular level. As the product passes through each Sprint new tests are developed to exhaustively test each new function or component. This testing methodology ensures that as new functionality is added to an application, previous functionality does not get infected or broken.
Using this testing paradigm, TDD comes into the scene because test cases are written before actual development begins. The unit test verifies the functionality of the feature and ensures the test case fails if the feature is absent. TDD is a ‘test-first’ approach to keep the product development focused on passing pre-designed test-cases. The software is functional and testable at the conclusion of each Sprint.
Employing TDD to Drive Innovation
RPA can be a momentum driver in your digital transformation journey. Each RPA project can be thought of as a Sprint and, as each new bot is deployed, end users begin to find new ways to embrace technology to create more value for their organization.
TDD plays a vital role in making RPA deployments successful. Just as momentum drives innovation in a development team, momentum drives innovation within an organization. A buggy piece of code is going to frustrate users, kill momentum and adversely impact the return the client realizes from their technology investment. Time invested in planning the testing, before the code is written, will pay dividends during development and when the application is put into production.