As Developers we want to build applications that meet your needs. Comprehensive and timely testing helps make that happen. Below are some guidelines regarding what you can do to help us deliver the best product.
Timeline for testing:
- Please try to respond to a request for testing within 1-3 business days or prior to the morning before a demo (typically a Thursday) to allow for time for changes to be made.
- If a request for testing feedback is received within 2 days of the demo (usually on the Wednesday prior to Demos), noon the day before is acceptable (developer to indicate this in testing request).
- If feedback is not received prior to noon on the day before demos, delivery may be delayed.
Communication between Developer and User:
- The developer will communicate completion of work on the project (
...
- by email).
- If no changes are required, please respond to a request for testing feedback with some indication to this effect.
- If changes are required, please outline them, with screenshots if possible.
- Once changes are made and communicated by the developer, please do another round of testing, and respond whether your concerns have been met/the application meets your needs.
General Testing:
- Look only at things that are new or changed. This is not the time to get other things fixed. (That said, if you find bugs in other areas of the application while testing, please feel free to submit those as bugs!)
- Always do testing in SISTest if possible.
- Make sure to run through the expected process at least once (consider both visual and process testing). We’d rather fix any bugs with this new feature now than after delivery. Your feedback is critical to making this happen.
Visual Testing:
- Look for any spelling and wording issues
- Are things where they make the most sense to you?
- Does this new feature have visual flow?
Process Testing
- Does this new feature make sense to you? If you can’t understand how something is supposed to work, that might indicate that something is missing.
- Run through the standard workflow with multiple test students
- Think about flow. If this feature is part of a repetitive workflow, does anything about the design feel frustrating to use?
- Check to make sure data is saved and looks correct. Close out of the application/window and make sure that data is retained
Intensive Testing (time permitting):
- Use the feature in non-standard ways. Try to break things.
- enter things in the ‘wrong’ order.
- quit without saving.
- change tabs while in the middle of editing.
- save partial data.
- enter the wrong things.
- See if you can make any error messages appear
- Think about possible validation steps (ex. can you enter letters in a field for student ID?)