We’ve been testing healthcare software for several years and in particular, pharmacy management software. Testing healthcare software products definitely requires a different angle, so I thought I’d share some of our expertise and experience. \tRoles and workflows. Physicians, pharmacists, nurses, and technicians all have different permissions and use the application differently so the test strategy and test cases must specifically account for these peculiarities. For example, a physician is responsible for prescribing an order, while the pharmacist only receives the order. \tPrivileges by role. Each role must be tested for their specific privileges, positive and negative. For instance, only the system administrator has the right to delete a medicine type, or only a pharmacist can reject a physician’s order. \tCategorization rules. Both medicines and illnesses have strict categorization rules. For example, there are many kinds of Flu such as H1N1, H5N1, etc. but a kind of cancer such as lung cancer cannot be listed as a sub-category of Flu. Likewise aspirin should be listed under anti-inflammatories. \tInterconnected workflows. One step in a workflow may update another workflow. If a physician decides to refuse to use one medicine, he should give rational reasons which then need to be approved by his or her manager. If approved, then that approval should be forbid purchasing new medicine of that type in the purchasing workflow. \tDatabases. Healthcare software always contains many databases such as patients, medicine, physicians, facilities, etc. Often these databases are connected and each of the connected tables needs to be verified. Testers should verify changes are integral where they should be and that search results are as expected in the different tables. \tBoundary values. Boundary values should provide consistent results. For example, if one patient’s age is more than 60 years old, they may be set to ‘senior’ and therefore medicines may be administered in lower quantities, so the tester should try the boundary values as 59,60,61 to verify that the patient is put into the right age category. Negative testing is critical in this instance as well since older patients who should get lower dosages may have adverse reactions if they receive instructions for a normal adult dosage. Generally speaking, as in testing any software product, the more domain knowledge the better, as the rules, roles, and intricacies of the domain directly impact test strategy and test case design. For testing pharmacy management software, it is critical to understand the different medical roles; doctor, nurse, technician, etc. and be able to understand, what they can and cannot do (also from a permissions standpoint), how they would use the software on a daily basis, and how their workflows interact.