소프트웨어 테스팅의 발전: ISTQB, ISO/IEC/IEEE 25023, 29119를 중심으로

소프트웨어 테스팅 분야는 지난 수십 년간 체계적인 발전을 거듭해왔습니다.

특히 ISTQB(International Software Testing Qualifications Board)의 지식 체계와 ISO/IEC/IEEE의 관련 표준들은 소프트웨어 테스팅의 개념을 정립하고, 프로세스를 표준화하며, 품질 측정 방식을 구체화하는 데 핵심적인 역할을 해왔습니다.

ISO/IEC/IEEE는 세 개의 독립적인 국제 표준화 기구가 공동으로 표준을 개발하고 발표할 때 사용하는 표기입니다. 각 기관의 약자는 다음과 같습니다.

ISO (International Organization for Standardization): 국제표준화기구.제조업, 기술, 보건 등 다양한 산업 분야의 국제 표준을 제정하고 발행하는 비정부 기구입니다.

IEC (International Electrotechnical Commission): 국제전기기술위원회.[전기, 전자 및 관련 기술에 대한 국제 표준을 제정하고 발행하는 비영리 단체입니다.

IEEE (Institute of Electrical and Electronics Engineers): 국제전기전자공학자협회.전기, 전자, 컴퓨터 공학 및 정보 기술 분야를 중심으로 기술 혁신을 촉진하는 전문가 협회입니다.

이 세 기관은 각자의 전문 분야에서 표준을 개발하지만, 기술이 융합되고 상호 연관성이 높아짐에 따라 공동으로 표준을 제정하는 경우가 많습니다. ISO/IEC/IEEE라는 표기는 해당 표준이 세 기관의 협력을 통해 만들어졌음을 의미합니다.


이러한 발전 과정을 연대순으로 살펴보면 다음과 같습니다.

1998년 ~ 2000년대 초반: ISTQB의 등장과 지식 체계의 확립

1998년, ISTQB의 전신이라 할 수 있는 ISEB(Information Systems Examinations Board)가 'Certified Tester Syllabus'를 개발하며 소프트웨어 테스팅 전문가를 위한 체계적인 지식의 필요성을 제시했습니다.

이후 2002년 11월, ISTQB가 공식적으로 출범하며 국제적으로 통용되는 소프트웨어 테스팅 전문가 자격 제도의 기틀을 마련했습니다.

ISTQB는 소프트웨어 테스팅에 대한 공통된 용어와 개념을 정립하고, 기초부터 전문가 수준까지 단계별(Foundation, Advanced, Expert) 지식 체계를 구축했습니다. 2005년에는 첫 번째 ISTQB Foundation Level 실러버스(v1.0)가 발표되었으며, 이는 전 세계의 테스팅 전문가들이 공통된 지식 기반 위에서 소통하고 협력할 수 있는 발판이 되었습니다.

국내에는 2005년에 도입 되었습니다.
저는 2010년도에 영어로 자격을 취득 하였습니다.

국내: KOLAS 소프트웨어 시험 분야 인정

KOLAS(Korea Laboratory Accreditation Scheme, 한국인정기구)가 소프트웨어 분야의 시험 역량을 갖춘 기관을 '공인시험기관'으로 인정하기 시작한 것은 관련 국가표준(KS)이 제정되고 시험 분야가 공식적으로 개설되면서부터입니다.

시기: 정확한 날짜를 특정하기는 어렵지만, 소프트웨어 품질 및 테스팅 관련 KS 표준(예: KS X ISO/IEC 25023, KS X ISO/IEC/IEEE 29119 등)이 도입되고 해당 분야의 공인시험기관 인정 제도가 활성화된 것은 2000년대 중반 이후로 볼 수 있습니다.

근거: KOLAS는 국제표준인 ISO/IEC 17025(시험기관 및 교정기관의 자격에 대한 일반 요구사항)를 기반으로 운영됩니다. 국내에서는 이를 부합화한 KS Q ISO/IEC 17025를 기준으로 시험기관의 경영 시스템과 기술적 역량을 평가하여 특정 시험 분야에 대한 자격을 부여합니다.

의미: 국내 기업이나 연구소가 소프트웨어 시험 분야에서 KOLAS 공인시험기관으로 인정받으면, 그 기관이 발행한 시험성적서는 국가적인 공신력을 갖게 됩니다.

2. 국외: KOLAS의 국제 상호인정협정 (ILAC-MRA)

"국외 KOLAS 인증"이라는 것은 존재하지 않습니다. KOLAS는 대한민국의 국가인정기구이기 때문입니다. 대신, KOLAS가 발행한 공인성적서가 해외에서도 동일한 효력을 갖게 되는 '국제 상A호인정' 제도가 있습니다.

시기 (국제적 효력 발생): KOLAS는 2001년 5월, ILAC(International Laboratory Accreditation Cooperation, 국제시험기관인정협력체)의 상호인정협정(MRA, Mutual Recognition Arrangement)에 공식 서명했습니다.

근거: ILAC-MRA에 가입한 국가의 인정기구들은 동등한 수준의 역량을 갖춘 것으로 서로 인정합니다.

의미: 2001년부터 KOLAS 공인시험기관이 발행한 시험성적서는 ILAC-MRA에 가입한 미국, 일본, 독일, 중국 등 전 세계 100여 개 주요 국가에서 별도의 추가 시험 없이 그대로 인정됩니다. 즉, 국내에서 발행한 공인성적서가 곧 '국제 통용 성적서'가 되는 것입니다.

요약 정리
구분 국내 (KOLAS 공인시험기관 인정) 국외 (국제 상호인정)
개념 특정 소프트웨어를 시험할 능력이 있는 시험기관을 국가가 인정하는 제도 국내 KOLAS 공인성적서가 해외에서도 효력을 갖도록 하는 국가 간의 약속
주체 KOLAS (한국인정기구) ILAC (국제시험기관인정협력체)
시작 시점 S/W 분야는 2000년대 중반 이후 본격화 2001년 5월 (KOLAS의 ILAC-MRA 가입 시점)
핵심 시험기관의 신뢰성 확보 국내 성적서의 국제적 통용성 확보

결론적으로, 국내에서 소프트웨어 시험을 위한 KOLAS 공인시험기관 인정 제도는 2000년대 중반 이후부터 자리를 잡았으며, 이 성적서가 국제적으로 효력을 갖게 된 시점은 2001년부터라고 정리할 수 있습니다.

2007년 ~ 2013년: ISO/IEC/IEEE 29119 표준 개발 착수 및 발표

2007년 5월, 국제표준화기구(ISO)는 소프트웨어 테스팅에 대한 새로운 국제 표준 시리즈인 ISO/IEC/IEEE 29119의 개발에 착수했습니다. 이는 기존의 여러 표준을 통합하고 대체하기 위한 노력이었습니다.

수년간의 개발 끝에 2013년 9월, ISO/IEC/IEEE 29119의 첫 세 가지 파트가 발표되었습니다.

ISO/IEC/IEEE 29119-1: 개념 및 정의 (Concepts and definitions): 소프트웨어 테스팅의 핵심 용어와 개념을 정의하여 통일된 이해를 돕습니다.

ISO/IEC/IEEE 29119-2: 테스트 프로세스 (Test processes): 조직, 테스트 관리, 동적 테스트 등 다계층의 테스트 프로세스 모델을 정의하여 모든 소프트웨어 개발 생명주기에서 활용할 수 있는 프레임워크를 제공합니다.

ISO/IEC/IEEE 29119-3: 테스트 문서화 (Test documentation): 테스트 계획, 설계, 결과 보고 등 테스트 프로세스 전반에 걸쳐 필요한 문서의 표준 템플릿을 제공합니다.


이 표준들은 소프트웨어 테스팅을 보다 체계적이고 관리 가능한 프로세스로 재정의했으며, 특히 위험 기반 테스팅 접근 방식을 강조하여 테스트 활동의 효율성과 효과성을 높이는 데 기여했습니다.

2015년 ~ 2016년: 테스트 기법 및 품질 측정 표준의 확장

ISO/IEC/IEEE 29119 시리즈는 계속해서 발전하여 2015년 12월에는 네 번째 파트가, 2016년에는 다섯 번째 파트가 추가로 발표되었습니다.

ISO/IEC/IEEE 29119-4: 테스트 설계 기법 (Test techniques): 명세 기반, 구조 기반, 경험 기반 테스트 설계 기법을 정의하여 테스트 케이스를 체계적으로 도출할 수 있는 방법을 제시합니다.

ISO/IEC/IEEE 29119-5: 키워드 기반 테스팅 (Keyword-driven testing): 테스트 자동화의 한 형태인 키워드 기반 테스팅의 프레임워크와 적용 방법을 정의합니다.

키워드 기반 테스팅, 쉽게 이해하기

키워드 기반 테스팅을 요리 레시피에 비유하면 아주 쉽게 이해할 수 있습니다.

우리가 요리할 때를 생각해 보세요.

레시피의 각 단계: "볶는다", "끓인다", "간을 맞춘다" 같은 간단한 행동 지시어가 있습니다.

필요한 재료: "양파 1개", "소금 한 꼬집" 처럼 각 단계에 필요한 값이 있습니다.

실제 요리 기술: "볶는다"가 정확히 무엇인지, 불 세기는 어떻게 하고 얼마나 저어야 하는지에 대한 구체적인 방법은 요리사가 알고 있습니다.

키워드 기반 테스팅은 이와 똑같습니다.

키워드 (Keyword): "로그인한다", "클릭한다", "글자를입력한다" 처럼 테스트에 필요한 행동을 사람이 이해하기 쉬운 단어로 만들어 둔 것입니다. (마치 레시피의 '볶는다' 처럼요.)

테스트 데이터 (Test Data): 각 키워드를 실행할 때 필요한 값입니다. '로그인한다' 키워드에는 'ID'와 '비밀번호'가 필요하겠죠. (마치 '양파 1개', '소금 한 꼬집' 같은 재료입니다.)

실행 코드 (Implementation): "로그인한다" 라는 키워드를 컴퓨터가 실제로 실행할 수 있도록 만든 프로그래밍 코드입니다. 이 코드는 개발자나 자동화 전문가가 미리 만들어 둡니다. (마치 요리사의 '볶는 기술'과 같습니다.)

그래서 어떻게 사용하나요?

테스터는 코딩을 전혀 몰라도, 엑셀(Excel) 같은 표에 준비된 키워드와 필요한 데이터만 순서대로 나열해서 테스트 시나리오를 완성할 수 있습니다.

<예시: 엑셀 파일>

단계 키워드 데이터 1 데이터 2
1 로그인한다 user_id user_pw
2 클릭한다 '상품검색' 버튼
3 글자를입력한다 '검색창' '노트북'
4 검증한다 '검색결과' '노트북'

이렇게 표를 작성해두면, 자동화 도구가 이 표를 순서대로 읽으면서 각 키워드에 연결된 실제 코드를 실행시켜 테스트를 진행합니다.

핵심 장점

쉬운 테스트 작성: 코딩을 몰라도 키워드를 조합하여 자동화 테스트를 만들 수 있습니다.

높은 재사용성: '로그인한다' 키워드 하나만 잘 만들어두면 수십, 수백 개의 테스트에서 계속 가져다 쓸 수 있습니다.

편리한 유지보수: 만약 로그인 방식이 바뀌면, 수백 개의 테스트 시나리오를 고치는 대신 '로그인한다' 키워드의 실제 코드 딱 하나만 수정하면 됩니다.

결론적으로, 키워드 기반 테스팅은 '무엇을' 테스트할지(키워드)와 '어떻게' 테스트할지(코드)를 분리하여, 테스트 자동화를 훨씬 쉽고 효율적으로 만들어주는 방법입니다.

키워드 기반 테스트에서 한글로 작성된 엑셀 파일을 인식하고 동작하는 자동화 도구

과거에는 영문 환경을 기본으로 하는 도구가 많아 한글 처리(인코딩 문제 등)에 어려움이 있었지만, 현재 대부분의 최신 자동화 도구들은 유니코드(Unicode)를 지원하기 때문에 한글을 포함한 다국어 처리가 원활합니다.

키워드 기반 테스트에서 한글 엑셀 파일이 동작하는 방식은 크게 두 가지로 나눌 수 있습니다.

1. 상용 자동화 도구

사용하기 편리한 GUI(그래픽 사용자 인터페이스) 환경을 제공하는 유료 도구들입니다. 코딩 지식이 거의 없어도 사용할 수 있도록 만들어진 경우가 많으며, 엑셀 파일 연동과 한글 지원은 기본적인 기능으로 포함된 경우가 많습니다.

Ranorex: 엑셀, CSV 파일 등을 데이터 소스로 연결하여 테스트를 실행할 수 있습니다.

한글로 된 키워드나 테스트 데이터를 엑셀에 작성하고 이를 읽어들여 테스트 자동화를 수행하는 것이 가능합니다.

T-Plan Robot: 엑셀을 외부 데이터 소스로 활용하여 키워드 기반 테스트를 관리할 수 있습니다.
시각적인 인터페이스를 제공하여 비전문가도 쉽게 접근할 수 있도록 돕습니다.

기타 상용 도구: 그 외 다수의 상용 도구들이 키워드 기반 테스트 프레임워크와 엑셀 연동 기능을 제공하며, 대부분 한글 환경을 문제없이 지원합니다.

2. 오픈소스 프레임워크 (직접 구축)

개발 역량이 있는 팀에서 더 유연하게 프레임워크를 구축하고 싶을 때 사용하는 방식입니다.

Robot Framework: 파이썬 기반의 강력한 오픈소스 테스트 자동화 프레임워크입니다. 키워드 기반 테스트를 위해 태어났다고 해도 과언이 아닐 정도로 개념이 잘 잡혀 있습니다.
테스트 케이스를 간단한 표 형식(엑셀, TSV 등)으로 작성할 수 있으며, 키워드를 한글로 정의하고 사용하는 것이 완벽하게 가능합니다.

작동 방식:

엑셀 파일 작성: 엑셀에 | 키워드 | 인자1 | 인자2 | 와 같은 형식으로 한글 키워드와 데이터를 사용하여 테스트 시나리오를 작성합니다.

키워드 구현: "로그인", "상품 검색" 등 엑셀에 사용한 한글 키워드가 실제로 어떤 동작을 수행할지 파이썬 코드로 미리 함수를 만들어 둡니다.

실행: Robot Framework가 엑셀 파일을 읽어 들여 한 줄씩 해석하면서, 해당 한글 키워드에 연결된 파이썬 함수를 실행시켜 테스트를 진행합니다.

Selenium + 프로그래밍 언어 (Python, Java 등): 가장 널리 쓰이는 웹 자동화 라이브러리인 Selenium을 기반으로 직접 키워드 기반 프레임워크를 구축하는 방식입니다.

작동 방식:

엑셀 파싱 라이브러리 사용: 파이썬의 openpyxl이나 자바의 Apache POI 같은 라이브러리를 사용하여 엑셀 파일을 읽어 들입니다.

키워드 실행 로직 구현: 읽어 들인 키워드(예: "클릭")에 따라 어떤 Selenium 동작(예: element.click())을 수행할지 프로그래밍 코드로 직접 구현합니다.

한글 처리: 프로그래밍 언어에서 파일 입출력 시 인코딩(주로 'UTF-8')을 올바르게 설정해주면 한글 키워드나 데이터를 문제없이 처리할 수 있습니다.

결론적으로, 어떤 도구를 선택하든 한글로 된 엑셀 파일을 사용하여 키워드 기반 테스트를 자동화하는 것은 충분히 가능합니다.

팀의 기술 역량, 예산, 프로젝트의 특성을 고려하여 사용하기 편한 상용 도구를 선택하거나, 더 높은 자유도와 확장성이 필요하다면 오픈소스 프레임워크를 활용하여 직접 구축하는 방법을 선택할 수 있습니다.

키워드 기반 테스트(Keyword-Driven Testing, KDT)와 행동 기반 테스트(Behavior-Driven Testing/Development, BDT/BDD) 비교

둘 다 테스트를 사람이 이해하기 쉬운 언어로 작성한다는 공통점이 있지만, 그 철학과 목적, 사용 방식에서 중요한 차이가 있습니다.

두 가지를 명확하게 비교해 드리겠습니다.

핵심 비유로 이해하기

키워드 기반 테스트 (KDT)는 "요리 레시피"와 같습니다.

"재료를 넣는다", "볶는다", "끓인다" 와 같이 테스트를 수행하기 위한 구체적인 행동(How)들을 나열하는 방식입니다. 테스트 자동화의 '방법론' 에 가깝습니다.

행동 기반 테스트 (BDD)는 "손님에게 대접할 요리의 시나리오"와 같습니다.

"배고픈 손님이 식당에 와서, 특정 요리를 주문하면, 맛있는 음식을 대접받고 만족하며 나간다" 와 같이 사용자의 목표와 행동(What & Why)을 중심으로 시나리오를 서술합니다. 개발 '문화이자 소통 방식' 에 가깝습니다.

주요 차이점 비교표
구분 키워드 기반 테스트 (KDT) 행동 기반 테스트/개발 (BDD)
주요 목적 테스트 자동화의 효율화 및 재사용성 증대.코드를 몰라도 테스트를 만들 수 있게 하는 것에 집중. 팀(기획-개발-QA) 간의 명확한 소통과 협업.<br>소프트웨어의 '행동'에 대한 공통된 이해를 만드는 것에 집중.
작성 주체 주로 테스터(QA)가 중심이 되어 작성. 기획자, 개발자, 테스터 (3 Amigos) 가 함께 논의하고 작성.
언어/형식 키워드 + 데이터의 조합.(예: 로그인, ID, PW)<ㅡ자유로운 키워드 정의 가능. Gherkin이라는 정형화된 형식 사용.Given (전제) - When (행동) - Then (결과) 구조.
추상화 수준 낮은 수준의 행동(Action)을 추상화.(예: '클릭한다', '입력한다', '선택한다') 높은 수준의 사용자 행동(Behavior)을 추상화.(예: '사용자가 로그인에 성공한다')
관점 테스트 중심적 (How)"이 기능을 어떻게 테스트할 것인가?" 사용자/비즈니스 중심적 (What)"이 기능은 사용자를 위해 무엇을 해야 하는가?"
주요 도구 Robot Framework, Selenium/Appium 기반의 자체 프레임워크 Cucumber, SpecFlow, Behave
결과물 재사용 가능한 테스트 스크립트와 테스트 데이터. 모든 팀원이 이해하는 살아있는 문서(Living Documentation). (이 문서 자체가 테스트 코드가 됨)
더 쉬운 예시로 비교

상황: "사용자가 올바른 ID와 PW를 입력하면 로그인에 성공한다"

1. 키워드 기반 테스트 (KDT) 방식 (엑셀 예시)

테스터가 "어떻게 테스트할지"를 단계별로 정의합니다.

단계 키워드 대상 데이터
1 웹사이트이동 로그인 페이지 URL
2 글자입력 ID 입력창 my_id
3 글자입력 비밀번호 입력창 my_password
4 클릭 로그인 버튼
5 텍스트검증 사용자 이름 표시 my_id

장점: '글자입력', '클릭' 같은 키워드는 다른 테스트에서도 계속 재사용할 수 있습니다.

2. 행동 기반 테스트 (BDD) 방식 (Gherkin 예시)

기획자, 개발자, 테스터가 함께 "사용자가 무엇을 원하는지"를 시나리오로 정의합니다.

Generated gherkin
기능: 사용자 로그인

  시나리오: 올바른 정보로 로그인 성공
    Given 내가 로그인 페이지에 있을 때
    When 올바른 아이디와 비밀번호를 입력하고
    And 로그인 버튼을 누르면
    Then 로그인에 성공하여 내 정보 페이지로 이동한다


장점: 코드를 모르는 기획자도 이 시나리오를 읽고 소프트웨어의 기능 명세를 정확히 이해할 수 있습니다.

결론: 언제 무엇을 쓸까?

키워드 기반 테스트(KDT)를 선택하세요:

이미 정의된 요구사항을 바탕으로 테스트 자동화의 효율을 높이고 싶을 때.

QA팀 내에서 테스트 코드의 재사용성을 극대화하고 싶을 때.

비교적 기술적인 관점에서 테스트를 구축할 때.

행동 기반 테스트/개발(BDD)을 선택하세요:

프로젝트 시작 단계부터 기획-개발-QA 간의 오해를 줄이고 싶을 때.

요구사항 자체가 테스트 케이스이자 명세서가 되는 '살아있는 문서'를 만들고 싶을 때.

비즈니스 가치와 사용자 행동에 더 집중하고 싶을 때.

두 방식은 서로 배타적이지 않습니다. BDD의 Given-When-Then 시나리오의 각 단계를 구현할 때, 내부적으로는 키워드 기반 테스트의 '키워드'를 호출하는 방식으로 함께 사용하는 것도 매우 효과적인 전략입니다.

ISO/IEC 25023

이와 더불어 2016년 6월에는 소프트웨어 제품의 품질을 정량적으로 측정하고 평가하기 위한 중요한 표준인 ISO/IEC 25023이 발표되었습니다.

이 표준은 SQuaRE(Systems and software Quality Requirements and Evaluation) 시리즈의 일부로, ISO/IEC 25010에 정의된 기능성, 신뢰성, 사용성 등과 같은 품질 특성을 측정하기 위한 구체적인 지표를 제공합니다.

이로써 소프트웨어의 품질은 추상적인 개념이 아닌, 측정 가능한 목표가 되었습니다.

2018년 이후: 최신 동향을 반영한 지식 체계의 진화

소프트웨어 개발 방법론이 애자일, 데브옵스 등으로 빠르게 변화함에 따라 ISTQB 지식 체계 또한 지속적으로 개정되고 있습니다.

2018년과 2023년에 발표된 새로운 Foundation Level 실러버스는 애자일 테스팅, 리스크 기반 테스팅 등의 최신 동향을 적극적으로 반영했습니다.

이처럼 소프트웨어 테스팅 분야는 ISTQB의 실용적인 지식 체계와 ISO/IEC/IEEE의 국제 표준이 상호 보완하며 발전해왔습니다.

이를 통해 테스팅은 단순히 결함을 찾는 활동을 넘어, 소프트웨어 개발 생명주기 전반에 걸쳐 품질을 확보하고 비즈니스 리스크를 줄이는 핵심적인 엔지니어링 활동으로 자리매김하게 되었습니다.

#소프트웨어테스팅 #ISTQB #키워드기반테스팅 #행동기반개발 #테스트자동화 #ISO29119 #QA #소프트웨어품질 #KSTQB #테스트방법론