mar/content/case_experiment_test_protocol.tex

%&tex
\subsection{Test Protocol}
\label{sec:test_protocol}
    The last step of the preparation phase is to implement a test protocol.
    The tests are designed to validate if the system meets its requirements.

    While defining the tests, it became clear that part of the requirements was not sufficiently defined.
    The current requirements apply to the complete system and is not updated for the design choices made in the initial design.
    If the tests are made based on the current requirements, they can only be performed when the complete design is implemented.
    To create tests that apply to specific features or compoments, the requirements had to be updated.
    This update adds order of operations and additional requirements, which are explained in the following two sections.
    The third section explains how the tests are formed based on the up-to-date requirements.
    
    \subsubsection{Defining the Order of Operation}
    There are two modes of operation: writing and erasing.
    In these situations, the end-effector holds a writing or erasing tool respectively.
    By defining the order of operation for each mode, specific requirements are assigned to the \ac{scara} and the \ac{cdc}.

    The current design uses the \ac{scara} to write characters on the board at a static position.
    When these characters are written the \ac{cdc} moves to the next position:
    \begin{order}{Writing}
        \emph{Precondition:} Board marker as tool in end-effector.
        \begin{enumerate}
            \item Move \ac{cdc} to position of characters.
            \item Write three characters with the \ac{scara}.
            \item Repeat step 1 and 2 untill the Tweet is on the board.
            \item Move \ac{cdc} away from the text on the board.
        \end{enumerate}
    \end{order}


    The second order of operation is about the erasing.
    Removing text from the board is done by the following steps:
    \begin{order}{Erasing}
        \emph{Precondition:} Board eraser as tool in end-effector.
        \begin{enumerate}
            \item Move \ac{cdc} to position of characters.
            \item Clear the area in reach of the \ac{scara}.
            \item Repeat step 1 and 2 till the Tweet is removed from on the board.
        \end{enumerate}
    \end{order}

    A possible third order of operation is tool switching using the end-effector.
    At this point, the design of the end-effector is not definitive enough to determine an order of operation.
    Additionally, not having an order of operation for the end-effector did not hinder the definition of tests.

    \subsubsection{Improving Requirements}
    The defined order of operations add more requirements to the system.
    Two of the new requirements specify the operational behavior of the \ac{scara} and \ac{cdc}, based on the order specified above.
    To ensure that the overall system can still write one character per second, the \ac{scara} and \ac{cdc} must both complete their task in three seconds.
    Therefore, two seconds are assigned to the \ac{scara} to write three characters and the \ac{cdc} gets one second to move the \ac{scara} to the new position.

    A fifth requirement is added because it was overlooked during the previous steps.
    The five system requirements are in addition to those in \autoref{sec:specifications}:
    \begin{specification}
        \begin{enumerate}
            \setcounter{enumi}{12}
                \input{content/input/speclistc.tex}
        \end{enumerate}
    \end{specification}
    These additional requirements take into account that the current design consists of a \ac{scara}, end-effector and \ac{cdc}.
    Where each of these components has a different role and thus a different responsibility in the system.

    \subsubsection{Setting up the tests}
    Based on the updated requirements, a set of test cases is created.
    In total there are five small and five large test cases.
    The small tests cover a single compoment or feature and the large tests combine multiple features.
    Each test specifies for which requirements they apply and include a description that explains the test.
    The smaller test cases also indicate on which feature or component they apply.
    All ten tests are included in \autoref{app:test_specification}.
    The following is a small and a large test case from these ten.

    One of the small tests focusses on the speed and range requirements of the \ac{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}

    \subsubsection{Evaluation}
        This step was completed without many difficulties.
        Eventhough this step included an unexpected revision of the earlier requirements and definition of order of operations.
        Indicating that I overlooked details while defining the requirements in \autoref{sec:specifications}.
        According to the design plan as described in \autoref{chap:analysis}, I have to go back and review those requirements.
        Followed by reviewing all steps after the requirements.
        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 evaluate this with more detail.

        During the analysis, I expected more specific tests.
        Each test can 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 has to 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 requirements and features that are specified in this preparation phase.
        When all the tests pass, the system should meet all the requirements.