https://huddle.eurostarsoftwaretesting.com/software-testing-crisis-journey-roots-craft/

Software Testing Crisis? The Journey To The Roots Of Our Craft

소프트웨어 테스팅의 위기? 우리 기술의 근원으로의 여행

Posted by Nicola 2018/05/12

Reading Time: 9 minutes

Achieving the high software quality is, unfortunately, still hard to attain. One important reason is that IT industry loves tools, automatization and software solutions. We think that new technologies will immediately solve our problems - just because. Having no real, rational arguments for that, we believe that all this stuff is a silver bullet or some other software quality snake-oil. We love this illusion that high complexity of modern technologies immediately implies their high robustness and applicability. In all this madness of unceasing progress of technology we have somehow lost the ability to have a deeper reflection about the foundations of our craft. And also, the ability to transform this reflection into a working solution, which in many cases can be much more effective than just relying on a new tool or a sophisticated tchnology.

불행히도 높은 품질의 소프트웨어를 달성하는 것은 여전히 어렵다. 한 가지 중요한 이유는 IT 산업이 도구, 자동화 그리고 소프트웨어 솔루션을 사랑한다는 점이다. 그 때문에 우리는 신기술이 즉시 우리의 문제를 해결해 줄 것으로 생각한다. 그에 대한 현실적이고 이성적인 논쟁이 없다면 우리는 이 모든 것들을 은탄환 또는 또 다른 소프트웨어 품질의 가짜약으로 믿는다. 우리는 고도의 복잡도를 가진 현대적인 기술이 곧바로 자신들의 강건성과 적응력을 의미한다는 이런 환영을 사랑한다. 기술이 끊임없이 진보하는 이런 모든 광기에서 우리는 우리 기술의 근원에 대해 더 깊은 성찰을 가지는 능력을 웬일인지 상실했다. 또한 대부분의 경우 새로운 도구나 현대적인 기술에 단순히 의지하는 것보다 훨씬 더 효율적일 수 있는 이러한 성찰을 작업의 해결책으로 전환하는 능력 또한 마찬가지다.

Let us follow this apparently underestimated approach and return to the roots of the testing craft. Starting with the fundamental principle - a reflection on how software works - we will identify the software’s primary ‘components’ (hereinafter called software dimensions). These basic software elements will help us to build a software fault model showing the ways in which software may fail. The model will then guide testing, being a handy tool for providing good, effective and creative test ideas.

이제 이렇게 명백히 과소평가된 접근법과 테스팅 기술의 근원으로 되돌아가 보자. 먼저 소프트웨어가 어떻게 동작하는가에 대한 성찰을 의미하는 근원적인 원리로 시작한다. 우리는 소프트웨어의 주요 ‘컴포넌트’를 (이후로는 소프트웨어의 차원 요소로 부른다) 식별할 것이다. 이와 같은 기본적인 소프트웨어 요소는 우리가 소프트웨어가 실패할 수 있는 방식을 나타내는 소프트웨어 실패 모델을 (software fault model) 만드는데 도움을 줄 것이다. 이후 이 모델은 테스팅을 안내해서 훌륭하고 효과적이며 창의적인 테스트 아이디어를 제공하는 유용한 도구가 될 것이다.

BASIC SOFTWARE CHARACTERISTICS

기본적인 소프트웨어의 특성

When we ask someone ‘what does the software really do?’, probably the most frequent answer would be ‘it processes data’. This is perfectly fine: every program accepts some input data, transforms them and outputs other data. This process takes place in time: a program is not able to return the answer immediately – it needs to perform several steps. The actions that our program undertakes are a result of some events that either come from the inside of a software or are external, and come from the environment in which software operates. Data and events can be described quantitatively. For example, data value can be large or small, events can occur frequently or rarely and so on.

 

우리가 누군가에게 ‘실제로 소프트웨어가 하는 일은 무엇입니까?’라고 묻는다면 아마 가장 빈번한 대답은 ‘그것이 데이터를 처리하는 것입니다.’라는 답변일 것이다. 이것은 완전히 옳다. 즉 모든 프로그램은 약간의 입력 데이터를 받아들여 그것을 변환해 다른 데이터를 출력한다. 이 과정은 시간 순으로 일어난다. 즉 하나의 프로그램이 즉시로 답을 되돌려 보낼 수는 없다. 그것은 몇 개의 단계를 수행할 필요가 있다. 우리의 프로그램이 취하는 동작은 소프트웨어의 내부 또는 외부 그리고 소프트웨어가 동작하는 환경에서 오는 어떤 이벤트의 결과이다. 데이터와 이벤트는 정량적으로 묘사할 수 있다. 예를 들어 데이터의 값은 크거나 작을 수 있고 이벤트는 빈번하거나 드물거나 하는 식으로 일어난다.


