SE401:Group32:Tool Wishlist

From Marks Wiki
Revision as of 05:21, 3 November 2008 by Mark (Sọ̀rọ̀ | contribs) (27 revision(s))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

◄ Main Page

Tool Wishlist (not completed yet)

This is what we want the tool to be able to do.

  1. Run test cases automatically with little interaction by the tester
  2. Be generic to different mobile devices
  3. Generation of test reports detailing test outcomes
  4. Test cases for Usability Testing (See below for the standards we are focusing on)
    1. Aesthetics
      1. Be able to test whether the given application can fit in the screen on the mobile device.
      2. Be able to test whether the appropriate buttons and forms are displayed correctly.
  5. Non-intrusive to users - While testing, the operation of the tool should be hidden from users.
  6. Extensibility - The tool should be able to be used on a wide range of applications with little modifications made to it.
  1. Functional Testing
    1. Be able to test whether specific functions are doing what they are supposed to be doing.
  1. Non-Functional Testing
    1. Performance in terms of response times
      1. Is the application performing in the a specific time
    2. Resource usage


Note: Most important is at the top

From Neilson's 10 heuristics the ones we think are most important to test are:

  • Consistency and Standards - Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
  • Error Prevention - Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
  • Flexibility and efficiency of use - Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
  • Aesthetic and minimalist design - Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.


◄ Main Page