mar/content/case_experiment_test_protocol.tex

%&tex
\subsection{Test Protocol}
\label{sec:test_protocol}
    The last step of the preparation phase is to design tests.
    The tests are designed to validate if the system meets the specifications.
    While defining the tests, it became clear that part of the specifications was not explicitly defined.
    As the specifications were made before the design decissisions in the initial design and the feature definition, the specifications did not take that information into account.
    Updating the specifications after the design decissions was overlooked during the specification of the design plan.
    To ensure the repeatibility of the tests, this step starts with specifying the order of operation and improved specifications.

    \subsubsection{Defining the Order of Operation}
    There are two modes of operation: writing and wiping.
    Defining the order of operation also distributes the responsibility between the different components.
    The writing operation can be split in the following steps:
    \begin{order}{Writing}
        \emph{Precondition:} Marker as end-effector.
        \begin{enumerate}
            \item Move cable driven carriage to position of characters.
            \item Write three characters with the SCARA.
            \item Repeat step 1 and 2 till the Tweet is on the board.
            \item Move carriage away from the text on the board.
        \end{enumerate}
    \end{order}

    The other operation is wiping.
    This is similar to the operation of writing with the following steps:
    \begin{order}{Wiping}
        \emph{Precondition:} Wiper as end-effector.
        \begin{enumerate}
            \item Move cable driven carriage to position of characters.
            \item Clear the area in reach of the SCARA.
            \item Repeat step 1 and 2 till the Tweet is removed from on the board.
        \end{enumerate}
    \end{order}
    Furthermore, switching between the states requires the tool to be switched.
    However, at this point, it is not known how tools will be switched.
    Therefore, the order of operation is determined during the development of the end-effector.
    Additionally, the missing order of operation for the end-effector did not result in difficulty while defining the tests.

    \subsubsection{Improving Specifications}
    Based on the order of operation, the following specifications were added to the list in \autoref{sec:specifications}:
    \begin{specification}
        \begin{enumerate}
            \setcounter{enumi}{12}
                \input{content/input/speclistc.tex}
        \end{enumerate}
    \end{specification}
    These additional specifications are also based on the combined system decission that was made in section \autoref{sec:initialdesign}.
    These specifications distribute responsibility between sub-components.

    \subsubsection{Setting up the tests}
    With the updated specifications it was possible to create a number of test cases.
    In total there are five small test cases and four large test cases.
    The small tests cover a sub-system and the large tests apply on the complete systems.
    Each tests has a list of specifications that are covered with the test and for smaller tests the subsystem under test is also determined.
    With a short description it is described how the test should be performed.

    One of the small tests focusses on the speed and range requirements of the SCARA:
    \setcounter{testcounter}{0}
    \begin{test}{Small rectangle}
    \input{content/input/systemtest1.tex}
    \end{test}
    Repeatability is tested in one of the large system wide tests:
    \setcounter{testcounter}{5}
    \begin{test}{Repeatability}
    \input{content/input/systemtest6.tex}
    \end{test}
    The complete set of system tests is included in \autoref{app:test_specification}.

    \subsubsection{Evaluation}
        This step was completed without many difficulties.
        Which includes the revision of the earlier specifications and definition of orders of operation.
        Indicating that I overlooked details while defining the specifications in \autoref{sec:specifications}.
        According to the design plan as described in \autoref{chap:analysis}, I should go back and review those specifications.
        Followed by reviewing all steps after the specifications.
        However, this complete review is not practical and extremely time consuming.
        The point here is, looking at the evaluations of this and previous steps, that chosen design strategy is not feasible, especially as a novice designer.
        In \autoref{chap:case_evaluation} I will evaluate this with more detail.

        During the analysis, I expected more specific tests.
        Each test could then be used as a milestone during the development of the system.
        Every time detail is added, an additional test passes.
        Or a test fails, notifying that something went wrong and should be investigated.
        Creating such specific tests relies on the details in the design of the system.
        The current design is basic and these details are added during the feature implementation.
        Nevertheless, this step resulted in a set of tests that cover all specifications and features that are specified in this preparation phase.
        When all the tests pass, the system should meet all the requirements.