Skip to main content
summaryrefslogtreecommitdiffstats
blob: 3c7932e4faaccf3773c53cf8a95a69ce780bfbb7 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
% $Id: approaches.tex 7776 2009-01-30 17:08:26Z alexandra $
% Local Variables:
% ispell-check-comments: nil
% Local IspellDict: american
% End:
% --------------------------------------------------------
% User documentation
% copyright by BREDEX GmbH 2004
% --------------------------------------------------------

Testing is critical to the success of software projects. It is especially important to acceptance test software which is designed for end users.

There are various ways to go about performing acceptance testing, each with their advantages and disadvantages. 

\subsection{Manual Tests}

Manual testing, although thorough, cannot keep up with the pace of development. It is impossible to carry out complete continuous integration and regression tests manually. 


\subsection{Programmed Tests}

Writing tests in some kind of scripting language is certainly powerful, but it puts a strain on the resources of a team, because the test code itself becomes a project in its own right and also needs to be checked and maintained. The extra costs added by programming GUI tests can be considerable. 

Tests written in code also have the problem that they no longer view the software as a black box and may miss important aspects relating to the acceptance. In addition, automation experts (experienced software developers) become the only people who can write or maintain tests. It is generally inadvisable to test your own work, but this is what can happen if testing remains solely in the realm of the developers. Writing tests without coding from the black box perspective not only allows test experts to automate tests (and therefore brings the test perspective to the forefront), but also puts developers in the shoes of the users, which helps to focus and improve the test.  


\subsection{Recorded Tests}
\label{IntroRecording}
Possibly the most popular approach to automated functional testing is macro recording, that is, recording a user's actions for later playback.
The appeal of this approach is the apparently quick success that can be seen: a test script can be quickly recorded and played back, giving the impression that automated testing is nothing more than recording a manual test. 

However, this approach fails to meet the needs of large or long-term software projects for the following reasons:

\begin{itemize}
\item Test specification begins very late in the development cycle,
 as recording can only begin once the software is available. 
\item Since only the user action is recorded, checkpoints for verification
of test results have to be inserted manually.
\item Recorded tests can only test parts of the application which already work. \item There is also the danger that the implementation of the application will be tested, instead of the requirements. 
\item Recorded scripts are often very large and not particularly 
well-structured. Making changes at a later point is therefore 
difficult and requires programming skills, which further increases costs.  
\item Code generated by recording generally doesn't conform to
 common software quality attributes such as reliability, stability, 
portability, maintainability, and usability.
\end{itemize}

In essence, a recorded script is not an automated test. It must be refactored to remove errors and redundancies, to make its component parts modular and reusable and to insert the intelligence of the manual tester to make the test robust. Once all this has been done, there is probably very little of the original recording left, and a great deal of development work has been done to refactor the script.  


\subsection{The \app{} approach}
\label{JBApproach}
\app{} makes lets you automate tests which follow the best practices known from software development (readability, modularity and reusability to ensure maintainability), but without any programming effort. 


This gives the following advantages: 

\subsection{Early test creation}

\app{} tests are created before the \gdaut{} is available. This is a radical advantage over capture-replay tools, which force testers to wait until an application is ready to begin with testing. The specification of modular, flexible GUI tests begins early (even as early as at the requirements stage) and continues alongside software development.\\ 
The benefit of this is that every version of an \gdaut{} can be tested as soon as it becomes available. Testing keeps up with development, so you waste no time in your test process. Earlier testing lets you find issues when they are cheaper and easier to fix and encourages collaboration and communication within the team.

\subsection{Code-free automation}

Tests are automated completely from the user perspective and require no programming effort. \\

This means that those who understand the user perspective best are able to fully automate tests. There is no need to wait for input (e.g. programmatic creation of test modules) from other team members to automate a test. If developers are writing tests, the black box perspective encourages them to think like a user would when faced with the software. Code-free tests also have the advantage that they are readable by the whole team and also by users or customers. 


\subsection{Manual tester intelligence}

The wide range of keywords available in \app{} include high-level actions which can be meaningfully used by testers. There is also a wide range of check and synchronization actions to incorporate the necessary robustness into a test. 

Back to the top