오랜만에 제 블로그의 '효자' 카테고리인 CSTS에 대한 글을 씁니다.
정말 오랫동안 관리를 못 했는데도 꾸준히 찾아주시는 분들을 보며,
여전히 많은 분들이 SW 테스트 분야에 대한 많은 관심을 가지고 계시다는 것을 느꼈습니다.
그래서 TTA 공식 예제와 최근 시험의 흐름을 다시 한번 짚어보게 되었습니다.
오늘은 단순히 문제를 풀고 답을 맞히는 것을 넘어,
출제자의 시선에서 "이 시험이 정말로 우리에게 무엇을 묻고 있는가?"를 생각해보고,
5가지 핵심 개념을 저만의 기준으로 분석해보고자 합니다.
합격을 가르는 5가지 핵심 개념
1. 개념의 경계: '용어'는 이해다.
가장 기본이지만, 가장 많이 틀리는 부분입니다.
이 시험은 '비슷해 보이는' 용어들의 미묘한 차이를 정확히 아는지를 묻습니다.
대표적인 예가 바로 '에러-결함-실패'의 관계입니다.
단순히 암기하는 것보다 이해를 통해 용어를 명확히 구분해야 합니다.
기출 예제 1번. 에러(Error)의 정의로 올바른 것은 무엇인가?
① 결함의 원인으로 사람에 의하여 생성된 실수를 말한다.
② 결함(Fault), 버그(Bug)와 동일한 의미이다.
③ 프로그램의 실행 결과와 올바른 결과의 차이를 말한다.
④ 제품에 포함된 결함을 의미한다.
정답은 ①번입니다. 하지만 이 문제를 단순히 '에러=실수'라고 암기하면,
조금만 변형되어도 흔들리게 됩니다.
이 세 가지 용어는 하나의 인과관계로 엮인 이야기와 같습니다.
가령,
- 에러 (Error): 개발자가 밤을 새우다 피곤해서, 혹은 요구사항을 잘못 이해해서 저지른 '사람의 실수'입니다. 예를 들어, '10 이상'을 코딩해야 하는데 < 기호를 써서 '10 초과'로 코딩한 바로 그 행위입니다.
- 결함 (Defect/Fault/Bug): 그 '실수'로 인해 코드에 남게 된 '문제적 코드 라인' 그 자체입니다. 위 예시에서 < 기호가 포함된 코드 라인이 바로 결함입니다.
- 실패 (Failure): 이 '결함'이 포함된 프로그램이 실행될 때, 사용자가 목격하게 되는 '오작동 현상'입니다. 사용자가 숫자 10을 입력했는데, '10 이상'이어야 할 조건이 만족되지 않아 다음 단계로 넘어가지 못하는 현상이 바로 실패입니다.
따라서 ②번은 결함과 동일하다 했으니 틀렸고, ③번은 '실패'의 정의이며, ④번은 '결함'의 정의입니다.
이 인과관계를 이해하면, 답을 찾을 수 있습니다.
2. 테스트 프로세스: '순서'와 '흐름'을 이야기로 엮어라
테스트 활동을 개별적인 점이 아닌, 하나의 유기적인 '선'으로 이해하고 있는지를 중요하게 봅니다.
각 단계의 '역할'과 그 결과물인 '산출물'을 짝짓는 문제가 단골로 출제됩니다.
기출 예제 14번. 다음 테스트 문서 중에서 작성 시점이 다른 것은 무엇인가?
① 테스트 절차서
② 테스트 로그
③ 테스트 사건 보고서
④ 테스트 요약 보고서
정답은 ①번입니다. 이 문제를 풀기 위해선, 머릿속에 테스트 프로젝트의 타임라인을 그려보면 좋급니다.
- Phase 1: 실행 이전 (계획 및 설계 단계)
- 무엇을, 어떻게, 언제 테스트할지 계획하고 설계하는 단계입니다.
- 여기서 우리는 테스트를 수행하기 위한 '설계도'와 '매뉴얼'을 만듭니다.
- '테스트 절차서'는 테스트 케이스를 어떤 순서로 실행할지에 대한 상세한 매뉴얼이므로, 당연히 실행 전에 작성됩니다.
- Phase 2: 실행 중 (실행 단계)
- 작성된 매뉴얼에 따라 실제로 프로그램을 실행해보는 단계입니다.
- '테스트 로그'는 테스트 수행 과정을 시간대별로 기록하는 '일지'입니다. 당연히 실행 중에 작성됩니다.
- '테스트 사건 보고서'는 테스트 중 예상치 못한 문제, 즉 '결함'을 발견했을 때 작성하는 '버그 리포트'입니다. 역시 실행 중에 작성됩니다.
- Phase 3: 실행 이후 (종료 및 보고 단계)
- 모든 테스트가 끝난 후, 전체 과정을 평가하고 요약하는 단계입니다.
- '테스트 요약 보고서'는 테스트의 최종 결과를 정리하여 이해관계자에게 보고하는 '결과 보고서'입니다.
- 실행이 모두 끝난 후에 작성됩니다.
이렇게 각 문서의 '목적'을 생각하면, ①번만이 유일하게 '실행 전'에 작성되는 문서임을 자연스럽게 알 수 있습니다.
3. 명세 기반 vs 구조 기반: '무엇'을 볼 것인가, '어떻게' 볼 것인가
소프트웨어 테스트의 가장 근본적인 두 가지 관점입니다.
'명세 기반(블랙박스)'은 내부 코드를 보지 않고 요구사항 명세서만 보고 기능이 잘 동작하는지를 확인하는 것이고,
'구조 기반(화이트박스)'은 코드의 내부 논리 구조를 들여다보며 모든 길이 제대로 테스트되었는지를 확인하는 것입니다.
기출 예제 35번. 한 테스트 집합이 90%의 분기 커버리지를 달성하였다는 사실이 의미하는 것은 무엇인가?
① 프로그램의 10개 문장이 있다면 테스트 집합에 의해 그중 9개가 실행되었다는 의미이다.
② 프로그램의 10개 분기가 있다면 테스트 집합에 의해 그중 9개가 실행되었다는 의미이다.③ 이 프로그램에 대해 10개의 테스트 입력 데이터 중에서 9개가 실행되었다는 의미이다.
④ 10개의 테스트 입력 데이터 중에서 9개가 오류를 검출하였다는 의미이다.
정답은 ②번입니다. 여기서 많은 분들이 '분기'와 '문장'을 혼동합니다.
- 문장 커버리지: 코드의 전체 라인 중 몇 줄이 실행되었는가를 측정합니다.
- 가장 단순하지만, 코드 내의 논리적 조건을 모두 확인하지 못하는 맹점이 있습니다.
- 분기 커버리지 (결정 커버리지): IF, CASE문과 같은 모든 '분기문'에 대해, 그 결과가 True인 경우와 False인 경우가 각각 한 번 이상씩 실행되었는지를 측정합니다.
- 예를 들어 if (x > 5)라는 코드가 있다면, x=10인 경우(True)와 x=3인 경우(False)를 모두 테스트해야 분기 커버리지를 만족하는 것입니다.
따라서 '90% 분기 커버리지'는 10개의 분기 조건 중 9개의 조건이 True/False 양방향으로 모두 테스트되었음을 의미합니다.
이는 코드의 논리적 경로를 얼마나 꼼꼼히 확인했는지를 보여주는,
문장 커버리지보다 훨씬 더 안전하고 튼튼한 구조 기반 테스트의 척도입니다.
4. 테스트 설계 기법: '경계'에서 버그가 태어난다
제한된 자원으로 최대의 효율을 내야 하는 테스터에게 '테스트 설계 기법'은 매우 중요합니다.
그중에서도 '경계값 분석'은 가장 실용적이고 중요합니다.
기출 예제 32번. 다음은 전면에 부착된 초음파 센서값에 따라 장애물을 피하는 로봇에 대한 요구사항 명세이다. 경계값 분석을 통하여 선정되는 테스트 입력값들로 가장 효율이 높은 것은 무엇인가?
- 0~5cm까지는 후진
- 10cm까지는 좌회전
- 100cm까지는 전진
이 문제의 요구사항을 정리하면 경계는 0, 5, 10, 100입니다.
(5와 10 사이의 구간은 명시되지 않았지만, 10cm '까지'는 좌회전이므로 6~10cm 구간으로 해석할 수 있습니다.)
경계값 분석의 핵심은, 프로그래머들이 경계 조건에서 >와 >=, <와 <=를 헷갈리는 실수를 자주 한다는 경험적 사실에 기반합니다.
따라서 우리는 경계 지점을 집중적으로 테스트해야 합니다.
- 경계 0, 5: 유효한 값의 최소 경계인 0, 5와 바로 바깥 값인 -1, 6을 테스트해야 합니다.
- 경계 10, 100: 유효한 값의 경계인 10, 100과 바로 바깥 값인 11, 101을 테스트해야 합니다.
이 값들을 조합하여 가장 효율적으로 테스트 케이스를 구성한 보기는 ③번(-1, 0, 5, 6, 10, 11, 100, 101)입니다.
각 경계의 바로 안쪽과 바깥쪽 값을 모두 포함하고 있기 때문입니다.
5. 정적 테스트: 실행하지 않고 결함 찾기
많은 수험생들이 '테스트 = 프로그램 실행'이라고만 생각합니다.
'정적 테스트'는 코드를 실행하지 않고, 명세서나 코드를 전문가들이 함께 검토(리뷰, 인스펩션)하거나
도구를 통해 분석하며 결함을 조기에 발견하는 매우 효율적인 활동입니다.
기출 예제 38번. 공식 검토 참가자에 대한 설명 중 올바르지 않은 것은?
① 주재자(Moderator)는 공식 검토를 계획하고 공식 검토 회의를 운영하며, 회의 종료 후 사후 관리를 한다.
② 작성자(Author)는 검토 대상 산출물 작성자로서 문서에 대한 책임이 있으며, 검토 시 해당 산출물에 관해 설명한다.
③ 검토자(Reviewer)는 검토 실행을 결정하고 프로젝트 일정 내에서 검토 시간을 할당하며, 검토 목표가 달성되었는지 판단한다.
④ 기록자(Recorder)는 회의 내용을 기록하고 모든 이슈 사항, 결함, 정의되어야 할 문제점 등을 문서화한다.
정답은 ③번입니다. 공식 검토에서 각자의 역할은 명확하게 분리되어 효율을 높입니다.
- 주재자(Moderator): 회의의 중립적인 '진행자'입니다.
- 작성자(Author): 산출물을 만든 '주인공'입니다.
- 기록자(Recorder): 회의록을 작성하는 '서기'입니다.
- 검토자(Reviewer): 동료의 시선에서 오류를 찾아내는 '매의 눈'입니다.
③번에서 설명하는 '실행 결정', '시간 할당', '목표 달성 판단'과 같은 역할은
프로젝트의 전반적인 책임을 지는 '관리자'의 역할에 가깝습니다.
검토자의 핵심 역할은 오직 '산출물을 검토하여 결함을 찾아내는 것'에 집중하는 것입니다.
이처럼 역할 분담의 원칙을 이해하는 것이 정적 테스트 파트의 핵심입니다.
CSTS 공부를 단순히 지식을 머릿속에 넣는 작업이라고 생각하지 마시고
복잡한 시스템의 위험을 예측하고, 논리적 함정을 피하며, 가장 효율적인 해결책을 설계하는 '문제 해결 능력'을 기른다고 생각해보세요.
AI 시대에 소프트웨어 품질은 더더욱 중요한 분야가 될 것입니다.
IT교육과 집필을 5년 넘게 해오면서
늘 수험생들이 가장 많이 혼동하는 개념들과 단답형 문제에서 점수를 가르는 패턴들을 따로 있다는 것을 알았습니다.
단순한 요약본이 아닌, '왜' 틀리는지, 그리고 출제자는 '어떻게' 함정을 파는지에 대한 비하인드 스토리를 늘 고민합니다.
이 글에 공감하고, 단순히 답을 외우는 것을 넘어 이러한 부분을 이해하고 싶으신 분들은
아래 댓글로 이 글에서 가장 도움이 되었던 부분이나, 현재 가장 답답하게 느끼는 파트를 남겨주세요.
제가 직접 정리한 추가 자료를 보내드리겠습니다.
모두들 화이팅입니다. :-)
