That’s not my bug

In my previous position I had the privilege to be on the Revenue Cycle Analytics team, which did reporting on all other parts of revenue cycle (patient accounting, registration, scheduling, charge services, etc). As part of my testing I need to create patient financial data to prove that our reporting displayed the data accurately. The problems that I began to experience was I would find bugs and places were the workflow was broken. When I would approach the solution I believed would be responsible for the fix or investigation I was told that is not my bug. Even worse was the solution said they tested their part of the code and it worked just fine, but it did not look like they were testing to make sure it integrated with the other solutions necessary to make the full workflow successful. I was finding bugs in the testing gaps, and no one seemed to care but me and my team.

So how do you fix a test strategy that does not take into consideration integration testing among solutions? In this case I stopped a major project from going out the door. We had to work in collaboration with another solution to send out a major project. When I found the bug that would keep our reporting from working properly I brought it to everyone’s attention. I was offered several work around solutions, but I refused to take the easier paths and insisted the workflow needed to be fixed.

I know that my situation is not unique and I am sure there are many in the testing community who experience these same problems on a daily basis. I am here to tell you we cannot allow ourselves to be siloed into just testing our pieces of the overall pie. Please join me as I go into detail about the problem of integration testing gaps, how I fixed this on my team, and solutions that can be used by everyone.