Skills from the healthcare field prove invaluable in the test lab
After 11 years as a registered, licensed occupational therapist practicing in the healthcare world, I became a software tester at a local software company. Although I am fortunate to have helped as many people as I did over the years, I came to the realisation that I needed a change from the clinical environment. My new company provided me with training and education in the field of software testing and in the software itself. It has turned out to be the most stimulating and exciting job I have had to this day. The skills of evaluation, planning, communication, creativity and flexibility have made my days as a tester exciting and interesting. I hope this article inspires readers to not only use some of the skills I have outlined below, but also to find their own ways to draw strength from talents that might seem outside the scope of software testing and bring them into the software testing arena.
As an occupational therapist, I utilised many skills.
When I met a new patient, after donning my gloves for universal precautions, I conducted a holistic evaluation. This included gathering the patient’s history of how he performed his daily activities (known as ADLs – Activities of Daily Living), and how he is able to perform them in his current state. In addition, I conducted further tests for personal attributes such as strength and cognition, including evaluating the patient’s orientation and safety awareness levels. Then I developed a plan for treatment with the patient. This included 3-5 main goals.
Once the patient agreed to this plan, I documented the evaluation and goals in the patient’s chart, including steps, or interventions, that I would use to reach those goals. As a part of the team supporting this patient’s recovery, I not only entered my plan as an order for the doctor to approve, but also reviewed the nursing, physical therapy, social worker, and case manager’s plans. I needed to know how the other team members were addressing the patient’s weaknesses to make sure there were no holes in our overall care plan.
The treatment included both supporting the patient’s needs and challenging him to work toward his goals. This required re-evaluating his progress toward the goals on a frequent basis. Sometimes, just a change in environment gave the patient a new challenge or exposed a weakness I had not noticed before. In fact, adapting the environment to the patient might be what was needed for the patient to succeed at the task at hand. Maybe introducing a compensatory tool or technique to the patient would make all the difference to allow him to reach his goals and perform certain activities. Or maybe providing treatment during a different time of day gave the patient an opportunity to work on improving other ADLs. These skills and practices, along with many others, were crucial to providing optimal care and treatment for a patient to help him reach his maximum level of independence for a safe transition home.
As a tester, these skills translated into testing the software.
A holistic evaluation of the application to be tested can help shape the test plan. One valuable test to execute that can offer a holistic evaluation of the application and the environment is a smoke test. This type of evaluation should be continuous throughout the product’s development life cycle to keep a pulse on the stability of the product. The holistic evaluation may instead call for a regression test to validate that existing functionality has not been broken, or an acceptance test in a production environment. Regardless of the specific test activity used in the evaluation process, the iterative and frequent evaluation provides the tester with more familiarity in the product and its development, and provides the software with a chance to show its overall strengths and weaknesses.
Prior to testing, it is important to know the software’s history. What are the known strengths and weaknesses? What are the outstanding bug-fixes that did not make it to this test environment? What are customers saying about the current release? If there are enhancements that need to be tested, what was the customer expecting from them? Did the design specify more than what was originally requested, or perhaps something completely different?
Image may be NSFW.
Clik here to view.
Once the evaluation is done and the history is gathered, a test plan is developed. During the test planning process, several questions must be asked. What is the goal or objective of the test? Do new test scripts or scenarios need to be written? Should steps be added to existing scripts? Which test types should be utilised, and at which stage of testing? And importantly, who is on the test team? How much of their time is allotted for this test plan? Will the test plan offer solid coverage of the entire product, or are only certain functions being tested? What other test teams are reviewing this codeset? Will their test plans overlap with yours, and if so, is this necessary? How can all teams ensure there are no gaping holes in the overall development plan for the project or release being tested? (I love the Swiss cheese analogy from Why Hospitals Should Fly: The Ultimate Flight Plan to Patient Safety and Quality Care by John Nance. Since no one test will catch every type of defect, it is important to alternate tests, which exercise the product in different ways and from different angles to catch as many defects as possible. It is like looking down at a stack of Swiss cheese. Although there are holes in each slice, you cannot see through one hole from top to bottom because the holes do not match up.)
Testing begins. But how to challenge the software to expose the right defects is the question. If the original test plan is not exposing issues, or maybe not the right issues, it is time to change the plan. Re-evaluation along the way is key. If the environment is changed slightly, how does the software perform? For performance testing, running the script at different times during the day is important to measure performance during the varying traffic patterns of other users in the system.
Acknowledge your strengths and talents, and bring them to the testing field
I use all of these skills and processes as a tester to try to ensure successful deployment of the software to the customer. My experience in the healthcare field as an occupational therapist has enhanced my software testing practice in ways I could not have imagined when I first considered changing careers. I encourage you to acknowledge your skills and bring them to your software testing approach.
About the Author
Shoshannah Gil is a software tester and testing supervisor in Massachusetts. She began her career in 2008. Actively seeking out new and exciting ways to exercise the software products she supports, she enjoys learning from the software testing community at large. Follow Shoshannah on Twitter: https://twitter.com/
The post An Occupational Therapist Turned Tester appeared first on Ministry of Testing.