When it comes to healthcare software solutions, whether or not to automate your QA testing of your new releases can be a difficult decision. On the one hand, you know that the manual testing you have had in place can get the validation and verification job done, as it has proven time and time again. Yes, it may be long and cumbersome with that month and a half of regression testing that must be baked into the SDLC, but it is a known in-use process that gets the job done, and that’s a good thing. But the leap into the unknown of automation testing, even if it whispers and entices with its potential for greater coverage and drastic execution time savings (during regular testing, not just regression testing), can be scary.
Likewise, the thought of your QA staff becoming test procedure coding experts overnight may make you question your sanity, asking questions like “Can they learn stuff, or will I need to look for new people who have never worked here before, new to our ways and how our systems work?” You start reading up on success rates of QA automation, and the numbers do not bring a smile to your face, as more than half of all efforts fail. And without an automation expert in-house, how do you even know which automation software fits your needs? How safe is it for your team who focuses on quality to be making it up as they go along?
The answer to that last question is to make sure that an outside expert is QA-ing your QA upgrade effort, and by “expert” I mean a reliable, long-standing QA firm, not just someone waving their business card around making pretty promises. Beginners and hucksters should not be making these important initial decisions, because they have no track record showing that they know how to recognize the hazards ahead. Automation is a form of Test Process Improvement (TPI), and all you need to do is find a software testing and business assurance company whose services include TPI, automation testing, industry specialty in healthcare IT, and Results-Based Testing (RBT). You want RBT because you want a contractual guarantee that the effort will work for your own piece of mind (to balance that scary leap into the unknown and that risk of failure that I talked about earlier). And once you have that, a lot of those earlier fears should melt away, and you can proceed to the task at hand: TPI.
Now let’s back up to some of our earlier questions: what about the learning curve of automation, and the software costs? You may want to partner with an SQA firm permanently for updating your test procedures (which can still be executed by non-programmers). Or you may want to choose a test automation process that is easier to learn like Behavior Driven Testing or Keyword Driven Testing, so that creating and maintaining scripts requires a lower knowledge of programming to accomplish. There are many free open-source functional testing tools available (Cucumber, Robotium, Sahi, Selenium, SoapUI, Watir, etc.), however many of them require a higher degree of programming knowledge to use.
You see, the real question should not be “What are the risks?” but “What are the savings?” The fact is that you’ve been drowning in wasted time and possible missed coverage due to the manual testing you’ve limited yourself to. The sprints through the testing suite are so short that the bugs get logged quicker, so the developers can receive those bugs quicker, and get the bug fixes out the door to testing quicker. Like a snake eating its own tail, the timeline headaches you used to have are going away. Also, the thought of “what if we just ran the entire suite again, because the most recent bug fixes changed a lot of code”, which used to be a pipe dream due to schedule pressures, is now a possibility, due to the drastic execution time improvement. Imagine the quality improvements this means for the final release! You will wonder how you used to survive. Why wouldn’t you want to rerun the test cases that passed on their first run though again to make sure that nothing got broken? It almost seems negligent to not have that option, now that you do have that option.
And best of all, your testers don’t have to even be present when the test cases execute! They can run them overnight, freeing their workday from the tedium of running similar test cases that have been bundled together to save execution time while risking mistakes due to the monotony of repetition.
So, there you have it. What used to be a scary list of “why you should avoid change” becomes a list of “why you needed to change.” The important thing is that you avoid the risk of guessing how to implement the solution and instead go with a safe trusted source experienced in the process.