우리는 왜 소프트웨어 테스트가 필요한 걸까?

 소프트웨어의 역사와 함께 이미 1960년대부터 테스트는 화두가 되어왔습니다.

 수십 년이 지난 지금도 테스트는 수많은 개발자들에게 여전히 관심을 받고 있습니다. 이유가 무엇일까요? 대체 소프트웨어 테스트란 무엇이고, 우리에게 왜 필요한 것인지 한번 알아보도록 하겠습니다.

1. 버그(Bug)란 무엇인가?

 우리는 PC나 스마트폰과 같은 기기를 통해 게임, 모바일 어플리케이션, 웹 서비스 등 각종 소프트웨어를 이용하는 과정에서 비정상적인 현상이 발생하거나 기기가 오작동하는 경우를 심심치 않게 만나볼 수 있습니다. 또 개발자라면 이러한 현상의 원인을 파악하고 없애기 위해 늘 고군분투하고 있을 거라 생각합니다. 여기서 말한 비정상적인 현상, 기기의 오작동이란 무엇일까요? 바로 버그입니다. 소프트웨어가 예상한 동작을 하지 않고 잘못된 결과를 내거나 혹은 오류를 발생시키거나, 작동이 실패하는 등 이렇게 개발 요구 사항 설계와 맞지 않게 동작하는 것을 모두 버그(결함)이라고 합니다. 

단 한번에 코딩이 완성되는 프로그램은 없다.

버그가 없는 프로그램은 존재하지 않는다.

버그가 없으면 그게 바로 버그다.

 위와 같은 말이 있을 정도로 프로그래밍에서는 버그가 항상 따라옵니다. 발견된 버그가 어디서 발생하는지 또 그것을 제거하는 일, 그것을 바로 디버깅(Debugging)이라 합니다.

 일반적으로 디버깅에는 브레이킹 포인트와 디버그모드를 이용한 코드 상의 체크, 특정 변수에 대해 조사하기 위해 해당 변수의 주소값을 취해 주소의 메모리를 조사하는 메모리 디버깅, 원격지에서 디버깅하는 원격 디버깅, 메모리 상태를 확인하는 메모리 덤프, 오류 정보에 대한 기록을 확인하는 로그 방식 등이 있습니다.

[토마스 에디슨, 1878년]

“나의 모든 발명의 과정이 그러했다. 첫 번째 단계는 직관이고, 곧 많은 진전이 이루어진다.

그 다음에는 어려움이 나타나고, 이들이 해결될 때 즈음에서 ‘버그’가 나타난다.

이를 해결하기 위해서는 몇 달간의 관찰과 학습, 노동이 필요하다. 이 ‘버그’가 잡힌 후에야
상업적인 성공과 실패를 확실히 판가름 난다.”

2. 디버깅과는 또 다른 테스팅

 문제가 없음을 밝히는 과정인 디버깅과는 다르게 문제가 있음을 밝히는 과정이 바로 테스팅입니다. 즉, 소프트웨어 테스트란 소프트웨어 품질 보증 활동 중 하나로 소프트웨어에 대한 요구사항의 만족도 및 예상과 실제 결과의 차이점 등을 여러 방법을 사용하여 검사하고 평가하는 일련의 과정을 의미합니다. 테스트 목적에는 다양한 이유가 있을 수 있으나 일반적으로는 다음과 같습니다. 

• 개발 프로세스 점검 및 이슈 제거
• 시스템과 소프트웨어가 명세를 충족하는지 확인
• 논리적 설계 구현의 검증
• 비즈니스 리스크를 감소시키는 근거 제공
• 품질 수준에 대한 자신감 획득과 정보 제공

 이러한 테스트가 제대로 이루어지지 않고 서비스나 제품이 출시된다면 예상치 못한 문제를 야기할 수 있습니다. 이로 인한 피해는 금전적인 손실, 시간 낭비, 비즈니스 이미지 손상 심지어는 부상이나 사망에 이르기까지 정말 다양하며 그 정도도 심각합니다.

3. 테스트, 정말 중요할까요?

 테스트는 개발 과정에서 간과해서는 안 되는 것으로 보입니다. 하지만 안타깝게도 오늘날 개발자들은 점점 더 테스트를 기피하고 있습니다. 이들이 직면한 가장 큰 문제는 소비자는 좀 더 많은 기능이 빠르게 그리고 값싸게 출시되길 원한다는 점입니다. 동시에 소프트웨어 품질은 기대에 벗어나지 않길 바라고 있습니다. 이 때문에 개발자들이 소프트웨어 테스트에 시간과 관심을 크게 두지 못하는 것이 현실입니다. 여전히 테스트 비용보다는 소프트웨어 개발 비용에 더 관심이 많으며, 테스트의 효과보다는 개발 생산성을 향상시키는 기술에 더 열광하기도 합니다. 그런데 아이러니하게도 테스트에 걸리는 시간과 비용이 많아질수록 전체 개발에 투입되는 시간과 비용이 줄어듭니다.

개발  == 건축

 소프트웨어 개발은 마치 건축과도 같습니다. 한층 한층 지어갈 때마다 지어진 곳에 문제는 없는지, 부실하진 않은지 등을 항상 검사해야만 합니다. 이를 하지 않으면 당장은 건물을 빨리 지어 내보일 순 있지만, 언제 무너질지 모르는 폭탄을 짓는 것과 같습니다. 만약 무너진다면 막대한 피해와 함께 처음부터 건물을 다시 지어야 합니다. 따라서 피해액과 함께 건축 비용도 두배로 들게 됩니다. 소프트웨어도 마찬가지입니다. 테스트를 거치면서 견고하게 개발하지 않으면 언제 소프트웨어에 장애가 발생할지 모릅니다. 코드를 보고 머릿속으로 시뮬레이션을 하거나, ‘돌아가겠지’하며 무책임하게 개발해서는 안됩니다.

다음 포스팅에서는 테스트 종류와 그 중 특히 단위테스트에 대해 구체적으로 이야기하겠습니다.

-출처-

소프트웨어 테스트 자동화 구축과 6가지 핵심 활동(시간과 비용을 줄이고 품질은 높이는)

https://book.naver.com/bookdb/book_detail.nhn?bid=9068077 (네이버 책 검색 결과)