테스터는 Testing만 하면 하고, 개발자는 Debugging만 하면 되는거 아닌가요?

질문

테스터는 Testing만 하면 하고, 개발자는 Debugging만 하면 되는 거 아닌가요?

테스터가 Debugging도 해야 하는 건가요?

ISTQB 버전

ISTQB Syllabus 2018

답변

Bug와의 전쟁

발명왕 에디슨이 1873년 자신이 발명한 기계를 설명하면서 처음 사용했다고 알려진 "bug"라는 단어는 소프트웨어 영역에서 조금씩 다르게 정리하고 있지만 wikipedia에 따르면, 오작동, 잘못된 결과, 오류의 발생 등을 의미합니다. 그래서 흔히들 "버그를 찾아야 한다, 버그 때문에 큰 문제가 발생했다"라고 표현하곤 합니다. (※ 참고 : 첫 번 째 컴퓨터 버그는 1947년에 발견됩니다.)

이 버그와의 전쟁속에서 오늘도 많은 테스터들은 다양한 종류의 소프트웨어를 실행시켜 "bug"를 찾으려 testing 이란 강력한 무기를 사용하고 있고, 개발자들은 오늘도 끊임없이 보고되는 "bug"일지 모를 이슈를 debugging이란 강력한 무기를 사용하여 해결하려고 노력하고 있습니다. 하지만 때로 서로 각자의 무기만을 사용하다 보면 의도하지 않은 오해나 대립이 발생하기도 합니다.

이런 오해가 심해지다 보면 bug와의 전쟁이 아닌 테스터 vs 개발자 간의 전쟁이 일어나는 양상이 발생합니다. 테스터와 개발자 모두 제품을 잘 만들기 위해 모인 사람들인데 쓸데없는 오해로 서로 적대적인 관계를 유지하는 것은 바람직하지 않습니다.

Testing vs Debugging

⌨︎ debugging에 대한 역사와 설명은 “테스팅은 디버깅과 근본적으로 구분되는 개념이다.”를 참고하시면 됩니다.

먼저 ISTQB Glossary에서 설명되어 있는 testing과 debugging의 용어 설명을 한 번 봅시다. (※ 아래의 영문 용어 설명은 ISTQB Glossary에서 그대로 인용한 것임을 밝힙니다.)

Testing : The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of a component or system and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.
Debugging : The process of finding, analyzing and removing the causes of failures in a component or system.

다음은 또 다른 참고 사이트인 "Geeks for Geeks에 게재되어 있는 Testing과 Debugging의 차이"라는 글에 정의된 용어 설명입니다. (※ 아래의 영문 용어 설명은 Geeks for Geeks에서 그대로 인용한 것임을 밝힙니다.)

Testing : Testing is the process to find bugs and errors.
Debugging : Debugging is the process to correct the bugs found during testing.

즉, 쉽게 말해 Testing은 "defect 이나 bug 같은 문제점을 찾아내는 과정"이고, Debugging은 "발견한 문제점의 원인을 찾고, 분석해서 없애는 과정"이라 할 수 있습니다.

다양한 제품/서비스(모바일앱, 게임, 웹서비스 등)를 실행해 보면서 문제 사항들을 찾아내는 일이 가장 많이들 하는 testing이라 할 수 있습니다. 테스트는 일반적으로 시스템의 전체적인 관점, 요구사항 대비 결과물을 확인하면서 문제점을 찾아냅니다. 테스트를 통해 찾아내는 문제점들은 거의 컴포넌트(Component) 단위에서 상태-전이(State transition) 관점이나 흐름-제어(Control flow) 관점에서 문제점을 찾게 됩니다. 세부적인 모듈 단위의 문제점을 찾기는 어렵습니다.

디버깅은 디버깅 도구에서 단계별로 코드를 실행하여 프로그래밍 실수를 만든 정확한 지점을 찾는 것을 의미합니다. 그러나 디버깅만으로 마술처럼 코드의 모든 문제/버그를 찾아내거나 표시할 수는 없습니다. 테스트와 다르게 디버깅은 세부적인 모듈 단위의 문제점을 찾기에는 적합하나, 소프트웨어의 소스 코드만 보고 상태-전이(State Transition) 혹은 흐름-제어(Control Flow) 관점에서 문제를 찾기는 어렵기 때문입니다.

또한 테스팅 결과를 정확하고 상세하게 알려주는 것이 디버깅을 하는데 필요한 시간을 단축 가능하게 해줍니다.

Testing과 Debugging의 상호 작용

우리는 소프트웨어 개발 업무를 수행하는 과정에서 테스터들이 testing을 통해 발견한 문제점을 개발자들이 원인을 찾아 코드를 수정하는 debugging을 통해 해결하고, 다시 testing을 통해 문제점이 일어나지 않는지 확인하는 과정을 반복합니다.

예를 들어, 모바일앱을 개발하는 중 회원 가입 후 로그인이 되지 않는 이슈를 테스터가 등록하였다고 해 봅시다.

개발자는 해당 이슈를 할당받아 문제점을 파악하고 잘못된 부분이 어느 부분인지 찾아 코드를 수정하고 나서 다시 테스터에게 보완이 되었다고 전달합니다.
테스터는 전달받은 앱으로 문제점이 수정되었는지 재 테스트를 하게 됩니다. 테스트 결과 정상 동작한다는 것이 확인되면 이슈는 종료가 되겠지만, 문제점이 여전히 발생되거나 그래도 안되는 부분이 있다면 개발자에게 해당 내용을 다시 전달하게 될 것입니다.

이런 과정을 통해 소프트웨어 제품과 서비스에 내재되어 있는 문제점들을 수정하고 사용자들의 불편사항들을 보완함으로써 소프트웨어의 품질이 높아질 수 있습니다.

결론 : Testing을 누가 하던, Debugging을 누가 하던 상관 없습니다. 잘 하는 사람이 하면 됩니다. 중요한 점은 그 활동들이 무엇인 지에 대한 이해입니다. 오늘도 평화로운 소프트웨어 개발을 진행하시길, 여러분들의 안녕과 평화를 필자들 모두 진심으로 바랍니다.

이와 관련한 자세한 설명과 예제는 필자의 블로그에 게재할 예정입니다. 주관적 관점이 들어간 예제라 본 글과 분리하였으니, 아래에 있는 「STEEG 개인 의견」 란에서 필자의 블로그에 와서 추가 내용들을 나중에 확인해 주세요.

참여자 정보

• 글쓴이 : Bykj, 천년나무

• 검토한이 : 품생품사. Byungjoo

STEEG 개인 의견

※ STEEG 개인 의견은 각 전문가 개인이 경험한 경력에 따른 의견이므로, 주관적 견해가 개제될 수 있습니다.
개인 의견에 대한 내용은 본 블로그와 관련이 없습니다.

향후 관련 예제에 대한 내용을 업데이트 할 예정입니다.

[팀블로그] 소프트웨어 테스팅 참고서