How to Test Your Outsourced Software
Here’s the scenario: Your hired software programmer uploaded a deliverable and you want to make sure everything works according to specs. After you download and install the submission, the program looks terrific and all the buttons “do stuff.” Is it ready for distribution? Should you go ahead and release payment for a job well done?
The answer is an unequivocal “No way!” A slick interface is a sign of well-designed programming, but the minute something doesn’t work right, all that work will be for naught – and once you sign off on the project, there’s no turning back. You have to take the time to check everything first.
Forget about the 4 Hour Work Week. Some things simply can’t be rushed, like software testing! Adequately testing your software could very well take longer than 4 hours. It could take 4 weeks or months for Pete’s sake, and the duration of testing depends on the complexity of the software and your penchant for detail.
Here’s how to test your software and make sure it works the way you want it to, prior to paying for it and releasing it to the public.
Use the Software as a Noob
Sometimes, it’s best to approach your software as if you’ve never seen it before and you don’t know how it works. This strategy will give you the same fresh perspective that your end-users will have. It will also give you some insight into what your end-users will think about your program and how they’ll use it. So click everything the way a new user would.
Click on what you’re supposed to click, and then click things that you aren’t. Clicking things that you’re supposed to click will verify they (hopefully) do what they’re supposed to do. Clicking on things that you aren’t supposed to click on will expose unplanned errors.
Test with Dummy Data
“Dummy data(link to samples from several types of programs)” is text that doesn’t mean anything. Its purpose is to simply exist and expose errors in software that hasn’t been programmed to adequately handle it. So load up your software and import some dummy data into it. (You can generate your own dummy text at this website.) Notice what happens when text is displayed where numbers should be displayed (and vice versa).
Speaking of numbers, if your program calculates them, are the calculations accurate? Use dummy data of various sizes. How well does the software handle a 5mb file of dummy data? What happens when you try to load an image into a music program? What happens when you put data into the wrong fields?
Answering these questions will help you direct your hired programmer’s error routines.
Get Out of Order
Both programmers and software testers often make the mistake of thinking users will use software the way they programmed it, which is typically in some sort of order. The truth is, users often use software in unpredictable ways. As a tester, you have to do the same. So interact with your submission in an order that doesn’t make sense.
After starting the software, you could try to save something that you haven’t even loaded yet for example. You could try to paint a dialog box or record a help file through a microphone. It sounds silly, but it’s necessary foolishness(merge this article with Paying for Bug Fixes). You’ll want to make sure the software displays the right error messages and gives users the option to undo mishaps without crashing.
Get Others in on the Act
Two brains are better than one, and when it comes to software testing, it may be better if one of those brains belongs to a computer-inept person. No offense, but the pc-incapable are simply invaluable when it comes to testing software for the simple fact that they’ll use software in a way no one would ever predict. Of course, you’ll additionally want to test the software with someone who does know what they’re doing, since they can easily spot out things that should happen, but don’t.
Run Your Software on Different Machines
I recently read an article that compared speeds of various well-known internet browsers, and though I’m sure I was supposed to be impressed, the article failed to explain the factors that could (or couldn’t) have influenced the results. So make sure you test your software on machines with varying RAM, disk size, and CPU.
See what happens when the software is run on a computer crammed with other software programs. Try different operating systems, screen resolutions, speakers, etc. The results will range from being perfect to being absolutely horrifying, and it’s your job to ensure your programmer codes a solution that satisfies the most common user conditions.
Test Corrections
Unfortunately, correcting an error isn’t the end of a buggy situation. You absolutely have to test the software again, just as extensively as you tested it in the beginning. Why? A “correction” in one part of a program could cause an error or two in other parts of the program, and if you don’t look for these errors and fix them, your users will – as a refund request!
I finally took the plunge and tried Microsoft's Virtual PC as a testing environment. It's a great idea for folks who are limited to testing on just one computer. Unfortunately, Virtual PC was really slow for me. Then I tried VMWare, which currently runs perfectly. I highly recommend it!
Testing outsourced software isn't hard but it require time..