“I Don’t Know How To Work With An Outside Tester, Help!”

I’ve been talking about importance of testing in my last couple of blog posts. The two most common questions I’ve been getting are, “What can you expect a tester to do?” and “How are you supposed to work with a tester?”

If you have never tested with a professional before, it can seem difficult.

But in reality, working with an outside tester is going to make your life so much easier.

You’ll probably forget that you’ve hired a tester altogether…until your get the finished product back — clean, functional and ready to launch.

So how does it work?

Let’s walk through a couple of scenarios together.

Starting a New Project, Or a New Section of an Existing Project.

You usually start with an initial project familiarity meeting, which will the formal kickoff of the project. In this meeting, you’re going to go over your project in detail.

So in that discussion, you’re going to talk about you and your project. That includes fleshing out the project duration, deadlines, and who all is involved (for example, the project manager, tech leads, a developer, etc). Finally, your tester will be involved in this meeting, so they’re kept in the loop from the beginning.

Your tester will create a software test plan from two documents: the requirement document and the project plan. The project work is divided into different modules and these project modules can be distributed among the developers who will carry on with the development activities.

In the meantime, your tester will be at work creating test scenarios and writing test cases according to the assigned modules. Test cases cover how the application is supposed to work, what input needs to be given, and what output is expected. They also cover all possible error messages. These are going to help ensure that the risk of error is minimal and that you and the tester don’t run into communication issues.

Here is an example of a test case that we have written recently.

When developers finish the individual modules, those modules are assigned to the testers. Using the test cases that were already, the testers carry out manual testing. If they find bugs, the bugs are logged and returned to the module developer.

On a “bug fix,” a tester does bug verification and runs tests of all related application modules to make sure everything is fixed. If a bug passes the verification it is marked as verified and marked as closed. Otherwise, the bug cycle gets repeated.

One great advantages of this process: the developer also knows exactly what tests will be run on his code from the very beginning. That’s much more useful to him that a requirement document that only contains high level details. The end result: the testers get it right the first time, and spend less time going back and fixing bugs.

Ad-hoc Testing

So what happens if a lot of development is going on across several different projects and you don’t want to pause to write test cases?

Ad-hoc testing is your answer.

In this process, you simply embed a tester within your development stream and ensure all output goes through a tester BEFORE coming to you, or going to the client.

So, the process kind of looks like this:

> The developer completes a task and uploads to staging / dev server.

> The tester reviews the tasks and confirms it’s working.

> The work uploaded to live server.

Ad-hoc testing can be done almost any time – in the beginning, towards the middle and towards the end. There is a time and place where ad-hoc testing will bring you maximum value. However, that time best judged by an experienced and professional tester who has in-depth knowledge about the system being tested.

Ad-hoc testing is not as foolproof as structured testing. However, it is very effective in reducing defects and spotting basic issues that your developers were unable to fix. Your tester will know the best time to do it.

What’s Next?

So, when you test with reputable outsourcing agencies, nothing is left up to chance. Reputable companies will eliminate the potential for error, clearly define all parameters, and make sure that everyone involved is given all necessary information.

That’s how a professional tester is able to perform better in a shorter time frame than if you were to undertake all the testing yourself.

Now, you could still test everything yourself…

But it’s highly likely that you would end up with a worse ROI than if you had just gone to a tester professionally.

Not to mention all the productivity you lose doing all the testing yourself. Losing energy during the long nights. The stress of watching your deadlines slip away. The uncertainty you get when you realize that you might end up launching a buggy product.

Believe me, I get it.

If you came in for a consultation at my agency, and you wanted to know an efficient, cost-effective way to make sure you’re launching a truly excellent product, I would say the same thing: A professional tester is the best option.

My recommendation: simply set aside a portion of your development budget for testing. It should be easy, because most reputable agencies will give you a quote.

That way, you’re sure to keep a good ROI, avoid the stress and endless testing cycles, and launch a high quality product.

Now …

I want you to keep a look out for my next blog post. It’s got more details about the special offer discussed in the last blog post. Go and read it if you haven’t yet — something very exciting is coming your way in the next few days.

And as always, comment, like, and share. We want to hear from you.