Server Side Rendering (SSR) is a method of generating app directly on the server. One of its benefits is a high performance because when a user sends a request to get code, the HTML and CSS part...
Testing an application on a deadline — assuring quality in two weeks’ time
“You have to create this application in the next 14 days”, a client told us during one of our recent projects. It might sound like an impossible mission but not for a well-organized team. The application was meant for patients in Nigeria looking to book a remote appointment with a doctor.
The client told us that because of the pandemic, the government was planning on introducing new safety restrictions. The goal was clear. We had to develop this app before a full lockdown. So is it even possible to create the MVP (Minimum Viable Product) for your business in 14 days? We knew it would be hard but not impossible so we told the world: “Hold my beer!” and got down to work.
Testing an app: Fortune favours the brave
When you don’t have enough time for testing, you can't include everything that you would usually carry out. That is obvious. You have to compromise and set your project’s priorities. How to deal with that challenge? The solution is to focus on the app’s core functionalities. It helps you find out as much as you can about the final users and the business goals of your client.
This attitude allows you to plan efficient tests and understand what is the major aim of the project. Besides, good communication with the client is the key to deliver the most appropriate product within the time range. If you aren’t aware of their needs, you can develop a beautifully written program but not the one the client wanted.
After we got this information, we started to think about optimizing our standard procedures and flows to meet the deadline. The job ahead of us was demanding but very rewarding. Do you remember this feeling when you are about to start working on something fascinating? When you work non-stop and forget to check what time it is? We were feeling like a part of something big and it was our fuel to go on.
In app testing, only the genius rules over the chaos
How did we face this challenge? In three words: organization, optimization and communication.
Build a small team
Ours only had eight people: five Developers, one Designer, one QA Engineer, and one Project Manager. Why didn't we get more people on board? Because having a bigger team might have affected productivity. A smaller group leads to more engagement, accountability and productivity. That was exactly what we needed.
Distribute the workload
We broke up large tasks into smaller ones and defined the final scope of the project. Everything within the scope was relevant, anything outside of the scope was to be ignored. It is crucial to follow these rules because it's harder to deliver a product on time when its scope broadens. Well, we didn't reinvent the wheel.
We sped up the development process by using the tools we already use. In a nutshell, Jira improved team communication by bringing consistency and structure to the way we tracked progress. Confluence was our knowledge storage. Github let our engineers collaborate on the same source code without stepping on each other’s toes. We created two separate repositories: one for frontend and one for backend developers.
Good team communication is also key. We used Slack to chat with each other and Google Meet for our daily meetings. It’s hard to imagine product development today without these tools now that they are a standard in many companies.
Practical tips from the app testing battlefield
How to test when you don't have enough time and you want to assure quality? You can’t use your usual methods as always. I can tell you how I approached the matter and give you some tips. Are these methods good in every situation? I don’t think so but in this very case, they worked.
Create tickets in a tracking system only if necessary. Most of the time I described bugs directly to the developers via Slack. When something was more complicated to describe, I used screen recordings of what was going on. It made us faster at fixing issues without needing to open tickets.
Protip: on macOS, there is a native program for recording screen and voice. You just have to press cmd+shift+5 to launch it. It works well and you can attach these videos to Slack or Jira in a few seconds. For Windows or Linux, you need to install an additional program. There are many available on the Internet.
Meet frequently but not for a long time. Shorter daily meetings have a positive influence on the team. Do you need to talk to the backend developer about the latest implementation? Just ask him to stay for a bit after the meeting. It saves everybody’s time.
Record some videos for the client instead of having a demo meeting. All clients like to be updated. Instead of a long demo meeting with the whole team, just record a video when new features are implemented and describe what is happening on the screen. This saves time for the whole team who can focus on developing the next tasks.
Document the current issues. After all, we are only human and it’s in our nature to forget. It is good practice to write down all the crucial upcoming tasks and found bugs. Plus, you can send the list of bugs to developers in a single message and won’t have to ping your teammates every single time.
“And the winner is...”
We did it! The whole team stepped up and we finished this application in 14 days, including launching the production server. We delivered the fully working MVP product on time to the client. It wasn’t an easy task but we adjusted our procedures and workflows to that unusual situation. Now people in Nigeria can book a remote appointment with doctors via our application. It’s a good feeling to change the world for the better!
If you’d like to know more about the completed project, have a look at our case study.
You may also like...
Implementing new ideas into reality is always hard. But as it is with the creation of every product, not only software projects, correctly selected tools can make this road much smoother. Let&rs...