We have just come up with four basic software ‘dimensions’: Data (D), Events (E), Time (T) and Quantity (Q). These concepts are very general – notice that any software and its actions can be reduced to, and expressed with only these four basic ideas. We may support this rather strong thesis in the following way: software and computation are part of the physical world. Everything what happens in this world can be described by using several basic properties, like: mass, thermodynamic temperature, time or amount of substance. Consider the following analogies between the physical world and a working software, illustrated in Fig. 1:

우리는 방금 네 가지 기본적인 소프트웨어의 ‘차원 요소’인 데이터 (D), 이벤트 (E), 시간 (T) 그리고 수량 (Q)을 떠올렸다. 이 개념은 아주 일반적이다. 즉 어떤 소프트웨어나 그것의 동작도 이러한 네 가지의 기본 아이디어만으로 추론하거나 표현할 수 있다. 우리는 다음의 방식으로 이 강력한 이론을 뒷받침할 수 있다. 즉 소프트웨어와 계산을 물리적인 세계의 일부로 보는 것이다. 이 세계에서 일어나는 모든 일은 다수의 기본적인 속성인 질량, 열역학적 온도, 시간 또는 물질의 양 같은 것으로 설명할 수 있다. 그림 1에 표현된 물리적인 세계와 작동하는 소프트웨어 사이의 관계에 대해 다음의 비유를 생각해 보자.

Figure 1. Relation between physical properties of the world and the software

그림 1. 세계를 이루는 물리적인 속성과 소프트웨어의 관계


amount of aches: 화산재의 양

eruption: 화산 폭발

lava: 용암

solidifying lava: 응고된 용암

value of a variable: 변수의 값

calling a function: 함수 호출

variable: 변수

sequence of instruction: 명령어의 순서


Our model uses these four entities as a foundation. All other, more complicated ideas and relations will be built on this base. Let us think about how these dimensions may be related to software regarding the testing process:

우리의 모델은 이러한 네 가지 엔티티를 기초로 사용한다. 다른 모든 더 복잡한 아이디어와 관계들은 이러한 기초 위에 세워질 것이다. 이제 어떻게 이러한 차원 요소가 테스팅 프로세스에 관련되어 소프트웨어와 연결될 수 있는지 생각해 보자.

As our model will be described in terms of these four dimensions, we have to explain why we have decided to define software in such a way. The fundamental idea behind our model is as follows: if we are able to describe any aspect of any software with these four characteristics, we can also do this for failures and bugs present in the code and documentation. Hence, theoretically, if we are able to describe the software detailed enough, we should be able to identify all the risks, problems, bugs, threats and possible failures.

우리의 모델을 이러한 네 가지 차원 요소의 관점으로 설명할 때 우리는 왜 우리가 이런 방식으로 소프트웨어를 정의해야 하는지를 설명해야 한다. 우리 모델 뒤에 존재하는 기본적인 아이디어는 다음과 같다. 만일 우리가 이러한 네 가지 특성으로 어떤 소프트웨어의 어느 측면을 묘사할 수 있다면 우리는 코드나 문서에 존재하는 실패나 버그에 대해서도 이것을 할 수 있다. 따라서 이론적으로 우리가 그 소프트웨어를 충분히 상세히 묘사할 수 있다면 우리는 모든 리스크, 모든 문제, 모든 버그, 위협 그리고 발생 가능한 실패를 확인할 수 있어야 한다.

TQED MODEL

TQED 모델

Having our four basic dimensions in place is not enough. Of course, there may be some error in a file (Data problem), some input string may be too large (Quantity problem), an unexpected exception may occur (Event problem) and so on. But software is more complicated. We need to build a new layer upon our four dimensions. For example, a failure may happen when we use a certain model of a printer together with a certain model of a web browser. Both printer and web browser can be considered as a Data dimension. But the failure results by a combination of these two entities. Hence, we should consider different combinations of dimensions. Together with the basic dimensions they constitute our final model, presented in Fig. 2.

