https://wiki.kram.nz/index.php?action=history&feed=atom&title=SE401%3AGroup32%3ATool_WishlistSE401:Group32:Tool Wishlist - Revision history2026-04-06T15:48:35ZRevision history for this page on the wikiMediaWiki 1.45.3https://wiki.kram.nz/index.php?title=SE401:Group32:Tool_Wishlist&diff=10947&oldid=prevMark: 27 revision(s)2008-11-03T05:21:41Z<p>27 revision(s)</p>
<p><b>New page</b></p><div>[[SE401:Group32|◄ Main Page]]<br />
=Tool Wishlist (not completed yet)=<br />
<br />
This is what we want the tool to be able to do.<br />
<br />
#Run test cases automatically with little interaction by the tester<br />
#'''Be generic to different mobile devices'''<br />
#Generation of test reports detailing test outcomes<br />
#Test cases for Usability Testing (See below for the standards we are focusing on)<br />
##'''Aesthetics'''<br />
###Be able to test whether the given application can fit in the screen on the mobile device.<br />
###Be able to test whether the appropriate buttons and forms are displayed correctly.<br />
#Non-intrusive to users - While testing, the operation of the tool should be hidden from users.<br />
#Extensibility - The tool should be able to be used on a wide range of applications with little modifications made to it.<br />
<br />
#Functional Testing<br />
##Be able to test whether specific functions are doing what they are supposed to be doing.<br />
<br />
#Non-Functional Testing<br />
##Performance in terms of response times<br />
###Is the application performing in the a specific time <br />
##Resource usage<br />
<br />
<br />
Note: Most important is at the top<br />
<br />
==From Neilson's 10 heuristics the ones we think are most important to test are:==<br />
<br />
*'''Consistency and Standards''' - Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.<br />
*'''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.<br />
*'''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.<br />
*'''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.<br />
<br />
<br />
<br />
[[SE401:Group32|◄ Main Page]]</div>Mark