The Art of Software Testing 책을 통하여

Testing에 대해 공부해보았다.

Software Testing?

Software Testing에 대해서 이렇게 생각하는 사람들이 있다.

  • 오류가 존재하지 않는 것을 입증하는 프로세스
  • 프로그램이 의도한 기능을 정확히 수행하는지 보여주는 것
  • 프로그램이 의도한대로 작업하는지에 대한 신뢰를 확립하는 과정

그러나 Software Testing은

  • 의도하지 않은 것은 의도하지 않은대로 동작하지 않음
  • 의도한 것은 의도한대로 동작

하는 것을 확인하기 위한 일련의 프로세스다.

즉, 프로그램에 가치를 더하는 것을 말한다.

무슨 말이냐 하면, Software Testing을 통해 프로그램의 품질이나 안정성을 높이는 것을 말한다.

안정성을 높인다는 것은 무슨 말일까?

오류를 찾고 수정하는 것을 의미한다.

그래서 Software Testing을 할 때에는 프로그램에 오류가 있다고 가정을 하고 그 오류들을 찾기 위해서 한다.

결국 Software Testing은

오류를 찾기 위해 프로그램을 실행하는 과정

우리가 일반적으로 프로그래밍을 하여 새로운 무언가를 만들어내는 건설적인 프로세스인 반면, Software Testing은 파괴적인 프로세스다.

이것은 프로그래밍을 하며 무엇을 만들면서 심리적으로 긍정적인 결과가 나오기를 기대하게 되고, 그에 반대하는 결과가 나오기를 꺼려하는 심리와 연관이 있기 때문이다.

앞서 말했듯이 Software Testing은 오류를 찾기 위해 프로그램을 실행하는 과정이다.

그렇기 때문에 우리는 Software Testing을 하다보면 필연적으로 이런 심리적인 요소를 맞딱뜨릴 수 밖에 없다.

이해를 돕기 위해 예를 들자면, 이런 Software Testing은 마치 우리가 병원의 의사를 찾아가는 행위와 같다.

우리는 우리의 몸에 이상이 있을 때 혹은 이상이 있다고 느낄 때 불안감으로 인해 병원을 방문해 의사에게 검사를 받게 된다.

그런데 우리는 분명히 몸에 이상이 있는 거 같은데 의사는 아무 이상이 없다고 한다.

그럼 이 때 우리는 어떻게 생각하는가? 만약 이 불안감이 해소가 되지 않는다면 우리는 다른 병원을 찾아가 다른 의사에게 또 비용을 들여서 검사를 받는다.

이것을 Software Testing에 비유할 수 있다.

분명 오류가 있을텐데 오류가 나오지 않는다, 이것은 좋은 상황인가?

잠재된 오류가 있을 것이며 이 Software를, 이 프로그램을 릴리즈 하기 전에 오류를 최대한 찾아서 프로그램의 품질과 안정성을 높여야 한다.

릴리즈 이후에 오류를 찾아서 고치는 일은 릴리즈 이전에 오류를 찾아 고치는 일보다 훨씬 큰 비용이 들기 때문이다.

그렇다고 해서 무한정으로 모든 무한의 케이스에 대해서도 Software Testing을 할 수는 없다.

일종의 ‘가성비’를 고려하여 적절한 선에서 진행하여야 한다.

Black-box test, White-box test

Black-box test

단어 그대로 내부 동작과 구조보다는 입력에 대한 출력 기대값에 대하여 Testing하는 것을 말한다.

그래서 이 때 테스트 데이터는 전적으로 기대 결과에 기반하여 만들어지게 된다.

그러나 이런 입력값은 그 종류가 매우 많아 모두 테스트하기에는 불가능하다.

더욱이 어떤 트랜잭션에 의존적이라면, 그 트랜잭션과 관련된 모든 상황에 대해서도 Testing이 필요하기 때문이다.

그래서 위에서 말했듯이 ‘가성비’를 생각하여 한정된 케이스로 최대한의 효율을 뽑아야 한다.

White-box test

Black-box test와는 반대로 내부로직과 구조를 Testing하는 것이다.

위의 Black-box test와 유사한 방법으로 Testing을 하며, 내부 로직과 구조를 테스트하는만큼 이 또한 경우의 수가 매우 많다.

그래서 테스트 데이터는 내부 로직에 의존하여 테스트 데이터를 만들어낸다.

만약 아래와 같은 로직이 내부 로직의 어느 지점에 있을 때, 어떻게 Testing을 할 것인가?

1
2
if (a - b > c) System.out.println("a - b > c");
else ...

위 케이스와 같이 데이터 민감성 오류가 발생할 수 있을 것이고, 이것은 내부 로직이 어떻게 흘러가는지 경로를 확인하는 것에서는 발견하기 어렵다.

만약 내부 로직이 복잡하여 분기가 많다면 로직이 어떻게 흘러가는지 경로의 그 수가 매우 많을 것이다.

그러므로 Black-box test와 White-box test를 적절히 섞어 Test Case를 선정한뒤 Testing하는 것이 중요하다.

10개의 원칙

그래서 The art of software testing에서는 10개의 Software Testing 원칙을 제안한다.

  1. 테스트 케이스에는 예상 출력이나 결과에 대한 정의가 필요하다.
  2. 프로그래머는 자신의 프로그램을 테스트 X
  3. 프로그래밍 조직은 자신들의 프로그램을 테스트 X
  4. 모든 테스트 과정에서는 각 테스트 결과에 대한 검사가 필요
  5. 테스트 케이스는 유효하고 예상 가능한 입력 조건에 대해 작성할 뿐만 아니라 예상치 못한 조건에 대해서도 작성하여야 함
  6. 프로그램이 해야 할 일을 수행하는 지 확인하는 것은 전체의 절반을 확인하는 것이고, 하지 말아야 할 것을 하지 않는 지도 확인해야 함
  7. 폐기시킬 프로그램이 아니라면 폐기할 테스트 케이스를 사용해서는 안됨
  8. 아무런 오류가 발견되지 않을 것이라는 가정하에 테스트를 계획하면 안됨
  9. 프로그램의 섹션에서의 오류 존재 가능성은 그 부분에서 발견된 오류 수에 비례
  10. 테스트는 매우 창조적이고 지적인 업무

포스트에 대한 피드백이 있으시다면 여기로 메일 부탁드립니다. 읽어주셔서 감사합니다.