The game of the hospital or how we studied and tested the health system in one of the European countries

    The article “How to cope with problems in an inherited project after 3 other teams” tells what the development team had to go through in order to get a fairly stable software product in a year and a half.
    Here we want to tell you what the testing team did to effectively check all the changes made by the developers and to ensure that the product meets the expectations of customers and end users.
    image

    An inherited product without analysts, documentation, testing processes and generally teeming with bugs is a real challenge for any team. And attracting testers to such a product was only a matter of customer agreement.
    I would like to note that the study of narrowly focused business logic, and even for a particular foreign state, can turn out to be a very non-trivial thing. You can look at this as if you installed the American engineer - 1C “Accounting” on the machine and asked you to work with it, and this is exactly how the Russian accountants do it.

    1. Where to start the tester, if there is only code.

    The first thing we did was carefully study all the possible articles and websites dedicated to healthcare. Starting with what are the standards for the exchange of electronic medical information, and ending with viewing photos of hospitals, where the software transferred to our hands is installed. Of course, potential competitors and just applications for voice decryption did not pass us by.
    The second stage of acquaintance with the application was close communication with the customer. Thanks to the correspondence and the resulting outline of the help documentation (4 presentation slides), we were able to identify several critical points:
    • How is recording (devices, audio formats)
    • Letter templates, which are formed from transcripts dictated by doctors.
    • User roles: Doctors, Secretaries, Transcriber, Secretaries-editors (monitor the quality of the text), print department
    • List of Integration Systems
    • General life cycle of documents

    This data became the basis for further work and set us priorities in studying the application with 400,000 lines of code. As a result, we drew such a scheme:



    2. Support as a source of knowledge.

    By the time we started to understand at least a little business logic, numerous tickets with bugs and problems for users fell on the support head. These tickets have become our second data source. Such applications have an incredible number of features. For example, we needed to carefully study the specifications for OMR codes, features of double names and surnames, document templates and much more. We were even sent photographs with already printed letters, so that we had a clear idea of ​​how letters are folded and what format foreign envelopes are.
    But the most useful were sets of settings and configurations that are used on real servers. The situation was such that hundreds of settings were used for ten servers, which influenced the business logic of the client application. Together with the developers, through the code we studied each of them and, of course, documented.

    3. Everything should be as close to reality as possible.

    After we realized that you can’t test the entire functionality of the recording window with simple microphones, we requested the devices that doctors use.
    Basically, these are devices such as speechmike and DVR, as well as pedals for controlling audio during transcription.


    Philips LFH3200 / 00

    DVR Philips DPM8000

    Infinity foot control

    Another important point for effective testing was the emulation of integration systems.
    We tried to minimize the “black boxes” throughout the testing process and to study what outgoing data third-party services work with. For example, Mirth Connector (interface for working with HL7 messages), WinDip (electronic documentation system), Docman (electronic service for sending letters). Each service has its own formats, and it is very important to provide them with the correct data for further processing.
    We relied on a simple rule: the closer tests are conducted to reality, the more critical and important bugs are, and therefore testing itself becomes more efficient.

    4. Look for loyal users.

    Any application will have users willing to collaborate with the development team. We asked to record all actions with the application, and then send it to us for analysis. In total, we got about ten entries, moreover, from users with different roles. We managed to build a complete picture of working with the application, as well as see the speed and performance problems. At that time, the speed of the application was deplorable, and the development team had to sweat over the optimization.
    The resulting videos were translated into test cases, which were later used for regression testing.

    5. End-to-end testing.

    One of the large-scale tests for us was End-to-End testing. It meant carrying out a full test of the application, from installing it on a clean machine with drivers for devices and ending with printing letters and packing them in an envelope. End-to-end tests allowed us to clearly understand what gaps in our knowledge of the system are still present, which test servers we lack, and whether we have a correct understanding of the admin part of the application.
    The most important thing was to recreate the full work of hospitals, sending documents for decryption, checking these works, processing letters, followed by printing and sending them to various integration systems. We selected the texts closest in size, studied the statistics on the size of the audio, and looked at what types of formatting are most often used in letters. In general, they made a real role-playing game, it remains to wear only white robes.
    Of course, after that we sent our reports to the customer, pointing out the most significant flaws of the application, and also indicated what other data we lack to study the systems.

    6. Total

    The result of this work was a solid report explaining to the customer how our system works and what problems it has. We also achieved informed testing by supplementing Jira (Zephyr) and Confluence with numerous test cases (over 1000), checklists, specifications, and even user guides (over 50 articles) for our customers.
    But the main achievement for us was the fact that the customer began to trust us as experts and was very attentive to our advice. Now, no specifications are developed without our static testing, and we, in turn, maintain control so that all documentation is kept up to date on our wiki.
    In conclusion, I want to say that this is only a small part of all measures that provide high-quality, informed and, most important, user-oriented testing. In parallel with these actions, the testing processes are being set up within the team, the deployment of automated testing, the selection of tools, the setup and stabilization of test benches and much more.
    It also shows how you can carry out the most difficult stage - “Entering the project” with minimal support from the customer, the lack of analysts and with maximum efficiency.

    Thanks for attention!

    Also popular now: