Testing complex apps: how to break & fix them

Quality assurance is an important part of building and releasing software. Just as a new airplane model goes through rigorous testing, complex software also needs to be brought to its limit and fixed so it works smoothly for everyone.

Why is testing so important? Through a proper testing process, you can find a new app’s breaking points before it actually reaches the public. You don’t want your software product to break on release day, do you? It makes for a terrible user experience and gives your customers the impression that you don’t know what you’re doing.

Even though it seems like a tedious, costly process, testing your app and fixing the issues you find can help you tremendously along the way. Otherwise you risk gathering a lot of bugs that will eventually break key features and render your app unusable.

So in this article, we’re going to talk about the best ways to test complex apps, how to plan for it, how to find issues and how to manage the process of fixing them.

Step 1: Understanding

The first and most important step of testing complex software is understanding it. There’s no way you can properly look for issues if you don’t fully know how the app is supposed to work - you won’t know if certain flows are bugs or features, as that famous quote says. And that’s a big problem.

And when we say “understanding” we don’t mean just knowing, overall, what it’s supposed to do. To properly test an app, you have to understand every bit and piece of it. What every single button does, what every action leads to, what happens when you don’t fill in specific bits of information, how to create or edit certain items, which user types are allowed to do what, and so on.

Sit down with your development team and make sure they explain everything to you. Ask as many “what does this button do”-type questions as possible and don’t hesitate to reach out to them outside of meetings to ask additional questions. Since it’s your product, it’s essential to know its ins and outs.

A big part of this step is sorting development and testing tasks properly. When you do eventually start testing your app, you gotta know what has actually been coded and what not. Keeping all tasks organized in a kanban board can be very helpful - and it’s, in fact, standard software development procedure.

Make sure, before you and/or your team starts testing your app, that all features that are testable are clearly listed in your task board. Otherwise, you risk testing tasks that are still in progress. This means making it clear to your developers to move tasks to the correct state as they work on them.

Step 2: Planning

Before heading into testing your app, it’s best to actually organize the testing process itself. This means setting some goals, outlining what your testing session should achieve. Here are a few examples of goals your testing process can have:

• Testing out all user flows to ensure that they work properly
• Looking for edge case scenarios that break the app
• Checking if the app’s UI matches its original design
• Making sure the app works well on all screen sizes (unless it’s not made to be responsive)
• Re-testing old issues that have been fixed before (but which can always resurface or have broken something else)
• Testing issues signaled by users and/or retesting such issues after they’ve been fixed by the development team

As we’ve already mentioned, it’s important to keep track of your development tasks in kanban boards, using platforms such as ClickUp or Jira. Specifically, divide tasks by their status: in progress, not started, awaiting a pull request, ready for testing, complete, reopened, are just some status examples you can use. By dividing tasks in their respective status, it’s easier to keep track of what you can test and what not. Plus, you can see which major features are still in progress and which you probably won’t be able to test.

Of course, most businesses who build software know about the Agile methodology are probably already using the system we’ve just described. But just doing the dividing of the tasks isn’t all of it - you gotta keep your task boards up to date for maximum efficiency, and add all useful details to each task, especially more complex tasks that will need to be tested.

Sort tasks by how long they’d take to test and plan out how many you can fit into your schedule. A lot of things can go wrong when testing, features break, servers can go down - so add a reasonable amount of extra time to each estimate you make. This will help you organize the testing process.

In order to not go back and forth between sections of the app or user types, we recommend sorting the tasks by their main features and user type. This way, you’d test everything dealing with super admins at once, and then tasks related to simple admins or regular users. You wouldn’t go back and forth between accounts. 

Same goes for specific sections of the app - for an online store, sort all tasks related to the checkout process in one place, and those related to product browsing in another. Again, so you don’t go back and forth between them.

Step 3: Test away

You might think this is the clearest step. You open your testing tasks and just get down to it. But unfortunately, like many things in life, it’s not that simple. Some testing tasks could involve different variables. Different ways an app’s flow can go. If you uncheck a certain checkbox, does the system detect your mistake? If you type an email address wrong, does it let you finish creating an account? If you type in an invalid password, does it tell you that you did so? All of these can go into one single page - the sign up.

Authentication is one of the most basic and important functions of an app. And it’s not always the simplest - the way you fill in sign up forms can have so many variables, as we showed you before. You can either type everything in correctly, using valid data. You can then type in some stuff wrong, like excluding the @ from your email address, to test whether the app detects your mistake. You can leave everything empty and click on “create account” to ensure it won’t let you do that. You can type in an email address that already exists.

The point here is that with every feature, there are many different test cases you can do. When you gather more experience in manual testing, these will come naturally to you. But before that, it’s best to make lists. Jot down different ways you can test each feature. Developers might even tell you that you need to break the app - so think of creative ways you can screw things up. It’s for the greater good, trust me.

Here are some common ways to test a specific app feature:

• Do everything exactly as intended. If this test case passes, it’s good, but it doesn’t guarantee that you don’t have any bugs. 
• Do one or more things wrong. In this situation, you get to test your app’s error detection and whether said errors are specific and accurate. You could not fill in an email field when making an account and the app would just tell you that “Something went wrong” but not make that field red. That’s a good example of a bug.
• Find a ridiculous edge case. And by ridiculous I mean something no one, especially the devs, would have thought of. This is relative to the kind of software you’re building and might not be a thing if your software isn’t too complex. You might need the expertise of a seasoned tester for this one, but the key is simply acting stupid within your software.
• Retest old issues. New pieces of code sometimes fix other issues or break features that were working before. When your devs push code to a part of the app that used to have a lot of bugs, make sure to retest issues you’ve had before to make sure they’re truly gone.

As you test, report all issues you find in the appropriate place you settled on with your entire team. Add them to your boards in Jira, ClickUp or whatever you use. In order to not lose track of them, add issues as you find them. It might prove tedious, but it’ll help in the long run. If possible, assign developers to the issues you add - this ensures they don’t lose track of the bugs you find.

When adding bugs to your Jira or ClickUp boards, here are a few things you should include:

• Make the title short and clear and start with the part of the app the bug is on. It’s quicker to find and sort tasks when their titles start with the app feature they’re about. If the bug only happens on a certain type of user’s account, start with that as well. Here’s an example: “Super admin - User Settings”. Then quickly describe the issue without getting into all the details - that’s what the description is for. Name the main issue. For example: “Password change doesn’t work”.
• Retrace your steps in the description. Unless the title is very specific and there’s no need for extra details, never leave the task description empty. A good thing to do here is to describe the steps you took that led to the bug. This is the best way to help your developers find the issue. The 2nd best way is to include console data, in the case of issues where things don’t load (or server errors): to do that, right click on the page you’re on and select Inspect. In the panel that opens, click on “Console” from the list at the top. This can vary depending on your browser.
• Add screenshots and/or screen recordings. The more unspecific the bug, the more useful the screenshot. Show the devs exactly what happened when you tested - don’t keep them guessing. If you’re on Chrome, a good extension for screenshots and screen recordings is Nimbus.

Step 4: Adapt & learn

As you constantly test your software, you’ll eventually find the best ways to do it, how to move more efficiently and how to give your developers the information they need. You can’t become an expert on testing overnight. Cut yourself some slack and take it step by step: understand your app, plan your testing process and be meticulous.

What happens when you test and you don't find any issues? Here are a few things to consider:

• You might not be testing well enough. Your developers might be great, but software is rarely perfect. You might only be scratching the surface in your testing process and not finding edge cases. Keep trying to break the app. Do things you shouldn’t do.
• Try automatic tests. You developers can implement a system that automatically tests parts of their code. It’s not foolproof, but it’s a great way to evaluate the app’s code. If these tests and your manual tests both yield positive results, then the app truly is good to go.
• Ask for customer feedback. If your app is live and available for download, keep an eye on user feedback and reviews. This is a great way to find issues within your app, although it’s not good publicity. Fix said issues and reply to those reviews confirming you did so.

What happens when you test and find a lot of issues? Well, if the app is still in progress and not at a point where it should be working perfectly, this is just a regular part of software development. Invest time and effort into fixing the issues before you release something. Sit down with your team and prioritize tasks, decide what is more vital to the app and focus on those. Smaller bugs can go on the backburner, but not forever. Don’t let them pile on, as they might break other features down the line.

When your bugs are fixed, one important thing to do is retesting. You gotta confirm that the bugs have been fixed and the issues don’t exist anymore. It might seem pointless, but sometimes you might discover that a bug fix broke something else. It’s just how code acts. Be diligent with your retesting and don’t hesitate to retest bigger features instead of just the tiny issue you initially found.

And there you have it, these are some of our best tips on how to test complex software. A big part of it is planning and keeping in close contact with your development team. Keep in mind you work together and doing so as a well-oiled machine can come as a great advantage. Pay attention to customer feedback and don’t dismiss bugs that harm your app’s user experience.

If you’re looking to get software built or bugs fixed, we can help you out. Contact us and let’s discuss what we can do together. Or if you want us to play around in your software and find your UI/UX pain points, we offer that for free here.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.