What Can You Learn from Software Testing?

Software Testing is a crucial element of any software development project and it should not be overlooked.

In this blog, I will detail some of the key takeaways from my research and practice as a software tester, in hopes of giving you some real insight into the benefits and pitfalls of software testing.

I don’t think the word “testing” accurately reflects what testers do. I prefer to use the word “assurance”.

Testing sounds like it is something that happens at the end of a project when you have nothing else to do (or when you’re desperate).

Assurance sounds like something that should happen all of the time during software development.

Cem Kaner: “Testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results.”

I don’t like the word “evaluation” either. Perhaps that’s because for too long I was involved in formal inspections and evaluations where the goal was to find defects.

We often found them, but we rarely found solutions for fixing them. A better word might be “investigation”. And perhaps I don’t like “requirements” either, because it is so open-ended (and vague). The definition might be better if it said “intended results”.

My point isn’t to nitpick, but to make a point: most people understand testing as a checking activity – it’s about finding bugs and reporting them.

As a QA professional, I am constantly learning new things. But there are a few lessons that I consider to be my favorites. These are the lessons that I find myself repeating to other people, again and again.

Read Code

Reading code is more important than writing code for a tester in an established product-development environment because it helps you to understand what the program is supposed to do and how it is supposed to do.

It’s especially important when you’re testing a feature that programmers wrote before you started testing.

And reading code written by other team members can help you learn their style and anticipate problems they might have run into while writing the feature you’re going to test.

Track Bugs Faster

The hardest part of software testing is knowing when you’re done. If you ask people to find bugs in your software, they’ll do it. They’ll never stop finding bugs.

The only way to stop them from finding bugs is to stop asking them to find bugs. So how could it be decided?

Obviously, there’s no fixed rule. But there is a good guideline, that is when the marginal cost of finding another bug exceeds the expected benefit, you should probably stop testing.

Another way of saying this is to make sure you know where to look for bugs before you start testing.

Wherever that place is, concentrate your efforts there first because that’s where the most important bugs are likely to be.

That’s what Microsoft did with Windows Vista; they started by looking for security holes in the code they had rewritten, and fixed those first.

That made sense because security holes are the worst kind of bug; if an attacker can exploit one, he can make your whole system crash or take over all your data, regardless of how many other bugs are in the system. So get rid of those first, and then worry about everything else.

Testing is Model-Based

All testing is based on some model of the product, and all tests are valid only with respect to that model. The model can be explicit or implicit; it can be documented or in people’s heads.

A specification is a common kind of model. For example, you might have a written specification for the product, and test cases that were developed before the software was written and that refer to that specification.

That would be an explicit model, in a document (which could be an electronic document).

But sometimes there is no such specification. In this case, the only documentation of what the system is supposed to do might be the code itself (and even this isn’t always true).

In this case, your model is whatever picture of how things are supposed to work you’ve gotten from reading the code.

This isn’t necessarily any less explicit than a written specification; it’s just in a different medium: your head instead of a document.

In either case, whether the model is explicit or implicit, you have to have some idea about what you expect things to do before you can test them.

Your Test Scripts Define You

When we think about what it means to write software, we tend to imagine sitting at a keyboard, typing code.

And most of the time, we are typing code. But a lot of what we do as programmers involves writing other things: comments, documentation, tests, specifications, and so on.

A program is not just the code in it. It’s also the documentation, commentary, and test cases that go with it—all the stuff you write to understand and communicate what the code is supposed to do.

The code by itself isn’t all that useful; you have to know how it works. And as Knuth points out, what we write for human consumption is often harder than the code itself.

I’m not sure how many programmers realize how much writing they do in their job. I certainly didn’t when I started out.

Writing specifications and testing software was something that one did only after finishing with programming itself, as a kind of an afterthought.

Now I think of them as inseparable from it; not just because specifications and tests play an important part in writing good software, but also because they define what good software is.

Rotate Testers Between Projects

The best software testing is a combination of static and dynamic analysis. Static analysis is reading code and looking for problems, while dynamic analysis is trying to run the program and see if it breaks.

But even when it works right, you can’t read code forever without getting tired, so you need to switch back and forth between these two modes.

A good software tester reads code till he gets bored, then runs the program till he gets bored, then back to reading code again. If you do this all day long, you can find many more bugs than doing just one or the other.

It’s also good to rotate testers between projects. Don’t know why but this works.

When you are working on a project for a long time, all kinds of little decisions get made that make sense at the time but that may be hard to explain later.

New testers are better able to pick out things like this and ask about them.

Use Cloud-Based Platforms

There are different types of software testing like manual testing, automation testing and so on. The best way to do software testing is to test all the time and by that I mean, get your entire company involved with testing. Yes, your company!

If you want to start doing this right now, I recommend using cloud-based tools. These tools are easy enough for non-technical people to use and they also provide access to a huge number of devices (real phones and tablets) so you can see how your product looks on different screen sizes/resolutions.

Nowadays there are many tools out there that allow companies of any size to automate their mobile testing efforts.

If you’re testing a software product like website, app , you might use the cloud-based platform called LambdaTest.

To test your websites and apps using LambdaTest, you write a single test that runs on LambdaTest’s servers.

Then you indicate that you want to run the same test on all of LambdaTest’s thousands of virtual machines, each one running a different operating system and browser.

When the test finishes, you’ve automatically tested your app on every imaginable combination of OS and browser.

LambdaTest offers Selenium automation testing, Cypress test automation and Appium testing for automation tasks.

If you were doing this yourself, it would take forever. But LambdaTest has thousands of machines running on cloud at its disposal, and so can run thousands of tests in the time it would take you to run one.

The benefit is not just that it’s faster and easier. It’s also that by running your tests in the cloud, you can make sure they work on all browsers, even ones that don’t exist yet.

For example, let’s say a new operating system or browser comes out tomorrow with a bug in it. You will be able to run your test immediately to see if it picks up the problem.

Key Component

In conclusion, it can be said that software testing is of vital importance. It is a key component because it improves consistency and performance by identifying and subsequently removing errors.

Without testing, software production could be futile or sometimes could be vicious for customers. So being a tester you must always protect the reliability of the software and make it free from harm to use in real-life scenarios.