“We’ve tried this before and got burned. How do we know this will work?”
When you’ve tried to solve something in a certain way, and someone comes to you and suggests a similar-sounding approach, the first thing you get is hesitation. That’s the situation we found ourselves in with Arkansas Blue Cross Blue Shield
(and yes we realize this is an insurance company, but they are tightly coupled with the healthcare sector–all the regulations and rules involved with compliance are at the forefront here, so we consider this a healthcare case study)
Here’s their story:
The previous attempt
Their previous attempt involved having developers write the automated tests. And it was a mix of both website testing (through their customer-facing portals) and API testing (all the small programs handling the data transfers, record management, etc.). That ended up failing because their developers were too busy writing the code for their customers, and then the test automation fell into disrepair.
So, the testers were doing everything manually, and even the business analysts had to pitch in and help offload the testing work.
This actually happens a lot, whenever the expectation is that developers will write code AND write automated tests AND maintain those tests. The work that actually generates revenue is what gets prioritized, and everything else is set aside.
So when we were asked to help Make Automation Great Again, we pitched a pretty unorthodox idea:
What if the testers and business analysts could automate the testing?
Holy moly did that get a response!
When approaching non-developers about the idea of automation, they bristle. Part of it is, “am I automating myself out of a job?” The other part is, “am I creating another full time job for myself when I already don’t have enough time to get things done?”
We definitely take both points seriously, and the last thing we want to do is create more work for everybody. Automation is supposed to save time, not add to it.
So our proposed solution was:
- Create a testing framework that allows people to write tests in English
- Offload the testing effort from the developers
- Onboard the current testers and business analysts
- Train them on how to write great tests
Essentially we were allowing the testers to explain in English what they would be doing, step-by-step, while testing. This serves two purposes:
- First, it immediately provides documentation for what’s being tested.
- Second, there’s no “brain tax” of trying to turn human thought into computer code. It’s just English.
Our weapon of choice
We naturally gravitate toward Cucumber when creating testing frameworks like this. Although Blue Cross is a company that uses .Net for its programming, the Ruby language was a great fit. It’s got a lower learning curve, which means junior members (and even some enterprising non-developers) could extend and maintain the automation framework.
Also, since the things being tested were websites (which are in HTML) and APIs (which communicate via JSON and XML payloads), we weren’t limited to a .Net solution.
Testing and Demoing
As we built out the proof of concept, we decided to do a pretty involved process just to show off the capabilities. We demonstrated the creation of a new customer profile by filling out close to 100 fields and submitting the form, confirming that the system received the data by viewing it in a lookup elsewhere on the site. We also demonstrated that APIs could be sent data and responses captured and analyzed, using the same English-based test format (and how we test APIs using Cucumber is explained in more detail over at the Logistics Case Study
Workshopping and Handoff-ing
Finally, the goal was to get the teams to be independent of us. We designed a curriculum to get people used to the system, showed it in action, provided examples they could use to get familiar, and got them sent on their way.
Near the end of the project they asked if they could extend us a bit longer. There was another team that needed their tests automated too.
Whereas it took 6 months to get the primary project completed, we used the same framework to get things going in a little more than two weeks.
They’re still using it today.
For every project we take on, we make sure it’s custom fit for them. We’re not a one-size-fits-all provider. Great solutions work right now, and offer some flex to account for the future.
That’s how we roll.
So: If this or something similar might help you, we can get some time to chat.