Effectiveness of software testing techniques in enterprise: a case study

Figure 4. The Software Testing timeline 
Prepared by author according to Sources: 
(Gelperin & Hetzel, 1988; “The History of Software Testing,” 2015)
Hass (2008) claims that "there is no universal set of definitions of test concepts", consequently 
the universe of testing has been defined as multidimensional. The most used facets of universe are 
listed below (see Table 4, page 21) in order to cover some part of the complexity of the testing. 
Table 4. The general facets of multidimensional testing 

Coding 
languages

Development 
models 

Development 
paradigms 

Incidents 

Maturity models 

Money 

People skills 

People types 

Process 
improvement 

Product 

Product 
paradigms 

Product risks 

Quality assurance 
activities 

Quality factors 

Quality goals 

Standards 

Testing obstacles 

Testing progress 

Test approaches 

Test basis 

Test effort 

Test levels 

Test processes 

Test process 
improvement 

Test project risks 

Test scopes 

Test techniques 

Test tools 

---

22

Incident 
handling 
architectures 

Resources 

Risk willingness 

Test objectives

Test policy 

Test types 

Time 
Prepared by author according to Source: 
(Hass, 2008)
 
These terms can be interpreted as dependent factors of all software testing process. Each of them 
affects software quality and style of testing. Some of them have been already discussed in previous 
subchapter, others - will be introduced later. Despite the multidimensional view of testing the main 
terms should be provided for further discussion of testing techniques. The classic definition is as 
follows: “Testing is the process of executing a program with intention of finding errors” (Myers, 
1979). Much more extended and formal term is suggested by “IEEE Standard Glossary of Software 
Engineering Terminology” (1990)
:
(1) The process of operating a system or component under specified conditions, observing or 
recording the results, and making an evaluation of some aspect of the system or component. (2) The 
process of analyzing a software item to detect the differences between existing and required conditions 
(that is, bugs) and to evaluate the features of the software items".
(Galin, 2004) proposed an alternative term consisting of previous ones: 
Software testing is a formal 
process carried out by a specialized testing team in which a software unit, several integrated software 
units or an entire software package are examined by running the programs on a computer. All the 
associated tests are performed according to approved test procedures on approved test cases. 
We will use the more formalized term by “IEEE Standard Glossary of Software Engineering 
Terminology,” 1990) in order to take a wider look on testing and focus on compliance of requirements 
or "differences between existing and required conditions" which is called a bug or defect. Hamlet 
(1995) examined the terms as well with the assumption that software quality is comprehended as the 
absence of defects. Some methods proved the theoretical possibility of "zero-defect" software with the 
binary ideal of "correct" /"not correct". Although, the correctness of software could be interpreted in 
different ways and theoretical calculations could not fit to practical usage. DeVolder et al. (2008) 
supports this idea adding the explanation: testing can never completely establish the correctness 
because whether a failure is thrown, the software does not do what the user expects (there is no 
correctness). Moreover, Hamlet (1995) argued against Myers (1979) on the argument "the best 
development process is to find failures" (Myers, 1979). Hamlet (1995) stated that failure-finding is a 
dangerous measure. As a result, he suggested to use a construct of two definitions for testing in order 
to define software quality clearly. The suggested term is inherited from Dahl, Dijkstra, & Hoare (1972) 
as "Testing can show the presence of errors, never their absence." and Myers (1979) "The purpose of 
testing is to find errors". Indeed, Graham et al. (2008) agrees that usually the main purpose of testing is 

---

23
to find defects. However, in spite of software quality as we defined before, we would rather 
recommend focusing on the objectives listed by (Hambling & Morgan, 2011): 

Finding mistakes made by the programmer while developing the software; 

Gaining confidence in and providing information about the level of quality; 

Prevention from defects; 

Compliance of business and user requirements; 

Ensuring that software meets the Business Requirement Specification (hereinafter BRS) and 
System Requirement Specifications (hereinafter SRS). 
Further, DeVolder et al. (2008) distinguishes software testing as a process with a purpose to measure 
the quality of developed software by quality factors. Classification of quality factors by McCall et al. 
(1977) have been introduced in the subchapter 1.1 (see Table 2, page ). The extended table with the 
requirements and their corresponding tests are presented further (see Annex 1, page 70). Some of 
quality factors are divided in sub factors with corresponding tests in order to get full coverage of the 
respective requirements. In fact, the list of provided tests describes generally, what types of tests 
should be prepared before testing. Such tests can be executed by different testing techniques or tools - 
this will be discussed in further chapter.
To get full coverage of tests and perform efficient testing, some regulations should be followed. 
For this purpose Graham et al. (2008) extracted the main principles of testing. They are as follows: 
1)