Take the initiative and create as thorough a testing plan as you can. Remember – test, test, test, test, and test again. I can’t stress this enough.
You are now ready to start testing with your trading partner, which could include a provider, clearinghouse, another payer, etc. Do you know what needs to be tested, and what results you should expect? It isn’t enough to just say that the transaction set clears everything just fine; you need to know what results you expect.
Testing your send and receive abilities with your trading partner is crucial. For instance, you want to receive an 834 transaction (Benefit Enrollment and Maintenance) from your trading partner. One scenario would be to have them change the member’s gender and send that in the 834. Your expected results would be that when you receive the transaction and it loads into your system, that particular member’s gender will be changed in your system. Changing different information for members is a good way to test to see if the data received will load into your system without any problems.
Can your trading partner handle multiple instances of a member COB loop? Or can you? You would be surprised how many can’t. This is definitely a good one to test in an 834. The more of these types of scenarios you can identify to test the better off you will be in the long run.
A good way to start is by creating a testing matrix. The testing matrix is one way to list all the different aspects you are testing and the expected results. Engage your stakeholders in this activity as well. They will probably think of items you may not. The more items you can list to test, the less likely you will run into issues down the road. Below is a sample testing matrix for an 834 transaction. You will want to design yours based on your testing needs.
Strive to have your testing environment as closely mirrored to your production environment as possible. It never seems to fail, even though your testing and production environment may be identical, that what did work correctly in test may not in production. Plan for this to happen, because chances are it will.
Of course you can’t think of every possible testing scenario, but by creating the testing matrix you will probably hit 99% of them. The 1% are usually those scenarios that happen once in a blue moon.