우리의 네 가지 기본적인 차원 요소를 제 위치로 두는 것으로는 충분치 않다. 물론 파일에 (데이터 문제) 약간의 에러가 있을 수도 있고 몇몇 입력 문자가 너무 길 수도 있으며 (수량적인 문제) 예상치 못한 예외가 발생할 수도 (이벤트 문제) 있다. 하지만 소프트웨어는 더 복잡하다. 우리는 네 가지 차원 요소에 새로운 층위를 (layer) 세울 필요가 있다. 예를 들어 우리가 어떤 웹 브라우저 모델과 특정 모델의 프린터를 함께 사용할 때 어떤 실패가 발생할 수 있다. 프린터와 웹 브라우저 모두는 하나의 데이터 차원 요소로서 고려될 수 있다. 하지만 그것의 실패는 이러한 두 가지 엔티티의 조합으로 발생한다. 그러므로 우리는 차원 요소의 서로 다른 조합을 고려해야 한다. 그림 2에 나타내었듯이 그것이 기본적인 차원 요소와 함께 쓰일 때만 우리의 최종 모델을 형성한다.

Figure 2. TQED model with basic combinations of dimensions. (C) 2018 Springer International Publishing, reprinted with permission

그림 2. 기본적인 차원 요소의 조합을 가진 TQED 모델. 스프링거 국제 출판사 (c) 2018, 허락하에 전제.

The grey rectangles represent the basic dimensions and the white ones – combinations of two dimensions. The three dots in the upper left part of the model represent more complicated situations, for example a combination of Data, Quantity and Event.

회색 사각형은 기본적인 차원 요소를 나타내며 흰 것은 두 차원 요소의 조합을 나타낸다. 이 모델의 좌상단에 있는 세 개의 점은 더 복잡한 상황을 표현한다. 예를 들면 데이터, 수량 그리고 이벤트의 조합을 나타낸다.


 

Like in the case of basic dimensions, let us think now how the combinations of them may be related to a System Under Test. Note that this is just an example – such an analysis should be done for each SUT individually, as each application is different and operates in different environment. Hereinafter the combinations will be represented by the concatenated letters that represent particular dimensions, e.g. DQ means Data+Quantity.

이제 기본적인 차원 요소의 경우처럼 이것을 어떻게 조합해야 테스트 중인 시스템과 연관시킬 수 있을지 생각해 보자. 이것은 그냥 예시라는 점을 주의하라. 즉 이러한 분석은 각 테스트 중인 시스템에 개별적으로 이루어져야 한다. 왜냐하면 각 애플리케이션이 서로 다르고 각각 다른 환경에서 운영되기 때문이다. 이후로는 이 조합을 예를 들어 DQ가 데이터 + 수량을 의미하는 것처럼 특정 차원 요소를 나타내는 연결 기호로 표현할 것이다.

(참고: Soak 테스팅은 한참 동안 부하를 가해  메모리 누수나 자원 누수를 알아내는 성능 테스팅의 일종이다.)

The name ‘TQED’ is the acronym for the four basic dimensions: Time, Quantity, Event, Data. It may be also derived from the words: ‘Tested. Quod Erat Demonstrandum’ (‘Tested. What was to be demonstrated.’), but of course this interpretation should be treated facetiously.

‘TQED’라는 용어는 네 가지 기본 차원 요소인 시간, 수량, 이벤트, 데이터의 머릿글이다. 또한 이것은 ‘Tested. Quod Erat Demonstrandum’라는 (‘테스트 됨. 입증이 필요한 것’) 단어에서 뽑은 용어이다. 하지만 물론 이런 해석은 농담이다.

MODEL PROPERTIES

모델의 속성

The TQED model is conceptual. It provides us with some basic notions that can be mapped to some real entities in our test project. Analysis of these notions and their combinations allows us to perceive very concrete risk areas or defect-prone places in a SUT.

TQED 모델은 개념적이다. 이것은 우리의 테스트 프로젝트에서 실제 엔티티들과 연결할 수 있는 기본적인 개념을 우리에게 제공한다. 우리는 이 개념의 분석과 그 조합을 통해 테스트 중인 소프트웨어의 매우 구체적인 리스크 영역 또는 결함 가능성이 있는 곳을 인지할 수 있다.

 

The presented approach is also universal: the dimensions themselves are only abstractions, hence they may be used in any kind of test type on any level of abstraction. The method fits in with the unit testing of a single class as well as with the system testing of a piece of hardware. Also, the model can be applied to any kind of a SW/HW test project, as all components of any SUT can be expressed in terms of the four basic software testing dimensions.

