Playing in the hospital or as we studied and tested the work of the health care system in a European country
The article “How to cope with problems in an inherited project after 3 other teams” tells you 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 verify all changes made by developers and ensure that the product meets the expectations of customers and end users.
An inherited product without analysts, documentation, testing processes and generally buggy is a real challenge for any team. And bringing testers to such a product was just a matter of customer consent.
I would like to note that the study of a narrowly focused business logic, and even for a specific foreign state, may turn out to be a very nontrivial thing. You can look at it as if you installed an “American Accounting Engineer” on the machine of an American engineer and asked to work with it, and exactly the way Russian bookkeepers do it.
1. How to start a tester, if there is only a code.
The first thing we did was carefully examine 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 voice decoding applications did not pass us.
The second stage of acquaintance with the application was close communication with the customer. Thanks to the correspondence and the received sketches of help-documentation (4 presentation slides), we were able to identify several critical points:
These 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 business logic at least a little, numerous tickets with bugs and problems from users were falling on the head of support. These tickets became our second data source. Such applications have an incredible amount of features. For example, we needed to carefully study the specifications for OMR codes, features of double names and surnames, document templates, and more. We were even sent photos with already printed letters, so that we could clearly understand how the letters are folded and what format foreign envelopes are.
But the most useful were the sets of settings and configurations that are used on real servers. The situation was such that for ten servers hundreds of settings were used that influenced the business logic of the client application. Together with the developers, we studied each of them through code and, of course, documented them.
3. Everything should be as close as possible to reality.
After we realized that you can’t test the entire functionality of the recording window with simple microphones, we requested the devices used by the doctors.
These are mainly devices like 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” in the whole testing process and 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 emails). 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 to reality tests are, the more critical and more important are the bugs, and consequently, the testing itself becomes more efficient.
4. Look for loyal users.
Any application will have users ready to cooperate with the development team. We asked to record all actions with the application, and then send it to us for analysis. Total we had about ten records, and from users with different roles. We managed to build a complete picture of the work with the application, as well as see the speed of work and performance problems. At that time, the speed of the application was deplorable, and the development team had to sweat over 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 to conduct a complete check of the application, starting with installation 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 knowledge of the system we still have, what test servers we lack and whether we have the correct idea of the admin part of the application.
The most important thing was to recreate the full work of the hospitals, sending documents for decoding, checking these works, processing letters, followed by printing and sending them to various integration systems. We selected the most approximate-sized texts, studied statistics on the size of the audio, 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 bathrobes.
Of course, after that we sent our reports to the customer, pointing out the most significant shortcomings of the application, and also pointed out 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 exist in it. We also achieved conscious testing, adding Jira (Zephyr) and Confluence with numerous test cases (more than 1000), checklists, specifications and even user guides (more than 50 articles) for our customers.
But the most important achievement for us was the fact that the customer began to trust us as experts and is very attentive to our advice. Now, no specification is developed without our static testing, and we, in turn, keep control to keep all documentation up to date in our wiki.
In conclusion, I would like to say that this is only a small part of all measures that provide high-quality, conscious, and most importantly user-oriented testing. Parallel to these actions, the adjustment of testing processes within the team, the deployment of automated testing, the selection of tools, the adjustment and stabilization of test benches and much more take place.
It also shows how to carry out the most difficult stage - “Entry into the project” with minimal support from the customer, the absence of analysts and with maximum efficiency.
Thanks for attention!
Here we want to tell you what the testing team did to effectively verify all changes made by developers and ensure that the product meets the expectations of customers and end users.
An inherited product without analysts, documentation, testing processes and generally buggy is a real challenge for any team. And bringing testers to such a product was just a matter of customer consent.
I would like to note that the study of a narrowly focused business logic, and even for a specific foreign state, may turn out to be a very nontrivial thing. You can look at it as if you installed an “American Accounting Engineer” on the machine of an American engineer and asked to work with it, and exactly the way Russian bookkeepers do it.
1. How to start a tester, if there is only a code.
The first thing we did was carefully examine 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 voice decoding applications did not pass us.
The second stage of acquaintance with the application was close communication with the customer. Thanks to the correspondence and the received sketches of help-documentation (4 presentation slides), we were able to identify several critical points:
- How is the recording (devices, audio formats)
- Templates of letters, which are formed from transcripts dictated by doctors.
- User roles: Doctors, Secretaries, Transcriber, Secretaries-editors (monitor text quality), print department
- List of integration systems
- Total life cycle of documents
These 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 business logic at least a little, numerous tickets with bugs and problems from users were falling on the head of support. These tickets became our second data source. Such applications have an incredible amount of features. For example, we needed to carefully study the specifications for OMR codes, features of double names and surnames, document templates, and more. We were even sent photos with already printed letters, so that we could clearly understand how the letters are folded and what format foreign envelopes are.
But the most useful were the sets of settings and configurations that are used on real servers. The situation was such that for ten servers hundreds of settings were used that influenced the business logic of the client application. Together with the developers, we studied each of them through code and, of course, documented them.
3. Everything should be as close as possible to reality.
After we realized that you can’t test the entire functionality of the recording window with simple microphones, we requested the devices used by the doctors.
These are mainly devices like 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” in the whole testing process and 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 emails). 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 to reality tests are, the more critical and more important are the bugs, and consequently, the testing itself becomes more efficient.
4. Look for loyal users.
Any application will have users ready to cooperate with the development team. We asked to record all actions with the application, and then send it to us for analysis. Total we had about ten records, and from users with different roles. We managed to build a complete picture of the work with the application, as well as see the speed of work and performance problems. At that time, the speed of the application was deplorable, and the development team had to sweat over 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 to conduct a complete check of the application, starting with installation 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 knowledge of the system we still have, what test servers we lack and whether we have the correct idea of the admin part of the application.
The most important thing was to recreate the full work of the hospitals, sending documents for decoding, checking these works, processing letters, followed by printing and sending them to various integration systems. We selected the most approximate-sized texts, studied statistics on the size of the audio, 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 bathrobes.
Of course, after that we sent our reports to the customer, pointing out the most significant shortcomings of the application, and also pointed out 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 exist in it. We also achieved conscious testing, adding Jira (Zephyr) and Confluence with numerous test cases (more than 1000), checklists, specifications and even user guides (more than 50 articles) for our customers.
But the most important achievement for us was the fact that the customer began to trust us as experts and is very attentive to our advice. Now, no specification is developed without our static testing, and we, in turn, keep control to keep all documentation up to date in our wiki.
In conclusion, I would like to say that this is only a small part of all measures that provide high-quality, conscious, and most importantly user-oriented testing. Parallel to these actions, the adjustment of testing processes within the team, the deployment of automated testing, the selection of tools, the adjustment and stabilization of test benches and much more take place.
It also shows how to carry out the most difficult stage - “Entry into the project” with minimal support from the customer, the absence of analysts and with maximum efficiency.
Thanks for attention!
Source: https://habr.com/ru/post/273621/
All Articles