From 6c635965035841435f71c50b374150c9fab22e7a Mon Sep 17 00:00:00 2001 From: pimjager Date: Tue, 6 Oct 2015 22:52:24 +0200 Subject: [PATCH] update quality characteristics and add Issue tracking --- 2approach.tex | 9 ++++----- 3eval.tex | 20 ++++++++++++++++++++ 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/2approach.tex b/2approach.tex index 76b1e1a..98aa460 100644 --- a/2approach.tex +++ b/2approach.tex @@ -47,11 +47,8 @@ to the SUT. to send and receive data it needs to be \emph{fault tolerant}. The SUT needs to properly handle errors in received data or complete unavailability of the underlying channel. - \item \textbf{Security}\\ - \emph{Confidentiality} is an important aspect for the SUT. Received data - should only be delivered to the program to which it is addressed. \end{itemize} -This leaves three categories which are not relevant the SUT. Below we will +This leaves four categories which are not relevant the SUT. Below we will shortly discuss per category why these are not relevant. \emph{Maintainability} is an important aspect of any software system, however for the SUT it is not a core aspect, as it is first and foremost of importance that the implementation @@ -59,7 +56,9 @@ is correct, furthermore TCP does not change often. \emph{Usability} isn't a core aspect either, as the SUT is not used directly by humans, but is a service which is addressed when another program needs it. \emph{Portability} isn't either as the SUT is installed on a system once and intended to work on that -system. +system. \emph{Security} isn't a feauture of the SUT either, systems using the +SUT can add their own security mechanisms on top of it. + \subsubsection{Quality in use} Quality in use is dived into five subcategories. Below we will discuss the diff --git a/3eval.tex b/3eval.tex index f57c493..19a1441 100644 --- a/3eval.tex +++ b/3eval.tex @@ -12,3 +12,23 @@ quality of the product. \subsection{Test ware} \subsection{Issue tracking} +Whenever an issue is detected (a test fails) this issue needs to be recorded +such that this incident is added to the test report. It can then be determined +if the incident was the result of a fault in the SUT or was caused by something +else, e.g. an error in the test. + +The record of a incident needs to hold all relevant data such that the incident +can easily be reproduced later. Therefore each incident will be recorded in an +incident report, which will include the following details: +\begin{itemize} + \item When the issue was detected and by whom. + \item Which test detected the issue. + \item Expected results. + \item Actual Results. + \item Relevant logs, screenshots or other data which is needed in + addition to the test itself to reproduce the incident and which + might be beneficial to it's resolution. + \item Other areas of the SUT which might be affected by the incident or by + a change resulting from the incident. +\end{itemize} + -- 2.20.1