TechAIDBlogHow to design Good Manual Tests for any feature?
By Mike Arias 05/07/2019 145

How to design Good Manual Tests for any feature?

Picture this, you’re in a team working on a new product and you need to design a test plan for it. It’s the first time this product goes through any sort of QA process. Automation isn’t a top priority at the moment. The Product Owner wants quality out of his product, and the team needs a way to assess if the app is doing what it’s supposed to do. So, what do you do? R/ Manual Tests.

In this article, we’ll go over what, for me, is the best approach to tackle a new functionality in an application.





Before writing any test, or starting with the manual tests, you should focus on getting to know the product. Get familiar with the business rules, and know what the goal of the app is. Depending on the team and the methodologies being used, the documentation can be very useful for this. But if for some reason the documentation is not good enough, a meeting with the team is always helpful to get those tiny little details that make or break the application.

As soon as you feel familiar with the app, you can start designing a test plan for it. Usually, when dealing with this I try to follow a more or less standard approach.




The first thing I always look for in functionality that I’m about to test is the Happy Path. A Happy Path is the sum of steps the user is expected to take for a given functionality. Knowing the Happy Path will help us define how to variate from it in our tests.

Let’s say, for example, that we’re working for Instagram and they ask us to test the posting functionality. In this case, what would be the happy path?

Well, in this case, the user would likely be expected to use a supported device/OS, and use a normal photo taken with their phone’s camera with up to a 16:9 aspect ratio.

Every time we’re testing Happy Path scenarios, we should expect the app to work as specified and nothing else. This is the way most users will probably use the app and it should be working pretty much flawlessly.




When we start to deviate from the Happy Path, we’ll start to encounter several scenarios. These might not be exactly what we expect our users to do, but are totally valid and should work as well.

Going back to “posting a photo to Instagram”, the Happy Path would be to do all the processes from within the app… But, Instagram also allows us to post photos from the gallery app on our phones. This is not the Happy Path and is not what most users would do, but is a totally valid action that should be supported and handled gracefully.




After exploring our positive scenarios, we’ll know most of the things we should be able to do with our app. But this won’t give us the test coverage we need. We also need to know what our app can’t do and how it should behave in those situations.

Again taking a look at our “posting a photo to Instagram” use case, what comes to your mind that shouldn’t be possible? What about unsupported file types? Should the app support photos with huge file sizes? What about funky aspect ratios like 21:9?

These are a mix of scenarios where the app shouldn’t allow us at all to proceed, and scenarios where the app should adjust what we input to something that’s valid. This should all be documented and tested.




After clearing all the functional tests, we can dive deep into the non-functional side of things. The non-functional testing is a pretty deep rabbit hole that can go as deep as the team is willing to. The type of non-functional tests applied to a product is completely up to the team, their priorities, and the budget. My favorites are Compatibility and Stress testing. Let’s take a look at each of them.




When doing compatibility testing, all we are doing is checking how our system behaves with other systems. Things like the OS version of our app, the version of our browser, the browser itself, or even the device we’re using at the time can affect our application.

Testing a mobile application on an iPhone is definitely not the same as doing it in a Samsung. But at the same time, testing it in a Samsung is not the same as testing it in a Google Pixel. So these are all things that need to go into consideration when designing your test plan. Usually, the best bet is to go for what your user base uses the most to ensure that your product works as expected for the majority of your clients.




In stress testing, the goal is to test how robust our application is. This type of testing is even more important in “mission-critical” apps where a crash could mean a huge loss for the company or for the user. This type of testing puts emphasis on how the app responds to heavy load, its availability of it, and how it handles errors when they do come up.

Ideally, a system should never stop and if an error does happen, the app needs to handle it gracefully and give the user an option to keep using it. This type of testing is usually confused with Load Testing. The key difference is that with Load Testing, the goal is to test how the application handles the normal expected workload in an environment that simulates the real-world usage it will get. While with Stress Testing, the tester goes beyond this point to test the absolute limit under sub-optimal conditions.



In future articles, we’ll go over how to mix and match these types of testing to build a good Test Plan.


This article was written by Mike Arias
Senior Software Testing Engineer of TechAID.
Twitter: @theqaboy

GO BACK TO Software testing

Leave a Reply


TechAID Solutions: A Global Leader in Software Testing

By TechAID Admin 11/20/2023 0

We at TechAID Solutions are immensely proud to announce our recent accolade as a 2023 Global Award winner for Software Testing services by Clutch, the premier global marketplace for B2B service providers. This recognition is not just an award; it’s a reflection of our commitment,…

From Isolation to Collaboration: A Software Tester’s Journey

By Alex Dillon 07/06/2023 0

A Software Tester’s Journey As a software tester, I’ve learned that our role extends beyond finding bugs. We are a crucial part of the development team, and our ability to engage positively with developers can significantly impact the success of a project. I learned this…


Thank you for downloading our free resources.

We hope you can find it useful for your daily work. Learn more about what we do.

Your resume was uploaded!

Thank you for being interested in making part of our family.


¡Tu currículum fue enviado!

Gracias por interesarte en formar parte de nuestra familia.