Author: Kevin Tuck

Without us actively thinking about it. We all make assumptions about multiple situations, activities, and future events daily.

From the reason our friend isn’t answering the telephone, what that new restaurant down the street is like, and what we are doing next Friday evening are all assumptions, sometimes based on prior experience and knowledge, but always made with the understanding that you may not know the definitive answer. But the conclusion is your best guess.

Some assumptions are safe, like, for example, if I press this full stop on my keyboard, one should appear on my screen. I was correct.

Let’s say you are the creator of a popular camera filter app for the Android platform. You introduce a new feature that you test thoroughly and are sure your current users will love. So you publish the change for everyone to download and wait for the feedback from your users.

The new version goes live and you see people are downloading the new version. Then the emails starting coming in.

‘My app doesn’t work.”

“I can’t access my photos. ”

“Was this tested?“

Uh-oh. 

The source code looks right, and it compiles without issue. What could be the problem?

It takes a special person to have held the position of window cleaner for the Empire State building back in the 1930s. Strapped to the side of the highest building in New York City, with their entire existence being held by a thin strip of leather (sweaty palm moment).

But the same is true of software testers.. just not that dangling off high-rise buildings bit. Someone might already be competent at their current role but may struggle with software testing.

Here are just a few of the qualities that you need to possess to be efficient and effective as a software tester.

Manual testing can be quiet bothersome.

Having to write all these test cases and then execute them a hundred times. Can’t we get a computer to do it for us?

Well, in certain circumstances it makes absolute sense to make the use of the computer and code an automated routine for us using Selenium or another automated tool. If all were doing is rerunning a test to check for regressions in the functionality then sure, why not? But this isn’t always the case and automated process can’t perform the same functions that a human can.

Excellent, one of your test cases has failed, and you have exposed a defect in the application that needs to be corrected ASAP. Time to raise a bug report for the developers to action.

But before you load up your bug tracking software and hit that Create New Issue button. Ask yourself… is this a bug? And how can you best highlight this so it gets the attention it deserves by the development team? 

Software testing is not just a formality that your product ought to go through before it is released to the public. It instead should be thought of as an invaluable part of your development process that can prevent you from releasing a piece of software that is not fit for the use by the end-user. But how does a tester perform testing? Where do they start?

This is where the Software Testing Life Cycle (or STLC) comes in. This is an established step-by-step process that guides you through the core approach to your test projects. Promoting consistency, each stage of the process has been planned to safeguard the quality of your product and boost test effectiveness,

Another piece in the ‘box method’ of software testing. This time we will be looking at white-box testing, which is also known as structural, clear-box, or glass-box testing to name a few of its aliases.

The name is derived from the concept that the tester can see through the box to the internal workings of the software, which of course is opposite to black-box testing which is purely functional and only deals with the inputs and outputs of the application.

If I ask you to verify something on a project for me. What would your instincts be?

And if I asked you to verify that same item. Would you think I was talking about the same thing, or asking a different request?

Don’t worry if you’re a little confused at the moment. These terms often get misunderstood when it comes to software testing but they mean two separate and very different procedures that serve complementary, but very separate purposes.

In this blog post, I will go over the black-box method of software testing. Often referred to as specification-based testing. This software testing method can be applied as soon as the user requirements are formed, allowing for testing activities to begin as early in development as possible.

But what is black-box testing? What sort of tests can the method be used in? And why are we using a box to perform software testing?

Testing documentation (or artifacts) are of huge importance to any successful testing effort. Not only do they fulfil the requirement of having a written account of your overall testing process for future reference. But in the instance of test cases, they will provide you with steps for future reference, thus making them available for additional members of your team to execute, or in the case of a well-written test case, reuse in future testing.

But what makes a good test case? And how do you write one in such a way that anyone can understand and follow?

Read More