1
edit
Changes
→Project Task List
<td>TBD.</td>
<td>Not started.</td>
</tr>
<tr>
<td colspan="4"><strong>Implementation of Delta Debugging & Driver</strong> ([http://www.st.cs.uni-sb.de/papers/tse2002/ Simplifying and Isolating Failure-Inducing Input, Ziller and Hildebrandt, 2002.])<br />
</td>
</tr>
<tr>
<td>General Algorithm</td>
<td>The general delta debugging algorithm implementation. For details, see [http://www.st.cs.uni-sb.de/papers/tse2002/ http://www.st.cs.uni-sb.de/papers/tse2002/].</td>
<td>[[User:dwwoodsi|Dean Woodside]]</td>
<td>Work in progress, check SVN repository from time-to-time.</td>
</tr>
<tr>
<td>Minimizing Algorithm</td>
<td>The minimizing delta debugging algorithm implementation. For details, see [http://www.st.cs.uni-sb.de/papers/tse2002/ http://www.st.cs.uni-sb.de/papers/tse2002/].</td>
<td>[[User:dwwoodsi|Dean Woodside]]</td>
<td>Not started.</td>
</tr>
<tr>
<td>Schema Defintion of Driver Data</td>
<td>A simple XSD which defines the driving test type (e.g. user interaction, program input), the minimal set of circumstance (scenario) to reproduce the failure, and the expected outcome after automating the circumstances.</td>
<td>[[User:dwwoodsi|Dean Woodside]]</td>
<td>Work in progress, check SVN repository from time-to-time.</td>
</tr>
<tr>
<td>Choosing a Record/Replay Facility</td>
<td>In the case of scenarios that require user interaction (namely, mouse actions), the framework will require a record/replay facility that will record user interaction the first time through and then replay it later during the automation.</td>
<td>[[User:dwwoodsi|Dean Woodside]]</td>
<td>Found some Windows tools in James Whittaker's famed [http://www.howtobreaksoftware.com/ How to Break Software]. Checking these out for their appropriateness. Tending to think we might have to roll our own (can't script existing ones [/well/]).</td>
</tr>
</table>
