Choose your question:
Do you know or want to know anything about testing management or application development? Then, you should know that, regardless of the project, the challenges in quality assurance usually boil down to:
Yet, every project is different and these challenges don’t appear out of the blue. They are the result of the misguided application development process. In Untitled Kingdom’s 13 years of experience in web & mobile app development, apart from establishing whole results-proven development workshops, we learned that (alas?) there is no 100% reliable script on how to test a product.
That’s where these 4 questions come in. I hear them both from our Partners (never called them “clients”) and other mobile app programmers. When in fact, I should be the one asking them. Everything starts with your idea for a medical device or digital health app, so you know best how you want to help others. Chosen QA methodologies aim to serve that purpose.
So approach the questions below with a grain of salt.
They imply that QA software testing is easier than it actually is, but at the same time, it’s easy to understand why everyone asks them.
They highlight key parts of the testing process: strategy, timing, and trustworthiness of your app.
And finally, in line with the delayed issue effect, they affect the efficiency and costs of the healthcare app development process.
My team’s work starts the moment we begin analyzing product requirements. During these early stages, QA specialists can weigh in on user experience issues that are easy to avoid. The whole process is more than just checking the bugs (I cover that in greater detail in another blog post).
In the case of digital health applications and healthcare app development, we review current approaches right from the start. We challenge them, discuss their limitations and choose the best and most efficient one. Then, we speak with the specialists (doctors) who are familiar with the problem (specific disease or condition) and -if possible- with potential users (patients) and ask them what is missing in other applications they might have been using.
I think it’s the best visualization of my day-to-day work.
All the little things you need to think about for 1 app to serve its purpose. 😉
You’ll be surprised how it improves the whole software development process.
In the Untitled Kingdom, QA specialists are always a part of a larger Project Team among mobile app programmers, UX/UI designer, Product Owner, and Product Manager. And it’s an arrangement that works for the benefit of all—making quality one of the team goals.
Shared objectives are a base for healthy relationships in the team, which translate into higher quality products. I’ve heard of developers who resent talking to QAs since they hate facing software issues and navigating tricky questions. This, as you can imagine, leads to a Quality Specialist being reluctant to flag any bugs. Yet, I never had that experience. As a team, we are rarely not on the same page.
True collaboration directly with Partners (aka you) is important too. Regular meetings or calls ensure clear communication. That’s when QA specialists can point out all blockers, discuss bugs' priorities, as well as give and receive comments. Making adjustments to the testing plan saves time and energy for the whole team. Not to mention saving on investments.
Legend has it that you can find this pic in a dictionary, as a definition of “true collaboration.”
I’m in the top left corner of the photo, clearly happy to see the UK's QA Team in all its glory.
Launching the application should never mean the end of my team’s work. Pre-release testing is, of course, far more extended - running different types of tests, using the best relevant production data, and checking the build deployment process. But in the end, test environments are never 100% identical in setup and resources to the ones in production.
Where can it go wrong? Deployment issues, data differences, or unexpected issues that could appear only in a production environment. Assuming the app’s feature works in production does not mean it actually does. We carefully test (if possible) the main functionality, verify key processes, and clean up the post-release test data.
Then we start monitoring the app’s performance. After hundreds (hundreds!) of tested cases, it’s actually exciting if a user can find any other way to “crash” the app or find any bugs. 🤓
Plus, with the user’s feedback, we can check if our assumptions were correct and (if needed) apply suitable changes to the next project.
These 4 questions are all about building (and testing!) engaging, trustworthy, and smoothly-running apps and devices. But in many ways, they are also about your transparency and confidence in inviting, checking, and questioning feedback.
The common thread of all these questions? The people factor.
When revaluing product requirements, we put ourselves in the app user’s shoes.
During application development, you collaborate with all the Project Team members.
And finally, after your healthcare mobile application is released, we all get to hear from the people actually using your app.
And, trust me, since every person has a different definition of quality, the best thing you can do is create the right process for us to match yours.
We’ll have the answers ready.