또한 앞서 제시된 접근법은 보편적이다. 즉 차원 요소 그 자체는 그냥 추상적이다. 그러므로 어떤 추상 레벨의 어느 테스트 유형에도 쓰일 수 있을 것이다. 이 방법은 단일 클래스의 유닛 테스팅 뿐만 아니라 단일 하드웨어의 시스템 테스팅에도 들어 맞는다. 또한 이 모델은 어떤 종류의 SW/HW 테스트 프로젝트에도 적용될 수 있다. 왜냐하면 테스트 중인 시스템의 모든 컴포넌트를 네 가지 기본적인 소프트웨어 테스팅의 차원 요소로 표현할 수 있기 때문이다.

It may be advisable to perform the conceptual mapping for more than two dimensions. For example, one may consider combinations like DETQ or DDEQQT. Considering a specific number of combinations should reflect the optimal trade-off between the risk, quality of tests, time and model simplicity. Exploratory testers may use the model as well: it can serve as a practical tester’s roadmap when performing the exploratory testing session. It can also help the tester in inventing valuable ad-hoc tests and in organizing the session in a systematic way.

두 개 이상의 차원 요소에 대해 개념 연결을 시행하는 것이 좋을 것이다. 예를 들어 누군가는 DETQ 또는 DDEQQT와 같은 조합을 고려할 수도 있다. 특정 개수의 조합을 고려하는 것은 리스크, 테스트의 품질, 시간과 모델의 단순성 사이의 최적의 트레이드 오프를 반영해야 한다. 탐색적 테스터는 이 모델을 아주 잘 사용할 수 있다. 즉 이것은 탐색적 테스팅 세션을 수행할 때 테스터의 실용적인 로드맵으로서 기능할 수 있다. 또한 이것은 가치있는 애드훅 테스트를 개발하고 체계적인 방식으로 그 세션을 조직화하는 방식으로 테스터를 도와줄 수 있다.

The TQED model is:

TQED 모델은

Applying TQED in practice: a ticket machine

실제로 TQED를 적용하기: 발권 기계

We will now show how the TQED model can be applied in practice. Assume that we have to perform a system testing of a ticket machine. The only documentation we have is the machine itself and the instruction written on it (see Fig. 3). By pressing two upper buttons a user can change the number of normal and reduced tickets to buy. Pressing ‘Cancel’ zeroes the values. After pressing a ‘Buy’ button a user inserts the coins and/or banknotes to pay for the tickets. The machine gives change. After the payment the tickets are printed and passed over to the dispenser.

이제 우리는 TQED 모델이 실제에 어떻게 적용될 수 있는지 살펴볼 것이다. 우리가 발권 기계의 시스템 테스팅을 수행해야 한다고 가정하자. 우리가 가진 유일한 문서는 기계 그 자체이며 그것에 쓰인 명령들 뿐이다 (그림 3을 보라). 사용자가 상단의 두 개 버튼을 누르면 구매할 성인, 아동 입장권의 개수를 변경할 수 있다. ‘취소’ 버튼을 누르면 그 값이 0으로 바뀐다. 사용자는 ‘구매’ 버튼을 누른 후 입장권 구매를 위해 동전이나 지폐를 넣는다. 이 기계는 거스름 돈을 내어 준다. 결제가 되고 나면 입장권이 인쇄되어 토출구로 나온다.

 

Let us apply the TQED approach for this SUT. We will not perform the full analysis, as it would take too much space. Instead, to show how one can benefit from the model, we will focus on some nontrivial test cases that can be derived using the TQED approach.

이 테스트 중인 시스템에 TQED 접근법을 적용해 보자. 우리는 완전한 분석을 하지 않을 것이다. 왜냐하면 이것이 너무나 많은 공간을 차지할 것으로 생각되기 때문이다. 대신 누군가가 이 모델에서 어떻게 이익을 볼 수 있는지 설명하기 위해 TQED 접근법을 사용해서 도출될 수 있는 중요한 테스트 케이스에 집중할 것이다.

Figure 3. A ticket machine. (C) 2018 Springer International Publishing, reprinted with permission

그림 3. 발권 기계. 스프링거 국제 출판사 (c) 2018, 허락하에 전제.

First, let us identify some real entities related to the basic dimensions. This is shown in Fig. 4.

먼저 기본적인 차원 요소와 관련된 실제 엔티티를 확인해 보자. 이것을 그림 4로 나타내었다.

Figure 4. Real entities for a ticket machine mapped to the basic software dimensions.

