Fog Creek Software
Discussion Board

How to be the best tester in software

If one preson is just 17 and he is staring his life in the software testing prdouct in baced of web applactions
and he want to be the great & best tester for his product

pls try to help him and give good advice 

aditya sachdev
Monday, March 17, 2003

The most important piece of advice I can give you is : always start testing from a totally clean PC. I'm more familiar with testing desktop app installs, but for a web server I'd say is much the same.

Get some imaging software (I use PowerQuest DriveImage), and make sure you can quickly get back to a freshly installed PC. Make sure you can always get a complete build off development at any time (daily builds are your friend!)  This is closest to the environment your customer's going to be in, after all.

Make sure you always do a trivial test that briefly checks each bit of functionality, so that there are no bugs that will completely stop the end user doing what they want. Do this, even if it's just testing a new build with one small functionality change.

A surprising amount of rookie testers don't realise this, so they end up okaying software that only ever works on two PCs - theirs and the developer's.

Better than being unemployed...
Monday, March 17, 2003

Ditto clean pc. I use VMWare.

Make sure you document what you are testing.

Preferably before you start, make a 'test script'. This is just a list of the parts of the application's functionality and the order in which you intend to test. Have a printed copy so you can easily make notes, write test data used and check off the parts that you have approved.

Find out what different parts of the application are supposed to do BEFORE you start testing. Just because something doesn't work like you think it should, doesn't mean its broken. Check with the designers.

Most important: If something does not pass your test, say why you think it is wrong, give the exact data you used to test and how you got to that part of the functionality (all this should be obvious from the 'test script').

If you are asked not to test something because e.g. its not finished, write 'Not tested' in the relevant section.

Make sure you act stupid when testing. E.g. Try and do things in the 'wrong' order. If there is an 'Amount' text field enter ‘45.77’, ‘45,77’ or 45.77$ and things like that (Yes the dollar sign is in the wrong place).

Got an empty form to fill in? Do nothing and press the submit button. Its important to test with no data as well as wrong data. Also paste in way too much. If the instructions for text entry say "enter 6 characters", Enter 7 and see what happens.

Don't stop halfway through testing for somebody to fix something you've just found. Test everything you plan to then submit a list of all problems. If you are prevented from testing further, say so and say why.

Be prepared to be abused. You're being paid to identify problems with other people's work and this will not endear you to them. Be professional, calm and polite. You're doing them a favour; better that you find problems than their customer.

Make sure you find out before hand how rigorously you are supposed to be testing. Are you supposed to be testing things like tab order, alignment of controls, consistency of labelling, existence and usefulness of help or have you just been told ‘have a look at this and see if it falls over’. Developers become irritated if you are exhaustive in your testing of something they are still working on.

Before you start, find out if the client (your manager/supervisor/the dev team/etc) wants you to raise a single fault log for common errors (eg the tab order is wrong) with a list of all the instances, or if they want you to raise a new log every time you find a new instance of the problem. Error logs can be political. A summary report may show a hundred errors against an application, which sounds really bad until you realise they all say “Guest spelt as geust”.

Monday, March 17, 2003

Learn the scientific method.  Live it.

Monday, March 17, 2003

Easy. Don't leave it until the last fucking minute to tell people that "ooh, that's not right" like some fsckwits here, when "that" has been the way the software has worked from day one.

Monday, March 17, 2003

The best testers break things.  They understand the requirements better than the developers - because most developers have to struggle with some detailed implementation.  Read the specs, devour the specs, question the specs, be involved in the spec writing. 

Don't sit around waiting for someone to tell you to do something.  Good testers should be involved in the design phase.  Push on your developers to design for testability.  Initiative, initiative, initiative.  If you find yourself with nothing to do and noone is involving you in design, and your organization is not accustomed to this notion, then ask to write specifications.  They will need to be written by someone, sometime, and you'll learn what is going on early on by asking questions to complete the job.  Then, when it comes time to test, you'll know what is going on and you'll have some documentation about what it is you're testing.

Think "AUTOMATION".  How can I make a machine do the testing job?  Being a "smart" user is boring.  And machines can break code so much better than humans.  Machines are faster, and they can gang up on the unit under test.  You just cannot stress our running code as a human the way a machine can.  Be the terminator.  Take pride in your ability to force that developer's code into submission. 

Above all: INITIATIVE.  Do not wait for someone to come and ask you to do something.  They are all too busy trying to complete their goals to worry about yours.

Nat Ersoz
Monday, March 17, 2003

I know a few good testers and all of them are skilled programmers, knowing the details of an application's internals helps greatly, plus they write their oen scripts/tools/etc (when they need to). The more you know about programming and software in general, the better tester you become IMO.

Monday, March 17, 2003

Like Nat said, "the best testers break things."  This means don't just create tests to prove the code is correct, create tests to prove the code is wrong.  It sounds like a small difference, but it's important.  If you're evil, that may help.

Be prepared to read a lot of code, looking for sections of logic that don't normally run.  Be sure your tests execute every branch of logic at least once.  You don't need to test every possible input value, but be sure that you identify "boundary values" such as the minimum and maximum allowed by the datatype, the min/max allowed by the procedure, zero, etc.  Be sure to try these values as input, as well as values on both sides of these values.

Learn what tools are available to help with testing, and try them.  You mentioned web applications.  Try HttpUnit to test the user interface, and something like the Microsoft Web Application Stress Tool for load testing and reliability testing.  For more general-purpose testing, take a look at some testing frameworks:

Monday, March 17, 2003

Be destructive - imagine you were the biggest enemy of the person who made the application, so that you will keep trying to find errors and bugs in order to embarrass him. That's also why programmers should never be testers of their own code ;-)

Monday, March 17, 2003

Oh, I almost forgot one of the most important things to test for, expecially with a web application!  Security.  You probably want to learn about using threat models to determine which security areas to test.  There's a good presentation on threat modeling by Michael Howard, one of the main guys behind Microsoft's Trustworty Computing initiative.  Check it out at
He claims that 50% of all Microsoft's security-related errors are discovered during the threat-modeling process.

As Michael says, "you aren't done with your design until your threat model is complete."  This then drives testing.  Another nice benefit of threat modeling is that it allows the tester to be involved much sooner in the process.

Monday, March 17, 2003

If the product you are testing has daily builds, I highly recommend using a binary search of old builds to discover in which build a newly discovered bug was first injected. This makes the bug report soooo much more valuable to the developer who has to fix the bug. They'll thank you big time!

Monday, March 17, 2003

Document any problems you find in clear, concise language. Explain exactly how to reproduce the problem. Describe what behaviour you observed, and what you were expecting to see. Include the build version you were testing, and also write down any weird configurations or situations you were testing under.

There's nothing worse for a developer to be assigned a bug that just says "the froogle doesn't work" or "data entry is broken" or something.

When a developer gives you a fix for the problem, try to re-test it as soon as practical. If it's still not quite right, the developer will be able to fix it quickly while that part of the code is still fresh in his mind. The longer you wait, the harder it becomes for the developer to slip back into that problem area, and you end up wasting everyone's time.

Darren Collins
Monday, March 17, 2003

+1 for VMware.

It has the ability to roll-back disk changes, which is ideal for a "clean-room" test environment. Using a single decent PC with a lot of memory, you can not only test any setup imaginable, but test the server and client as virtual PCs simultaneously.

Brad (
Tuesday, March 18, 2003

Also Check out MSDN for some good articles on testing.

Prakash S
Tuesday, March 18, 2003

*  Recent Topics

*  Fog Creek Home