Skip navigation
Brigham Young University
STAR Upgrade Project

PeopleSoft Testing Helps


As the PeopleSoft project continues to move forward, more and more modifications will be ready to test. The following are some testing strategies given by James Whittaker, Professor and Director of the Center for Software Engineering Research in the Computer Sciences Department at the Florida Institute of Technology. Dr. Whittaker frequently speaks about testing to large corporations, including Microsoft, where his talks are typically standing room only. Here are some of his suggestions regarding testing:

Apply Inputs that Force Error Messages to Occur

Why? This is important because the program should either appropriately respond to bad input or prevent bad input from being entered.

How? Try entering in data of the wrong type. For example, if the field is supposed to be a number, try entering a letter or another character. If the field is only supposed to accept a 9 digit SSN, try putting in 5 digit number of a 10 digit number. Try to get every error message that you know about to appear at least once.

Force the Program to Use Default Values

Why? When values are not entered into fields, the system must assign some default value or not allow the process to continue (required fields). If the default values are invalid or the system continues to process without a value for a required field, you have a problem!

How? Leave selected values empty and document what the page does. Check other pages that might be populated with the data you just entered (or didn't enter) and see what is there.

Force results to be too large or too small

Why? To test the boundaries that the program can operate in.

How? If you have a page that computes values based on input that you give it, put in some outrageous values that you may never see in real life and see what the result is. It could be that you get back an incorrect result or the program doesn't display it correctly.

Document your Test Cases

Why? When Engineering attempts to fix a reported problem, it is very helpful to know how to recreate to problem quickly. Also, testing documentation serves as a valuable resource for future upgrades and modifications.

How? Be diligent in documenting each test case and the steps involved in TENS. If you have questions regarding how to document your testing, contact Shanda (x21555) or Alisha (x29448).

Remember: Have fun! Get creative in your test cases. Every problem we uncover now is one less problem we will have to deal with later (sometimes at a much greater magnitude).

** These ideas and more are found in Dr. Whittaker's book How to Break Software: A Practical Guide to Testing, Addison Wesley, 2003. Bug picture courtesy of Texas A&M Department of Entomology (agnews.tamu.edu/ agex/forensic.html).

Last modified: June 23, 2006. Maintained by Webmaster.

Copyright © 1994-2005. Brigham Young University. All Rights Reserved. XHTML CSS 508