차원 요소

이 차원 요소와 연결되는 실제 엔티티

D

구매할 성인/아동 입장권, 기계에 존재하는 입장권 카드, 기계 내에 존재하는 서로 다른 동전/지폐의 교환 액수, 서로 다른 액면을 가진 투입된 동전/지폐, 전체 금액 즉 유효하고 무효한 동전/지폐

E

버튼을 누름. 잔돈을 거슬러 줌. 동전/지폐 투입.

T

동작 사이의 긴/짧은/일반적인 시간 간격

Q

낮거나 높은 값. 열린 경계 또는 닫힌 경계.  최대 가능값, 최소 가능값

그림 4. 기본적인 소프트웨어 차원 요소와 연견된 발권 기계를 위한 실제 엔티티


Now, let us provide some examples of the non-trivial test cases by analyzing several compositions of dimensions. The process of creating the test ideas is presented in Fig. 5: a tester takes one or more objects from different dimensions and thinks about how they can be combined together to produce a valuable test idea.

이제 몇 가지 차원 요소의 조합을 분석함으로써 중요한 테스트 케이스의 예를 제공해 보자. 테스트 아이디어를 생성하는 프로세스는 그림 5에 나타내었다. 테스터는 서로 다른 차원 요소에서 하나 이상의 객체를 취해 가치있는 테스트 아이디어를 생성하기 위해 어떻게하면 그것을 묶을 수 있는지에 대해 생각한다.

Figure 5. Schematic process of deriving the test ideas using the TQED model.

그림 5. TQED 모델을 사용해 테스트 아이디어를 도출하는 체계화된 프로세스

In Fig. 6 we show some more nontrivial examples. The first column shows the abstract combinations of dimensions. The second one describes the mapping to the real entities of a SUT. The last one contains the test ideas related to the given combinations of dimensions.

우리는 그림 6에서 몇 가지 보다 중요한 예제를 보여준다. 첫 번째 열은 차원 요소의 추상적인 조합을 나타낸다. 두 번째 열은 테스트 중인 시스템의 실제 엔티티와의 연결을 묘사한다. 마지막 열은 주어진 차원 요소의 조합과 관련된 테스트 아이디어가 들어있다.

Figure 6. Using the TQED model to derive some more nontrivial test ideas.

조합

실제 엔티티와 연결

테스트 아이디어

D

액면가

모든 유형의 동전과 지폐를 사용. 무효한 액면가와 북미 지역 화폐가 아닌 지폐도 사용.

EEE

동전 투입 + 전원 끄기 + 전원 켜기

동전 투입, 전원 크기, 전원 켜기에서 기계의 전원 끄기 전 투입된 돈을 기억하거나 동전을 반환할까?

ET

동전 투입 + 느린 시간

동전 투입 후 오랜 시간 대기. 기계가 일정 시간 이후 당신의 돈을 반환할까? 또는 다음 동작을 수행하기 위해 사용자를 기다리고 있을까?

EET

입장권 출력 + “취소” 버튼 누름 + 이벤트 사이의 짧은 시간

‘OK’ 버튼을 누르면 기계가 입장권을 인쇄한다. 즉시 ‘취소’ 버튼을 누른다. 기계가 그 동작을 취소하고 돈을 반환할까? 아니면 후자의 동작을 무시할까?

DEQ

가격 + 지폐 투입 + 이하의 값 [7.60달러, 38달러]

7.60 달러 미만의 입장권을 선택했지만 사용법에 따라 10불의 지폐로 결제하려고 시도. 기계가 그것을 허용할까? 또는 거부할까?

EET

‘성인 입장권’ 버튼 + ‘아동 입장권’ 버튼 + 동시에

두 개 버튼을 동시에 누름. 기계가 일반과 아동 입장권 모두의 숫자를 1 증가시킬까? 한 종류만 1증가시킬까? 아니면 아무것도 하지 않을까?

EQTQ

‘성인 입장권’ 버튼 + ‘성인 입장권’ 버튼 + 빠른 시간 + 큰 값

빠르게 (TQ) ‘성인 입장권’을 10번 (EQ) 누름. 기계가 이 모든 이벤트들을 올바르게 처리할까? 그리고 성인 입장권을 10개 증가시킬까? 아니면 더 적은 숫자만 증가시킬까?

EETT

‘성인 입장권’ 버튼 + ‘아동 입장권’ 버튼 + 긴 시간 + 일반적인 시간

