What You Will Learn
This is a story of my experience, albeit a very short one, of how testing in the oncology treatment domain transformed me. I hope it will inspire you too, to be better, to do more – regardless of your role!
After having worked in software testing for many years, across various retail and enterprise domains, I felt I have missed out on a very critical set of domains such as automobiles, aerospace and medicine.
My understanding is that testing in such domains needs a different mindset. Why? Because unlike many other domains, it would NOT be acceptable to have a priority 1 / 2 or an even lower priority / severity defect acceptable in the airplane software determining say – the flight path from point A to point B, or, some software that is doing a medical or laboratory test and the results are going to decide what type of treatment a patient is going to have, or, accident prevention software in a car. The effect of any defect cropping up in such software may have disastrous effects on lives of people.
A few months ago, my wish came true. The opportunity came in the form of a project for a client in the medical domain – more specifically in cancer treatment, focusing on radiation therapy.
There were two realizations I had in the first hour starting work here:
- This is a highly specialized field, one that requires a lot of research.
- One needs to have very good domain knowledge to be effective in this field.
Before I could contribute to the project, I had a huge learning curve of understanding the domain and the terminology. After the initial few months, I am probably still at just 1% (or under) of my domain knowledge.
I spoke with the Product Owners (doctors) and other subject matter experts in the office, did my own research from wikipedia and cancer.net to start learning and understanding the domain of cancer, and its treatment.
The client focuses on radiation therapy and manufactures various types of radiation therapy machines to administer the treatment. Along with the machines, they also have various other specialized software offerings in the domain to assist with the treatment planning, monitoring and care for the patients for hospitals and clinics to use. It identifies various ways to integrate the data and provide a unified view of the treatment to the team consisting of doctors, nurses, laboratories and pharmacies.
The goal of my team was to provide a software solution to cater to the needs of various roles involved in the patient’s treatment.
As time progressed, there were more and more of these conversations.
The more I heard these conversations, the more I felt that the team members seem to be very disconnected, non-compassionate, to the extent – rude; in their behavior and were very light-hearted in the conversations about people suffering from this very serious disease, from which it is very difficult to recover.
All this reality made me very uncomfortable.
The “Awe” moment
I recently had the opportunity to get a factory tour of how different types of radiation therapy machines are manufactured. It was an assembly line – very structured, and they also used Kanban – a Lean manufacturing process way of working at each relevant stage to ensure minimal waste.
It was amazing to see how the team brings to reality, from the smallest of the parts to the complete machine being assembled, and tested at the highest quality possible to prevent incorrect treatment for the patient on the table.
The factory floor is where all the different results of research and planning comes together. Things like the research, the planning, the tooling (software and hardware) required, the various simulators required before the first part is manufactured are not visible in the process.
Knowing what we were contributing towards made me value the work my team, and I were doing, and how that fitted in the complete cancer care treatment ecosystem.
And then, suddenly it hit me –
Unless one has the expertise and passion to be in this medical field, and unless one has the ability to remain-distant (emotionally) from an individual patient’s problem, one will not be able to bring objectivity in the treatment. There is a reason why it is not a good practice for a surgeon to operate on a family member or friend – it is difficult to stay objective and keep the emotions at bay during the treatment.
The team seemed to be doing exactly that – they seemed distant-enough, yet appropriately compassionate, to continue their contributions and work in the domain – whether it was in labs, in software development, or on the floor – assembling machines to send to hospitals, or the hospitals itself.
So, in hindsight, it was not that the team members referenced above were disconnected from the pain of the patients’, neither were they non-compassionate and they were definitely not rude.
In fact, I now admire, more so than before, the passion, grit, resolve, dedication (and as many adjectives I can think about to describe the massive effort) people in the field put in the form of research in universities, labs, in building better medical systems (hardware and software), working in hospitals as clerks, nurses, physicians, surgeons, administrator / operational staff members and various others roles to provide treatment to the needy.
[I am neither talking, nor considering the other side of the coin, the aspect where medical treatment and medicine have become a moneymaking business.]
It makes my resolve stronger to do my work more thoroughly – by testing “thoroughly and meticulously” in such an ecosystem.
I now need to ensure I put in more effort in understanding the domain better, understanding what problem I am helping to solve, and for whom. I have to work harder to achieve this.
Without this, someone may not get the best of the treatment, in good time, in an error-proof way. Without this, I am not doing my job; I am not fulfilling my responsibility of validating the “right-product is built, and the product is built-right.”