|
|
 |
Software Testing Procedures |
|
|
|
|
|
|
October 14, 2010
|
Fix Remote Printing Problems Now!
ScrewDrivers, triCerat's flagship print management software, stands out as a leader for third-party corporate remote desktop printing. Request more information today!
 |
Software testing can be quite an undertaking with today’s complex software packages. When thinking about testing software that reaches across multiple operating systems and platforms, like ScrewDrivers does, you have to consider several things.
1.) Testing on all platforms is only one piece of the puzzle.
Having the proper equipment is key to testing any software; you shouldn’t just test it on Windows XP and call it a day. What about Windows Vista, Windows 7, or the Server OSs, not to mention the 64-bit versions of each of those?
2.) Break the software.
Proper testing procedures will also make or break the QA process. Don’t just test the basic features. Check all features and try to combine them. End users can be unpredictable when it comes to using the software, so try to think like a user and do things that a user might do – right or wrong. Use a spreadsheet to track all the functionality testing.
3.) The bigger the software package, the bigger the team needed.
Proper staffing is very important because one person can’t possibly test a extensive software package like Simplify Suite - something is bound to get past them. It is very important to develop a strong team and give each teammate an opportunity to test every module. Not only does this help the process since every person is different, it also reinforces the team knowledge of the software.
4.) Document. Not sure if it’s important? Write it down anyways.
Documentation is also key to a successful testing process. You’ll want to make note of every little bug you find and how you stumbled upon it. Make sure to never leave any details out, as that one extra click might be the missing link in the process that the developer needs to triage the issue. This also helps post-release so you have documentation in case a customer finds a bug or has an issue. It’s much easier to look through a version history than to troubleshoot the issue to later on, learn that it was a bug and that there is already a custom fix for it that you could have sent to the customer or end user.
The testing process is much more involved than what I’ve described here, but at least now you have an idea of what to expect. While it can be very repetitive and at times boring, The Tester is the mediator between the nasty crippling software bug and the end user.
-Nick Nikitkin - triCerat Tech
|
|
|
|
|
