Rolling out Cucumber QA in Healthcare – an Interview with Roberto Pacheco
There are compelling reasons to adopt behavioral driven development (BDD) as part of an agile QA process.
Research conducted by MIT suggests that agile companies grow revenue 37% faster and generate 30% higher profits than non-agile organizations.
But…
…while 96% of organizations have adopted agile methodology for at least some of their projects, 43% still lack professional expertise associated with agile development – which has evolved to behavior-driven development (BDD).
Understanding the BDD framework, alone, is not enough to roll out a successful QA and development methodology revamp. Industry subject matter expertise is a must– which is why so many CMIOs and healthcare IT leaders are frustrated with outsourcing.
Cucumber is the leading tool used for BDD, which streamlines development by writing test cases first, enabling real-time collaboration with business stakeholders and developers to prove the tests.
Agile teams can:
- Write their scenarios before they write the code so that programmers can be guided by an unambiguous specification. This would allow programmers to catch mistakes immediately.
- Write their scenarios in such a way that they illustrate business rules and not just the UI. With this, you can get the business analysts and product owners on board.
- Write their scenarios in such a way that future project members can figure out what the system does simply by reading the scenarios.
We interviewed BDD and Cucumber expert, Roberto Pacheco, to share his experience implementing the QA and development methodology within the specialty pharmacy division at the world’s largest PBM.
What was your motivation to start using Cucumber?
We are the vendor of choice within the specialty pharmacy division of a large PBM customer. We first rolled out Cucumber during a microservices project about a year and a half ago. The customer was going through a digital transformation, migrating their data from a central ERP system to cloud-based microservices. We wanted to embrace the highest performing testing methodology.
BDD is test-driven, which means that we first write the test, and then write the code. With agile and test-driven development (TDD), we write the test first, and develop against those tests.
One of the main issues we were having with traditional testing [and one of the main reasons up to 80% of IT projects fail] is that we got the requirements from non-technical people, the stakeholders, and then we tried to write test cases against those scenarios.
The QA people spoke a different language than the business stakeholders and were not familiar with all the business rules and all the possible scenarios. Conversely, non-technical people wouldn’t understand test cases in Selenium or another testing platform. They were also in the dark when it came to making approval decisions.
The BDD framework closes those communication gaps. Teams can sit together in the same room, write test cases in the given: then: when format, and develop all the scenarios/behavior that they expect. Cucumber translates plain text into code, but you still need the code to execute your test cases. That’s where Selenium and other automation tools comes in.
Now, as we build several Pega applications, we can simply point them to the same cloud-based microservices so all the data is in sync. This was the motivation to move to microservices. Cucumber was selected because it’s the most commonly used tool for BDD. There are others such as JBehave, SpecFlow, and JDave.
Live documentation is a major bonus. If you want to see how your application behaves – or the capabilities of your application, you can go to the test cases and see all the behavior. Many legacy systems are so big and cumbersome that, while some people might understand specific components, there’s no overall insight to the whole system. Cucumber provides a live, continuous documentation.
How did you convince such a large customer to restructure their QA process?
The first question customers always ask is “How does this work?” They are often skeptical of the tool in the beginning because they don’t understand it. I’ve had to present several demos to show the platform’s utility.
We tested the QA process in the specialty pharmacy division as we are the subject matter experts and felt most comfortable there. Once we proved how well Cucumber worked, the customer decided to roll out the QA process across all lines of business as part of their digital transformation.
We’re calling the microservices with this PBM “entity services” because they only manage one entity. Instead of patient information all scattered around all these monolithic applications, we have them in one single place. The plan is to build over one hundred microservices, and we’re currently working on the first eight.
How did you and your team learn BDD so quickly?
We knew that agile teams using a BDD framework were faster, more collaborative and yielded better results. We read a lot of Cucumber books and online documentation that helped us learn about the practices on what we should be doing and what we should be targeting.
Two books I recommend are:
I trained a team of six people at our offices in Mexico, who were tasked with training larger groups. We started off with two projects to migrate monolithic legacy databases to new microservices.
It would normally be difficult to gather all the data and business logic from the legacy systems, but because we had prior experience working with those systems, it made it easier for us to understand.
This is where our experience in healthcare operations stands out. Other vendors, even some of the largest in the world, who also work with this customer, wouldn’t be able to initiate this kind of change because they do not know the systems and processes like we do. We’ve done similar transformations at [a Children’s Research] hospital and with other customers in healthcare.
How has your team leveraged QA automation?
My team built a Cucumber core, which is a Java library with reusable code that contains the core domain logic to execute Cucumber features. It’s basically a java rest client that manages HTTP calls, authorizations (Basic and oAuth 1.0), and validations.
We created this library because we are running many tests. Instead of writing the code repeatedly for each microservice, we created the library and published it on a repository within the PBM so that anyone can use it in practice. Other teams are using this same library for testing microservices.
For any microservices now in the PBM, all you must do is pull that dependency and you can start writing your Gherkin scripts without needing to write any code at all.
This seems to save a ton of time. Did the customer ask you to build it?
It does save a lot of time. This is one of the best practices which wasn’t being taken advantage of, so I went ahead and implemented it, which gained a lot of positive attention. I have been approached by several teams who ask me if they can use it and how to use it and some of them are contributing to the code like adding new functionalities.
We actually train other vendors in Cucumber. It’s common for Fortune 100 companies to have multiple IT vendors. It was strange at first, but also fun to know that we were the subject matter experts. Some of the vendors reached out to AgileThought in the beginning. They weren’t asking how to use Cucumber, but how to implement it within the PBM infrastructure.
What are the benefits of transitioning to microservices from a monolithic system?
Cost savings are a major factor. For example, if you have a monolithic application, it’s hard to scale out especially if you are getting a lot of requests for specific data. Microservices live in the cloud. We are use Pivotal Cloud Foundry to deploy and automatically scale if we need to.
If we start getting millions of requests on the same microservice, the system will automatically scale and you won’t see any shifts in performance. This is impossible to do with monolithic systems.
As an example, there are several days of the week where we have a spike in transactions like storing data to databases or retrieving data from databases (especially Monday after the weekend). There is usually a lot of requests coming in which makes the system slower at that time.
These performance issues do not exist with the microservices model because of the cloud based technology. Basically, you are at liberty to scale the way you want. You are not paying for the memory or the space of the RAM.