‘성인 입장권’ 버튼 누름. 누른 채로 ‘아동 입장권’ 버튼 누름. 양쪽 이벤트가 올바르게 처리되나? 그것 중 단 하나만 처리되나? 아니면 아무것도 처리되지 않나?

DDQQ

성인 입장권의 수 + 기계 안에 준비된 입장 카드의 수 + 거대한 수량 + 작은 수량

기계 안에 준비된 입장권 카드의 수 보다 많은 입장권을 사려고 선택. 기계가 당신의 주문을 허용할까? 돈을 반환하거나 가능한 많은 입장권만 인쇄할까? 인쇄되지 않은 입장권에 대한 잔돈을 반환할까?

DDQQET

전체 가격 + 기계 안에 있는 5센트 동전의 수 + 가격에 대한 경계값 + 기계 안에 있는 5센트 동전의 수에 대한 경계값 + 동전 투입 + 구체적인 이벤트의 순서

기계 안에 5센트 동전이 없는 (DQ) 테스트 환경을 준비. 1.9달러짜리 아동 입장권 (DQ) 1개 주문. 그리고 10센트, 20센트, 20센트, 20센트, 25센트, 1달러의 순서대로 동전과 지폐를 (E) 투입. 이 기계가 어떻게 반응할까? 입장권을 출력할까? 거스름 돈을 반환할까? 반환하지 않을까?

그림 6. 중요한 테스트 아이디어를 도출하는데 TQED 모델을 사용하기

Theoretically, one can analyze all the combinations for all the mapped entities up to a given number of basic dimensions and therefore derive in a simple, almost mechanical way, quite strong and nontrivial test ideas – which, in my opinion, is the most important task for a tester. The number and types of combinations and tests is of course a matter of many factors, like risk analysis, available resources, test strategy and so on.

이론적으로 누군가는 주어진 기본적인 차원 요소에 연결된 모든 엔티티의 모든 조합을 분석할 수 있다. 그러므로 간단하면서도 기계적인 방식으로 매우 강력하고 중요한 테스트 아이디어들을 도출할 수 있다. 내 생각에는 이것이 테스터에게 가장 중요한 과업이다. 물론 조합과 테스트의 숫자와 유형은 리스크 분석, 가용 리소스, 테스트 전략 등의 많은 다른 요소에 달려있다.

CONCLUSIONS

It must be remembered, though, that the TQED model is just a proposition of an organized test approach. It is by all means no silver bullet for testing. It supports the tester in a testing process, imposes an organized, engineering approach, but does not excuse a tester from thinking. Software decomposition, choosing the right level of abstraction, prioritizing the tests according to the risk analysis and mapping the dimensions and their combinations to the real entities – all of them are the creative parts and cannot be automated.

결론

TQED는 그냥 조직화된 테스트 접근법의 제안으로 기억해야 한다. 어떤 경우에 있어서도 이것이 테스팅의 은 탄환이 아니다. 이것은 테스팅 프로세스에 있어 테스터를 지원하며 조직화와 공학적인 접근을 제공한다. 하지만 테스터가 생각을 하지 않는 것에 대한 변명이 되진 않는다. 소프트웨어 분해는 올바른 추상화 수준을 선택하고 리스크 분석에 맞게 테스트의 우선 순위를 정하고 차원 요소와 그 조합을 실제 엔티티와 연결하는 것이다. 그것 모두는 창조적인 영역이며 자동화 할 수 없다.

 

More examples and details about the TQED model and – in general – about why thinking is the most important thing in software testing, can be found in my book ‘Thinking-Driven Testing. The Most Reasonable Approach to Quality Control’.

Link: https://www.springer.com/gp/book/9783319731940

Summary of the article

In this article I present a simple and universal model, founded on the natural software  testing characteristics, that may help the testers to construct the effective tests by a careful analysis of how system under test (SUT) works and how it can fail. The method may be really useful if there is no formal documentation and the only thing a tester has is a common sense (which is very often the case). A practical example of its application is presented.

Author Bio & photo

Adam Roman, Ph.D., is a professor of computer science at the Jagiellonian University in Cracow (Poland). His research interests include: effective test design techniques, software quality models, mutation testing and application of AI & data mining techniques in software quality engineering. He is an author of two monographs on software testing: ‘Thinking-Driven Testing. The Most Reasonable Approach to Quality Control’ (in English) and ‘Software testing and quality. Methods, techniques and tools’ (in Polish). A proponent of rational acting based on logical and system thinking.