You only get one chance to make a first impression.
But with app users, that one chance can mean everything.
App Store releases a daily average of 747 new apps.
For Google Play, it’s 1,819 new app releases every day.
On top of that, over 25% of app users abandon a product after only 1 use.
So how do you make sure that they will engage with your app?
As a Quality Assurance specialist at Untitled Kingdom, I believe the answer lies in testing. And with 13 years of experience in helping our Partners deliver market-fitting products, we know how to build a user-friendly (mobile and web) app.
Here’s how we do it by setting 5 software testing cycle steps.
Jump to a section:
Reminder: every project is different.
There is no set scenario on how to test a product. Software quality assurance and software quality control play different roles in each project.
After all, everything starts with your idea for (mobile or web) application.
Our team’s approach and chosen QA software methodologies are there to serve it and focus on what’s unique about the project.
Yet, some guidelines are universal.
The key objective in QA testing is always to ensure end-user satisfaction.
And setting suitable software testing life cycle (STLC) steps always helps.
At Untitled Kingdom, when developing MedTech projects, we focus on trust, reliability, and engagement of every application we test. And having learned from years of constructive feedback from our Partners (we never called them “clients”), I can present:
5 steps to create the most engaging, trustworthy apps during all STLC phases:
First of all: let's talk about communication
There’s no quality assurance without a quality team mindset.
When creating something that… often has never existed before, a shared understanding of the project’s goals across all team members is crucial.
In practice, it means that QA specialists are involved during every stage of software development. Right from the start. There’s no QA Team, only a Project Team - members responsible for specific tasks (like UX/UI designers and software developers) and team-players maintaining the workflow of the whole group (like Product Owner or Product Manager).
The strategy is built from a shared experience of all the team members.
As a result, quality becomes not only QA’s responsibility but is maintained by every member of the Project Team. QA engineers become a bridge between all the team members, including our Partners. Sharing these user-focused objectives and a “quality attitude” strengthens the team and helps us move in the right direction.
Step 1: Set clear goals and needs
It all starts the moment we begin to analyze business requirements and interpret them into users’ needs.
In practice, we do more than just ensure clean and intuitive interfaces. We determine how people should feel while using the app. For healthcare apps specifically, it means capturing... a certain sensitivity.
I’ll give an example:
For the last couple of months, I was working on a mental health phone application. Right after turning it on, the app user needed to answer questions regarding their sleeping habits, employment satisfaction, relationship status, and more.
We knew right away that the person on the other side of the screen needed to feel safe - to want to provide this sensitive information and to want to use the app again. So, chosen colors and design aside, we emphasized the pacing of each feature and analyzed the user’s journey in detail. In a way, we planned to test these features long before the “real work” even began.
As a result, we, the QA engineers, put ourselves in the shoes of the end-users. It helps us understand the product and spot any potential bugs right away. This perspective at such an early stage of the planning process saves everyone’s money and time.
QA Team at work.
No, our company core values are not displayed in all the office rooms... just in some of them.
Yes, we make sure that at each meeting, the number of devices is larger than the number of humans working with those devices.
Step 2: Determine the type and level of testing.
Now that we know how to communicate as a team and understand our shared goals... let’s plan it all out!
Precise planning allows us to:
- estimate the duration of testing,
- calculate the costs,
- measure required resources,
- and outline possible risks and challenges.
In practice, it means creating testing documentation, scheduling the development process, and presenting the test plan to our Partner. We determine what types of testing need to be done considering the functionality, performance, and accessibility standards necessary for the project’s success.
As a result, we can now contact our Partner with a detailed plan of our work and the types of tests we will be conducting. It creates shared understanding and essential vocabulary for both sides moving forward.
Frankly, this step is not very exciting. Signing up test cases, analyzing test scenarios, estimating every possible result… it’s plenty of digital paperwork.
Yet, this precise planning is crucial to the whole process. It allows us to avoid unclarity and unnecessary complexity. We investigate this in detail in chapters 3 and 5 of Untitled Kingdom’s "How to Start Your Project" ebook.
Step 3: Build a specific QA process.
Now that we have a plan… let’s put it into more concrete terms and build a process that the whole Project Team can trust.
In practice, we set testing environments, present QA flow in a bug-tracking system, integrate our tools with any tools from our Partners’ side and create a release plan. Such framework and process automation let us rate the app’s overall quality whenever any change appears. It’s all about creating the workflow.
I’ll be more specific:
Look closely, and you’ll notice 4 environments - dev, QA, staging, and production.
In this flow, we set up an additional environment (QA instance).
At Untitled Kingdom, if it’s suitable for the project, we tend to set up an additional environment. As a result, even if any bugs are found, it does not block other releases. We can be more flexible, allowing multiple QA engineers to test different features simultaneously.
Step 4: Execute the tests!
The software entry criteria: completed.
Specific QA environment: prepared.
let’s start the testing stage of software development!
In practice, it involves activities, such as:
- executing tests according to the test plan (manually, through automation tools, or combined tests),
- comparing expected and actual results,
- verifying and validating test results,
- reporting bugs,
- retesting the bug fixes.
For QA engineers, this step is the most exciting moment from all the STLC phases. That’s when we test all the features that build engagement in your app. As a result, we become the first real users of newly raised features.
Step 5: Check & act
At this stage, we look back at the work we’ve done so far to see what we can do better before moving forward. Then, we monitor the whole process and modify it if necessary. If something is not working, we change it in line with the flow depicted above (Step 3). If anything is missing, we bring on additional tools. If needed, we include automation in any of the processes.
It’s all about optimization. We’re happy to try something new if there’s anything we could do to improve our work. Despite being in a later stage of the process, we stay flexible and are ready to be agile.
Reminder: Implement feedback throughout all SDLC phases.
Do not fight it.
Do not fear it.
Feedback is simply information about other people’s reactions to your product. Sharing it is a basis for further improvement.
Analyzing it means putting that progress in motion.
In practice, throughout the whole development process, Project Team proactively gives feedback and suggests possible improvements based on our experience.
And I genuinely think that’s what sets Untitled Kingdom apart from other software companies. Our core values are family, quality, and... transparency.
That’s the visualization of all the steps in Untitled Kingdom’s agile software testing life cycle steps. I may or may not have this as wallpaper in my kitchen wall to wake me up each morning.
As a result, we’re not only testing, reviewing, and iterating. We’re also keeping the code clean and maintainable, inviting our partners’ feedback throughout all the SDLC phases.
It allows both sides to feel comfortable and familiar with all changes we make (and will continue to do!) in the application. We believe that’s what truly creates an agile software development life cycle.
In many ways, it’s my second favorite step. Because it’s not the start of a conversation. It’s concluding all the work we have already done.
Conclusion: Why the 5 steps?
Customers’ trust is not easy to gain, but these 5 agile software testing life cycle steps (if done right!) guarantee to convey and deliver a high-quality product.
Quality Assurance starts the moment we begin analyzing product requirements. Its effectiveness is about more than just checking the bugs (no, it’s not just Step 4).
Only then, as testers, can we make sure that technology serves not as a goal but as a tool allowing you to reach your goal.
Plus, we can recognize user experience issues before they are created.
For all of us at Untitled Kingdom, building healthcare apps means creating truly comprehensive digital health solutions. That’s why our primary focus is the users.
It takes training and research, as well as understanding the struggles and emotions driving the users. That’s why our UK citizens have medical backgrounds - our team includes an electroradiologist, neuropsychologist, and neurobiologist.
But above all else: creating MedTech solutions is about building trust.
If users trust your app, they are more likely to reuse it.
And if you increase your confidence in the QA process, it will increase users’ trust in your app.