Why Manual Testing Is Better For Software Startups

by Pranab @ www.dotsandarcs.com

Manual testing has been in deep waters for a while now. Automation is gaining favor among developers really fast, and to some people, it may seem like the end for manual testing is near. But I’m here to tell you that that’s not happening anytime soon, especially for startups. Manual testing isn’t going anywhere, and I’ll tell you why in this post.

The Myth About Automation

Sure, automation is great to use when dealing with large projects that require lots of system users. Automation also works great when there’s a lot of form-filling to be done repeatedly, because honestly, manually doing that gets incredibly boring after a while, and the attention span of a human goes out of the window pretty quickly in such situations.

Automation sounds great in theory. But there’s a myth about it that many of us tend to believe in at some point of time.

Many people, especially those who don’t completely understand automation, think of it as some sort of magical pendant that will always protect the wearer (the program, in our case) from harm (bugs). This belief stems from a lack of proper understanding of automated testing.

Here are some hard facts that tell you what automation really is like.

1. Automation testing isn’t nearly as automated as one might think. It still requires the right tools and a considerable amount of time to write a good automation script. And even after running the script, you can’t forget about it and go sip coffee at your desk as you lean back casually in your chair. It still needs your time and attention.
2. Automation requires stability. This is possibly the most important thing to remember: automated testing can only be integrated into your system when you have a stable infrastructure. Writing automation scripts takes time, and you can’t afford to rewrite them every time you make a small change in your build.
3. Automation doesn’t provide an opinion. This is often overlooked by some people, but is actually crucial to building a good product. An automated test cannot tell whether your product is broken or not. Its sole purpose is to detect any differences between the expected outcome and the actual outcome. It picks up changes in the behavior of the program, and reports that. It doesn’t know or care about the nature of the change. The change could be good, bad, or perhaps, even irrelevant. You have to check that manually.

Now, the actual purpose of a good automated test — stress on “good” — is to help the user form an opinion more easily and efficiently, but good automated tests are hard to create.

No, I’m not kidding you here.

Creating good automated tests takes time and real engineering proficiency. If you think you can buy a software package and hire any QE to do the work, you’re in for major disappointment. If you really want to get value out of your automation tests, your whole engineering department needs to pay attention to the process.

Are you willing to code in a way that facilitates automation? Can your developers design and redesign the product in ways that make it easy to perform automation tests? How about deployment? Can you easily deploy new versions of your product? Is your design modular enough?

These are just some of the important questions you need to ask yourself before you consider automation testing. They require serious thinking. Many software startups think they can get away with it, but good automation is actually a big investment, and most bootstrapped startups can’t afford it.

Why Manual Testing?

Let me sum it up for you in 4 simple points:

1. Easy exploratory testing: A manual tester not only checks the product in ways already presented to him but also explores it on his own. He can come up with new ways to explore the product, which is also called monkey testing. An automated test cannot do that. It only does what it’s been set up to do.
2. Finds real user issues: Manual testers are human beings just like your end users, so they are more likely to find real user issues. An automated test doesn’t act like a real world user would, and hence, can’t tell you much about your product’s impact on the user.
   Manual testing can find bugs likely to be encountered by a real user much more quickly, and allows for expedited changes. It is also much more effective when testing for user-friendliness and a positive experience on the whole. Automatic testing can’t achieve this because of the lack of human observation and intuition.
3. Flexibility: It is not uncommon to get a really great idea at a random moment, and when that happens, you want to get right on to it. You want to test it immediately, because time is of the essence. But this isn’t possible with automated testing. With manual testing, you can start doing it straightaway, but with automated testing, you need to set up test cases and program them into the tools. At times like these, manual testing wins hands down, letting you test ideas quickly and check their feasibility.
4. Economical: Let’s face it. Pretty much every startup wants to save money when starting out. There’s a lot of hit-and-trial in the initial stages, and automation scripts don’t like it when you do that. When running an automated test, you are obligated to keep things the way they are for the most part until the test is complete. If you change your product’s behavior, in all likeliness, all your automation will have to be rewritten, which can be very cumbersome and expensive.

Manual testing is much more affordable than automation testing, at least in the short run, especially in a developing nation like India — where good talent is still not very expensive. So it’s wise to go the manual way, atleast to begin with, till you have a stable infrastructure.

After all, money saved is money earned.

With that said, let me just state that I’m not here to put automation testing into the ground. It is useful and can be beneficial to you in areas where manual testing suffers, like low level interface regression testing.

But manual testing is still the way to go for startups, or any developer really, until they have a solid base ready.

Manual testing puts the software through as many real-world situations as possible. An automated test will always put the code through a situation A and see if it gives the outcome B. That’s all it will do because that’s what it is programmed to do. It cannot suggest, it cannot decide, it cannot adapt, and it cannot explore what will happen when your software is presented with a situation C you didn’t think of. And believe me when I tell you, a user will inevitably find a way to hit your code with something it didn’t anticipate.

To conclude this post, I will just say that you cannot do away with manual testing, because in the end, your app is going to be used by humans. Developers spend countless hours writing and rewriting code for their programs, but to what end? If we can’t provide an engaging user experience and the intended functionality to the end user, we might as well pack our bags and go home.

That’s what we have done for zipBoard. The entire team has manually tested the application, and used it as real people. Along with finding bugs, this process has been magically helpful to make zipBoard more intuitive, and user-friendly for our end-users.

by Pranab @ www.dotsandarcs.com