what's the best way to aid your tester?

Question

my company is small with only one full time tester, and mostly we're doing web apps. so i'm glad that we have tester as i think i would probably be bias or lazy when debugging my own code...

and our tester is actually located in another country, so usually we communicate via IM or email only. usually i try to do as much white box testing as possible but sometimes due to tight schedule i need to handle a few stuff at the same time and that's where i get rather lazy on post-testing... :(

currently what we usually do is to provide some documents with what the features should be like and hopefully they will have enough information to break whatever that is not working properly.

and sometimes i also include information or test cases on some of testing that i've done, and include also some test based on the potential faulty code logic that i would want her test explicitly.

whatever she finds she will log into our bugzilla and i will proceed to check it, fix it and get her to verify it again.

so my question do you have any good tips or better way so that we can aid our tester better in finding more bugs?

thanks ~steve

Answer 1

Since your tester is in another country and there will be some lag time between you passing something to your tester, and your tester getting back with the results, I think it's important the you do a lot of your own quality assurance to ensure that your code is

1. Fully functional
2. Handles basic problems like bad input

So that you don't waste your tester's time and your own time with bugs that shouldn't have even made it into testing stage. Hopefully, because you will be working so closely with your tester, the tester will get to know your standard bugs and be able to test those things quickly, and hopefully they will be able to pass on what they see as frequent problems so that similar bugs don't pop up all the time. I think the key here is communication to ensure that you aren't wasting any time fixing the same thing over and over again.

Answer 2

One of the huge benefits of an independent tester is that she will invent scenarios that we, as developers, would never consider. So a lot depends on her understanding of the system and the users, and on her creativity.

I try to help our testers by:

1. Telling them what I've changed, and what other parts of the system are likely to be affected,

2. Ensuring they understand the customer requirements, so they know how the system is supposed to work,

3. Asking for feedback about their subjective observations (it's too hard to ...; it takes too long to ...; the screen is ugly because....), and

4. Encouraging them to find creative ways to break the system after they've verified that it works the way it's supposed to for "expected" inputs.

Also, if you're working in different time zones, use that to your advantage by providing as many updates, fixes, etc. before you leave for the day, so she can work while you're asleep.

Remember, there are two parts to validation:

1. The system should do what it's supposed to do, and

2. It shouldn't do what it's not supposed to do!

Good luck!

Answer 3

Sounds like you are already doing two important things:

1. Do you best to find your own defects. (Although doesn't sound like you are working with any automated unit tests, which could help in this area)
2. Valuing the feedback that you get from testing.

Two additional things I would recommend.

1. You both need to get a clear definition of what needs to be done.
2. Provide completed functionality on a regular basis.

This is a bit of a balance between:

A. Provide Release Notes with a clear description of what was done

B. Regularly release with incremental functionality introduced.

Answer 4

Wouldnt it be better to NOT aid the tester in some cases? Are you going to be present to aid all the users when they run your program?

Answer 5

I am actually a tester myself. The best aid I get from our DEVs is what we call happy path testing. This is basically telling me if the program works exactly as it should based on the Technical Requirements this is how it is supposed to funtion.

For instance if you have a hello world application were if you click the button your label says hello, you would say exactly that Click button label text with be Hello.

We also have our DEVs pass their documented UNIT Tests to me and then I just make the test broader than they did. This is a great help. Our unit tests will always answer these four basic questions WHO WHAT WHEN and HOW. Who did the change. What was changed. How it works now. When it was changed.

Also being prompt with answering questions and giving all information to the tester upfront is great. I hate when DEVs give me an app and just say "here you go ready for testing". This is the worst possible scenario because I have no idea what it is or how it is even supposed to function.

If you give the Tester this information they will be able to find true bugs and possible missed requirements.

Answer 6

Automate him out of a job! Of course, you can't do that, but you should have a good, fast automated test suite so that he can focus on the things that can't be automated.