katwilhoit

 Profile Answers by katwilhoit 

• Feb 18th, 2010

 

For general software functionality:

Scope: Describe the basic object/goal of the software and functions to be tested. I always begin with the outputs and work backwards. If specifications and requirements exist for the item already, then obtain those, and review them.
The software must produce specific outputs, like a report, or an EDI file, or a completed order form, or just manipulate specific records in the database, etc. I like Pert charts for this part along with a general description, to chart the breakdown of the general processes needed to complete the test. The break down should be as small as "unit" testing meaning, if one user has to enter a certain record, then another user or process does an automated something, then the output appears, then you have 3 items to go in the chart. Use arrows to indicate the flow, and dependencies on other processes.

Organize:
1. Identify the baseline functionality that must be viable to pass the test, and list all features.  You can use something as simple as Excel for this, or a numbered table in Word, where each numbered item requires the user to enter, or execute something in the user interface, and each process that executes that has a "stopping" or evaluation point in the process. i.e. if you enter 3 values, and press Save and a record is created, then that is a stopping point, and probably would be 4 lines or instructions in a "unit" test. Gather all documents known for this starting with any government regulations that must be met, like national coding schemes or EDI formats in X12.
Have copies of the Requirements and Specifications.

2. Document Hardware/OS to be supported; and external software conditions to be met. You may need test cases for multiple Hardware/OS/Application configurations.
3. Identify the Average User, which tells you the viability of the workflow and entry process. Know the "job description" of each user. Software must be organized enough to support the user, in their natural environment.
4. Identify all parameters and conditions of the information process being supported. Inputs, outputs, database updates, name and document acceptable values for every parameter. For each parameter (input or output value) Include all code lists values, and edits on each field, by requirement, format, and value. List default options for any paramter.
5. Determine all logic descriptions formulas.  - this part is the most difficult for complex processes, because it determines the number of different test cases you'll need, based on varying conditions of incoming data to process. You'll have a number of cases at the end of this based on the variations, inputsXindexesXformulas.
6. Write that number of test cases. Write one case, to begin with, progressive, with only required values for the beginning "unit" test. Manually validate each test as soon as the function is available to test. Adjust as needed.  
7. Volume and Speed -Identify a normal number of data records that would be significant for the software to process in a specific amount of time. Usually my  test group will write a small program that inputs a single test case, as many times as the record number we're testing for volume and then use that over and over until we hit limits. In one case, we wrote a name generator and a UID generator that combined to register as many people as we wanted to test, then a script to clear it out of the database for repeat testing, and tuning. Some automatic testers do this easily and some require so much input that having programs within your software for tests, are more valuable, and can be used in implementation or diagnostics as well, later. 

Executing Tests, may involve logistics, multiple users or scripts, so you might be dealing with a single QA tester or a concerted effort of several people at once.  Meet, explain, schedule, countdown, begin.