테스트의 모든것

엑셀 꿀팁: 아래로 드래그해도 옆으로(K열→L열) 자동 참조하는 마법의 수식! (#REF! 오류 해결)

testmanager — Tue, 14 Apr 2026 08:22:29 +0900

안녕하세요! 엑셀 작업을 하다 보면 이런 난감한 상황이 생기곤 하죠.

"수식은 아래 행으로 복사(드래그)하고 싶은데, 참조하는 데이터는 옆으로(K열, L열, M열...) 한 칸씩 옮겨졌으면 좋겠다!"

하지만 엑셀의 기본 채우기 핸들은 아래로 내리면 숫자(행)만 커질 뿐, 알파벳(열)은 변하지 않습니다. 일일이 수정하자니 양이 너무 많고(K열부터 BE열까지라니!), 그냥 끌어다 놓으면 오류가 나기도 하죠.

오늘은 이 고민을 한 방에 해결해 줄 OFFSET 함수 사용법을 아주 쉽게 알려드릴게요!

1. 왜 그냥 드래그하면 안 될까요?

왜 그냥 드래그하면 안 될까요

엑셀은 아래로 당기면 "아래 칸으로 가라는 뜻이구나!"라고 생각해서 숫자만 키웁니다.

알파벳을 바꾸고 싶다면 엑셀에게 "내가 아래로 한 칸 갈 때마다, 너는 옆으로 한 칸 이동해서 데이터를 가져와!"라고 명령을 내려야 해요.

2. 해결사: OFFSET 함수 등장!

해결사: OFFSET 함수 등장!

이럴 때 사용하는 마법의 수식이 바로 이것입니다. F3 셀에 아래 수식을 복사해서 넣어보세요.

=COUNTIF(OFFSET('01. 데이터'!K3:K4048, 0, ROW(A1)-1), "o")

3. 수식, 아주 쉽게 이해하기 (딱 3가지만 보세요)

수식, 아주 쉽게 이해하기 (딱 3가지만 보세요)

'01. 데이터'!K3:K4048: 우리의 기준점입니다. 제일 처음 시작하는 K열 범위를 딱 고정해둔 거예요.

ROW(A1)-1: 이 수식의 핵심 엔진입니다!

첫 번째 칸(F3)에서는 0이 되어 K열을 그대로 봅니다.

아래로 한 칸 내리면 자동으로 1이 되어, 기준점에서 오른쪽으로 1칸 옆인 L열을 봅니다.

또 내리면 자동으로 2가 되어 M열을 보게 되죠.

"o": 우리가 찾고 싶은 데이터(알파벳 o)의 개수를 세라는 뜻입니다.

4. 자주 발생하는 #REF! 오류, 왜 그럴까요?

혹시 수식을 넣었는데 #REF!라는 글자가 뜨나요? 이건 보통 "참조할 범위를 벗어났다"는 뜻이에요.

INDEX 함수를 쓸 때 범위를 K열 하나만 잡아놓고 "옆으로 가!"라고 하면 엑셀이 당황해서 오류를 냅니다.

위에서 알려드린 OFFSET 수식은 기준점만 있으면 알아서 옆으로 점프하기 때문에 오류 걱정 없이 안전하게 사용할 수 있습니다.

5. 마무리 팁

이제 F3 셀에 수식을 넣었다면, 오른쪽 하단 모서리를 잡고 F49 셀까지 쭉~ 내리세요.

K열부터 BE열까지의 데이터가 순식간에 착착 계산될 거예요!

일일이 수정하던 노가다 작업은 이제 끝! 엑셀 함수 하나로 정시퇴근하세요!

AI가 코딩하고 검증하는 시대, 신입 개발자와 QA가 살아남는 법: '코드 작성자'에서 '시스템 설계자'로

testmanager — Mon, 13 Apr 2026 08:13:03 +0900

최근 ‘바이브 코딩(Vibe Coding)’이라는 용어가 등장할 정도로 AI의 개발 능력은 가히 파괴적입니다.

AI가 코드를 짜고, 스스로 오류를 찾아 수정하며, 최종 결과물까지 내놓는 환경에서 "이제 신입 개발자와 QA는 필요 없는 것 아니냐"는 위기감이 고조되고 있습니다.

하지만 이는 직업의 소멸이 아니라 '역할의 패러다임 전환'으로 보아야 합니다.

변화하는 생태계에서 살아남기 위한 전략은 다음과 같습니다.

1. 신입 개발자: 'How'가 아닌 'Why'와 'What'에 집중하라

신입 개발자: 'How'가 아닌 'Why'와 'What'에 집중하라

단순한 문법 숙지와 코드 구현 능력은 이제 AI의 영역입니다.

신입 개발자는 AI가 생성한 코드의 '결과'만 보는 것이 아니라, 그 코드가 왜 그렇게 작성되었는지, 전체 시스템 아키텍처 내에서 어떤 영향을 미치는지 이해하는 '코드 리뷰 및 설계 능력'을 길러야 합니다.

AI는 부분적인 최적화에 강하지만, 비즈니스 로직의 맥락과 복잡한 요구사항의 이면을 읽는 데는 한계가 있습니다.

기술적 깊이와 함께 비즈니스 도메인 지식을 쌓아 AI를 진두지휘하는 '오케스트레이터'가 되어야 합니다.

"AI 오케스트레이터"가 되는 것은 결국 AI가 못하는 것을 내가 하는 사람이 되는 것입니다. 구체적으로 어떤 역량인지 풀어드릴게요.

AI 오케스트레이터란?

AI에게 코드를 "시키는" 사람이 아니라, 무엇을 만들어야 하는지, 왜 그렇게 만들어야 하는지를 정의하고 AI의 결과물을 검증·통합·책임지는 사람입니다.

2.1. 요구사항을 AI가 이해할 언어로 번역하는 능력

요구사항을 AI가 이해할 언어로 번역하는 능력

AI에게 "로그인 기능 만들어줘"라고 하는 사람과,

"OAuth 2.0 기반 소셜 로그인, 실패 시 3회 잠금, 재시도는 이메일 인증, 세션은 Redis에 저장, 모바일/웹 공용 토큰 구조"

라고 하는 사람의 결과물은 하늘과 땅 차이입니다. 이 번역 능력 자체가 핵심 경쟁력입니다.

훈련법: 기획서나 회의 내용을 읽고, "이걸 AI 프롬프트로 어떻게 쓸까?"를 매일 연습하세요.

2.2. AI가 생성한 코드를 "읽고 의심하는" 능력

AI는 그럴듯하지만 틀린 코드를 자주 냅니다. 오케스트레이터는 다음을 체크합니다.

보안 헛점: SQL Injection, 인증 우회 가능성
성능 지뢰: N+1 쿼리, 메모리 누수
숨겨진 가정: "이 코드는 DB 연결이 항상 성공한다고 가정하고 있네"
비즈니스 맥락 이탈: 기술적으론 맞지만 우리 정책상 틀린 로직

코드를 직접 짜는 능력보다 코드를 읽고 리뷰하는 능력을 먼저 키우세요.

2.3. 시스템 전체를 그리는 아키텍처 감각

AI는 파일 하나, 함수 하나는 잘 만듭니다. 하지만 다음은 못합니다.

이 기능이 3개월 후 확장될 때 어떻게 변해야 하는가
마이크로서비스 간 의존성이 어디서 꼬이는가
장애가 나면 어느 지점부터 롤백해야 하는가

훈련법: 실제 오픈소스 프로젝트(예: Supabase, Gitea)의 구조를 직접 읽고, "왜 이렇게 나눴을까?"를 분석하는 연습을 하세요.

2.4. 도메인 지식으로 AI의 맥락을 채우는 능력

같은 "결제 시스템"이라도 커머스/구독/B2B는 완전히 다릅니다. AI는 이 차이를 모릅니다. 오케스트레이터는 산업·비즈니스 맥락을 AI에게 주입하는 사람입니다.

"우리 서비스는 월정액 SaaS고, 해지 시 당월 말까지 유지, 환불 없음, 이 정책 전제로 결제 로직 설계해줘"

이 맥락을 모르면 AI는 틀린 방향으로 열심히 달립니다.

2.5. 여러 AI 도구를 조율하는 워크플로우 설계

오케스트레이터는 AI 한 개만 쓰는 게 아닙니다.

역할 도구 예시

코드 생성	Claude Code, Cursor, Copilot
테스트 자동화	Playwright AI, Testim
코드 리뷰	CodeRabbit
문서화	Mintlify, Notion AI
디버깅	Sentry + AI 분석

이 도구들을 언제, 어떤 순서로, 어떻게 조합할지 설계하는 것 자체가 실력입니다.

실전 로드맵 (6개월)

1~2개월: AI로 토이 프로젝트 끝까지 만들기
          → 직접 짜지 말고, AI에게 시키고 리뷰만 하기

3~4개월: 생성된 코드에서 버그·보안 이슈 10개 찾아서 기록하기
          → "AI가 어디서 틀리는가" 패턴 파악

5~6개월: 특정 도메인(핀테크/헬스케어/커머스 등) 하나를 깊게 파기
          → 그 도메인의 규제·정책·엣지케이스를 AI보다 많이 알기

핵심을 한 줄로 요약하면, "AI는 손, 나는 머리" 라는 구조를 만드는 것입니다. AI가 빠르게 만들수록, 그것을 올바른 방향으로 이끌고 검증하는 사람의 가치는 오히려 올라갑니다.

2. QA 엔지니어: '테스터'에서 '품질 전략가' 및 'AI 감리사'로

QA 엔지니어: '테스터'에서 '품질 전략가' 및 'AI 감리사'로

반복적인 테스트 케이스 실행과 단순 버그 탐지는 AI가 훨씬 빠르고 정확합니다.

앞으로의 QA는 AI가 놓치기 쉬운 보안 취약점, 윤리적 판단, 사용자 경험(UX)의 미묘한 결함을 잡아내는 고차원적인 검증에 집중해야 합니다.

또한 AI가 스스로 검증한 결과물이 정말 '신뢰할 수 있는지'를 검증하는 'AI 거버넌스' 역할로 확장해야 합니다.

테스트 자동화 툴을 직접 설계하거나, AI 모델의 편향성을 관리하는 품질 전략가로서의 역량이 생존의 핵심입니다.

QA 엔지니어의 역할 변화는 마치 '단순히 벽돌이 튼튼한지 두드려보던 검사원'에서, '건물 전체의 설계가 안전한지, 거주자가 행복할지 고민하는 총괄 감독관'으로 변하는 것과 같습니다.

앞으로 QA가 왜 '전략가'와 '감리사'가 되어야 하는지 3가지 핵심 포인트로 쉽게 풀어 설명해 드릴게요.

2.1. 단순 반복은 AI에게 맡기고, 사람은 '맥락'을 봅니다

과거의 QA는 "로그인 버튼을 누르면 로그인이 되는가?" 같은 수백 개의 테스트 케이스를 직접 클릭하며 확인했습니다.

하지만 이제 이런 일은 AI가 훨씬 더 빠르고 실수 없이 해냅니다.

기존의 일: 버튼 클릭, 오타 찾기, 단순 기능 작동 확인 (AI의 영역)
미래의 일 (UX/윤리 검증):
- "기능은 작동하지만, 사용자가 이 과정에서 불쾌함을 느끼지는 않을까?" (UX의 미묘한 결함)
- "챗봇이 사용자에게 차별적인 발언이나 위험한 조언을 하지는 않는가?" (윤리적 판단)
- 핵심: AI는 '맞다/틀리다'는 잘 보지만, '적절하다/불편하다' 같은 인간 중심의 가치는 판단하지 못합니다.

2.2. 'AI를 검사하는 AI 전문가' (AI 거버넌스 및 감리)

이제는 AI가 코드를 짜고, AI가 테스트를 수행하는 시대입니다.

그렇다면 "그 AI가 한 일을 어떻게 믿을 수 있는가?"라는 질문이 생깁니다. 이때 QA가 '감리사' 역할을 하게 됩니다.

AI 거버넌스(Governance): AI가 정해진 규칙과 법규를 잘 지키며 작동하도록 관리 체계를 만드는 것입니다.
AI 감리사: AI가 내놓은 결과물이 환각(Hallucination, 가짜 정보를 진짜처럼 말하는 현상)인지 아닌지 가려내고, AI 모델이 특정 인종이나 성별에 편향된 결과를 내놓지 않는지 감시합니다.
쉽게 말하면: "AI야, 네가 테스트한 결과 리포트 가져와 봐. 내가 제대로 검증했는지 검사할게"라고 말하는 AI의 상사 역할을 하는 것입니다.

2.3. 도구를 쓰는 사람에서 '전략을 짜는 사람'으로

단순히 남이 만든 테스트 도구를 사용하는 수준을 넘어서야 합니다.

테스트 자동화 설계: 어떤 단계에 어떤 AI 도구를 배치할지, 전체적인 품질 보증 파이프라인을 설계합니다.
데이터 전략: AI가 똑똑해지려면 좋은 데이터가 필요합니다. 테스트에 사용할 데이터를 어떻게 정제하고 관리할지 결정하는 것도 QA의 몫입니다.
품질 전략가: "이 서비스는 보안이 제일 중요하니 이 부분에 검증 자원의 70%를 집중하자"라고 결정하는 의사결정자가 됩니다.

요약하자면, 여러분의 모습은 이렇게 바뀝니다.

구분	과거의 QA (테스터)	미래의 QA (전략가/감리사)
주요 업무	테스트 케이스 실행, 버그 리포트 작성	품질 전략 수립, AI 결과물 신뢰성 검증
핵심 역량	꼼꼼함, 도구 사용 능력	비판적 사고, 보안/윤리 지식, 데이터 이해력
관점	"프로그램이 돌아가는가?"	"이 서비스가 신뢰할 수 있고 안전한가?"

AI 시대의 QA는 "기술적인 결함을 찾는 사람"에서 "서비스의 가치와 신뢰를 증명하는 사람"으로 진화해야 합니다.

AI가 '계산기'라면, QA는 그 계산기로 '어떤 수학 문제를 풀어서 어떤 가치를 만들지' 결정하는 사람이 되는 것입니다.

AI를 두려워하기보다, AI를 부하 직원으로 거느리고 더 높은 수준의 품질을 고민하는 '품질의 지휘자'가 되는 것이 핵심입니다.

3. 공통 역량: AI를 레버리지(Leverage)하는 능력

공통 역량: AI를 레버리지(Leverage)하는 능력

AI를 경쟁자로 보지 말고 가장 유능한 '부사수'로 활용하십시오.

복잡한 문제를 AI가 이해할 수 있는 작은 단위로 쪼개어 지시하는 프롬프트 엔지니어링 능력과, AI의 결과물을 비판적으로 수용하고 수정할 수 있는 문제 해결 능력이 필수입니다.

도구의 성능이 좋아질수록 그 도구를 다루는 사람의 '안목'과 '의사결정력'이 몸값을 결정하게 될 것입니다.

결국 AI는 '도구'일 뿐입니다.

엔진이 강력해졌다고 해서 운전사가 필요 없는 것은 아닙니다.

기술 변화를 두려워하기보다 AI라는 강력한 엔진을 달고 더 먼 곳을 바라보는 설계자로 거듭나십시오.

AI를 활용하는 능력, 즉 'AI 레버리지(Leverage)'는 쉽게 말해 AI라는 지렛대를 사용해 내 힘보다 훨씬 큰 성과를 내는 기술을 의미합니다.

이 부분을 아주 친숙한 비유와 함께 3가지 포인트로 나누어 더 쉽게 설명해 드릴게요.

3.1. AI는 '지치지 않는 인턴(부사수)'입니다

예전에는 QA 엔지니어가 직접 엑셀에 테스트 케이스 수백 개를 쓰고 하나씩 확인했다면, 이제는 똑똑하지만 가끔 엉뚱한 '신입 인턴'에게 그 일을 시키는 '팀장님'이 되어야 한다는 뜻입니다.

나쁜 예: "내가 다 할 테니까 넌 가만히 있어." (AI를 안 쓰고 혼자 고생함)
좋은 예: "인턴(AI)아, 이번에 새로 만든 결제 기능에서 발생할 수 있는 오류 시나리오 50개만 뽑아와 봐. 다 되면 내가 검토해 줄게."
결과: 사람이 3시간 걸릴 일을 AI는 3초 만에 합니다. 사람은 그 3초 뒤에 나온 결과물을 검토하기만 하면 됩니다.

3.2. '말귀'를 잘 알아듣게 시키는 법 (프롬프트 엔지니어링)

AI에게 일을 시킬 때 "그거 좀 해줘"라고 하면 AI는 대충 대답합니다. 일을 잘 시키려면 복잡한 문제를 작게 쪼개서 구체적으로 지시해야 합니다.

잘못된 지시: "이 앱 테스트해 줘." (범위가 너무 넓어 AI가 당황함)
잘된 지시 (쪼개기):
1. "이 앱의 로그인 화면 기획서야. 여기서 발생할 수 있는 예외 상황을 나열해 줘."
2. "그중에서 '비밀번호 5회 오류' 상황에 대한 테스트 코드를 작성해 줘."
3. "작성한 코드에 보안 취약점이 없는지 한 번 더 확인해 줘."
핵심: 문제를 작게 나눌수록 AI는 천재가 됩니다. 이 '나누는 능력'이 바로 실력입니다.

3.3. '정답'을 고르는 안목 (비판적 수용)

AI는 아주 자신 있게 '거짓말'을 할 때가 있습니다(환각 현상). 그래서 AI가 준 결과물을 그대로 믿으면 큰 사고가 날 수 있습니다.

AI의 한계: AI는 "이게 맞나?"라고 고민하지 않고, 가장 그럴듯한 답을 내놓을 뿐입니다.
사람의 역할: AI가 가져온 결과물을 보고 "어? 이 부분은 우리 서비스 정책이랑 안 맞는데?" 혹은 "이 코드는 실제로 돌리면 에러가 날 것 같은데?"라고 잡아내는 것입니다.
비유: 요리사가 재료 손질은 기계(AI)에게 맡기더라도, 마지막에 간을 보고 "소금 조금 더 넣어야겠네"라고 결정하는 것과 같습니다. 최종 맛(품질)에 대한 책임은 사람이 집니다.

왜 이것이 '몸값'을 결정하나요?

앞으로는 '기능을 테스트할 줄 아는 사람'은 흔해집니다. AI가 다 해주니까요. 하지만 다음 능력을 가진 사람은 귀해집니다.

전략적 사고: "지금 상황에서 어떤 테스트를 AI에게 시켜야 가장 효율적일까?"를 아는 사람
의사결정력: "AI는 괜찮다고 하지만, 내 경험상 이 부분은 위험해. 추가 점검하자!"라고 판단하는 사람
도구의 주인: AI라는 강력한 도구를 휘두르며, 혼자서 과거 10명분의 업무량을 처리하는 사람

AI = 가장 유능한 부사수

요약하자면

AI를 부하 직원처럼 부리세요. (지시하기)
일을 작게 나누어 시키세요. (프롬프트 엔지니어링)
결과물은 반드시 내 눈으로 확인하세요. (비판적 사고)

결국 "AI가 대신할 수 없는 나의 경험과 직관"을 AI의 "압도적인 속도"와 결합하는 능력이 여러분의 가장 큰 무기가 될 것입니다.

당신은 어떤 부사수를 사용하는지 댓글로 알려주세요

Tricentis 자동화 테스트 도구별 커스터마이징을 위한 필수 프로그래밍 언어 가이드

testmanager — Sun, 12 Apr 2026 08:01:29 +0900

최근 엔터프라이즈 환경에서 가장 주목받는 테스트 자동화 솔루션인 Tricentis는 '노코드(No-code)'와 '로우코드(Low-code)'를 지향합니다.

하지만 복잡한 비즈니스 로직을 처리하거나 독특한 UI 컨트롤을 제어하기 위해서는 때때로 직접적인 코딩을 통한 커스터마이징이 필요합니다.

오늘은 Tricentis의 주요 제품군별로 어떤 프로그래밍 언어를 사용하여 확장하고 커스터마이징할 수 있는지 정리해 드립니다.

1. Tricentis Tosca (토스카): 중심은 C#

Tricentis Tosca (토스카): 중심은 C#

Tosca는 기본적으로 모델 기반 테스트 방식을 사용하지만, 엔진을 확장하거나 특수한 기능을 구현할 때는 **C#(.NET)**을 주로 사용합니다.

사용처: 커스텀 컨트롤 생성, Special Execution Tasks(SETs) 개발, API 연동 및 프레임워크 확장 시 필수적입니다.

2. Tricentis Testim: 웹 기반의 JavaScript/TypeScript

Tricentis Testim: 웹 기반의 JavaScript/TypeScript

AI 기반의 UI 테스트 자동화 도구인 Testim은 현대적인 웹 환경에 맞춰 JavaScript와 TypeScript를 지원합니다.

사용처: 기본 제공 액션으로 해결되지 않는 복잡한 브라우저 로직을 처리하기 위해 'Custom Code Step'을 작성할 때 활용됩니다.

3. Tricentis NeoLoad: 성능 테스트를 위한 JavaScript

Tricentis NeoLoad: 성능 테스트를 위한 JavaScript

부하 및 성능 테스트 도구인 NeoLoad는 시나리오 내부에서 데이터의 동적 처리나 조건부 로직을 위해 JavaScript 스크립팅을 지원합니다.

사용처: 변수 추출 후 가공, 복잡한 if/else 논리 적용 등 성능 테스트의 유연성을 높일 때 사용됩니다.

4. Tricentis qTest: 개방형 API와 SDK

테스트 관리 플랫폼인 qTest는 특정 언어에 국한되지 않고 Java, Python, C#, JavaScript 등 다양한 언어를 지원합니다.

사용처: REST API를 통한 데이터 연동이나 qTest Launch를 활용해 Selenium, Pytest 등 오픈소스 프레임워크와 통합할 때 해당 언어들을 폭넓게 사용할 수 있습니다.

요약하자면,
Tricentis 환경에서 가장 깊이 있는 커스터마이징을 원하신다면 C#에 대한 이해가 가장 중요하며, 웹 및 성능 최적화 영역에서는 JavaScript가 핵심적인 역할을 합니다.

자신의 프로젝트가 어떤 도구를 주력으로 사용하는지에 맞춰 필요한 언어를 학습하시길 권장합니다.

당신은 어떤 언어를 선호하나요? 댓글로 알려주세요

"URL만 주면 AI가 테스트하는 시대, 당신의 테스트 역량은 안녕하십니까?"

testmanager — Fri, 10 Apr 2026 08:41:17 +0900

소프트웨어 테스트 현장에서 "시간당 단가(Man-Month)"로 승부하던 시대는 이미 저물고 있습니다.

이제 URL 하나만 입력하면 AI가 스스로 페이지를 탐색하고 테스트 케이스를 생성하며, 결과까지 도출하는 세상입니다.

하지만 여전히 많은 아웃소싱 현장의 테스터들은 단순 매뉴얼 테스트에 안주하며 다가올 거대한 변화를 외면하고 있습니다.

특히 KOLAS(한국인정기구) 공인시험기관의 위상은 단순히 '도구를 잘 쓰는 것'을 넘어, 그 도구가 내뱉은 결과가 얼마나 객관적이고 신뢰할 수 있는가를 증명하는 데 있습니다.

이제 테스트 아웃소싱은 단순 노동력 제공이 아닌, 고객의 비즈니스 문제를 해결하고 성과를 보장하는 SLA(Service Level Agreement) 기반 모델로 전환되어야 합니다.

변화의 파도 앞에서 우리와 팀원들이 나아가야 할 방향을 제시합니다.

1. KOLAS 시험기관의 새로운 역할: 'AI 품질 검증의 보루'

AI 도구를 활용한 테스트가 대세가 될수록, 그 테스트 결과에 대한 '공인된 신뢰성'은 더욱 중요해집니다. KOLAS 시험기관은 다음과 같은 역량을 갖춰야 합니다.

AI 도구의 적합성 평가: 사용 중인 AI 테스트 솔루션이 ISO/IEC 표준에 부합하는지, 편향성은 없는지 검증하는 상위 수준의 시험 프로세스 구축.

재현성 및 투명성 확보: AI는 매번 다른 결과를 낼 수 있습니다. 시험 결과의 재현성을 보장하기 위한 통계적 검증 기법 도입.

메타모픽 테스팅 도입: 정답이 모호한 AI 시스템의 성능을 검증하기 위한 고도화된 시험 기법 적용.

2. 테스터의 새로운 미션과 슬로건

현실에 안주하는 마음을 깨우기 위해 개인과 팀의 지향점을 재정의해야 합니다.

미션: "우리는 단순 결함 발견자가 아닌, 데이터와 AI를 활용해 고객의 비즈니스 리스크를 제로(Zero)화하는 품질 아키텍트이다."

슬로건: "AI로 가속하고, 통찰로 완성하라(Accelerate with AI, Complete with Insight)."

3. 생존을 위해 반드시 개발해야 할 4가지 핵심 역량

이제 '클릭'하는 손가락 대신 '생각'하는 뇌의 근육을 키워야 합니다.

프롬프트 엔지니어링: AI에게 정확한 테스트 맥락을 지시하고, 허위 결과(Hallucination)를 걸러내는 능력.

도메인 리스크 분석: 비즈니스 로직을 이해하고 AI가 놓치기 쉬운 치명적인 '엣지 케이스'를 설계하는 능력.

데이터 리터러시: 테스트 결과 데이터를 분석하여 품질 비용(CoQ) 절감 효과를 숫자로 입증하는 능력.

SLA 기반 문제 해결 능력: 단순 버그 리포팅을 넘어, "어떻게 하면 이 시스템의 장애율을 0.1% 낮출 것인가?"라는 관점의 솔루션 제시 능력.

마치며

AI는 우리의 일자리를 뺏으러 온 적이 없습니다. 다만, AI를 다루지 못하고 단순 반복 업무에 머무는 사람'의 자리를 'AI를 도구 삼아 가치를 창출하는 사람'에게 옮길 뿐입니다.

지금 당장 매뉴얼 테스트의 안락함에서 벗어나, 품질의 미래를 설계하는 아키텍트로 거듭나십시오.

당신의 생각은 어떠신가요. 댓글로 알려주세요

소프트웨어테스트, AI테스트, KOLAS, 테스트자동화, QA역량, SLA계약, 프롬프트엔지니어링, 품질보증, 테스트아웃소싱, DX전환

Tricentis 자동화 테스트 도구별 커스터마이징을 위한 필수 프로그래밍 언어 가이드

testmanager — Thu, 9 Apr 2026 08:00:24 +0900

최근 엔터프라이즈 환경에서 가장 주목받는 테스트 자동화 솔루션인 Tricentis는 '노코드(No-code)'와 '로우코드(Low-code)'를 지향합니다.

하지만 복잡한 비즈니스 로직을 처리하거나 독특한 UI 컨트롤을 제어하기 위해서는 때때로 직접적인 코딩을 통한 커스터마이징이 필요합니다.

오늘은 Tricentis의 주요 제품군별로 어떤 프로그래밍 언어를 사용하여 확장하고 커스터마이징할 수 있는지 정리해 드립니다.

1. Tricentis Tosca (토스카):

중심은 C#
Tosca는 기본적으로 모델 기반 테스트 방식을 사용하지만, 엔진을 확장하거나 특수한 기능을 구현할 때는 **C#(.NET)**을 주로 사용합니다.

사용처: 커스텀 컨트롤 생성, Special Execution Tasks(SETs) 개발, API 연동 및 프레임워크 확장 시 필수적입니다.

2. Tricentis Testim: 웹 기반의 JavaScript/TypeScript

3. Tricentis NeoLoad: 성능 테스트를 위한 JavaScript

4. Tricentis qTest:

개방형 API와 SDK
테스트 관리 플랫폼인 qTest는 특정 언어에 국한되지 않고 Java, Python, C#, JavaScript 등 다양한 언어를 지원합니다.

사용처: REST API를 통한 데이터 연동이나 qTest Launch를 활용해 Selenium, Pytest 등 오픈소스 프레임워크와 통합할 때 해당 언어들을 폭넓게 사용할 수 있습니다.

요약하자면,
Tricentis 환경에서 가장 깊이 있는 커스터마이징을 원하신다면 C#에 대한 이해가 가장 중요하며, 웹 및 성능 최적화 영역에서는 JavaScript가 핵심적인 역할을 합니다. 자신의 프로젝트가 어떤 도구를 주력으로 사용하는지에 맞춰 필요한 언어를 학습하시길 권장합니다.

[태그]
Tricentis, 토스카, Tosca, Testim, NeoLoad, qTest, 자동화테스트, 소프트웨어테스트, C#, JavaScript, TypeScript, 프로그래밍언어, 커스터마이징, 노코드, 로우코드, QA자동화

[첨부] 기획서 없이 바로 쓰는 생명보험 기간계 통합 테스트 시나리오 프레임워크(테스트케이스)

testmanager — Thu, 9 Apr 2026 06:59:27 +0900

명세서 없이 구현된 화면만으로 운영팀이 바로 써먹을 수 있는 통합 시나리오를 작성하려면 각 모듈을 독립적으로 보지 말고 데이터가 흘러가는 강물처럼 연결해야 합니다.

생명보험 기간계의 핵심은 계약의 생애주기입니다.

고객 등록, 청약(신계약), 입금, 유지(보전), 지급(사고), 회계처리로 이어지는 흐름을 끊지 않고 연결하는 것이 가장 중요합니다.

명세서가 없는 환경에서 시스템의 현재 상태를 완벽하게 파악하고 운영 이관을 준비하기 위한 모듈별 핵심 통합 테스트 시나리오 구성 전략을 공유합니다.

생명보험 기간계 통합 테스트 시나리오의 대전제는 하나의 증권번호(계약)를 끝까지 살려둔다는 것입니다.

이를 바탕으로 크게 4가지 흐름으로 테스트를 구성할 수 있습니다.

1. 4가지 흐름으로 테스트 구성

첫 번째는 신계약 성립부터 입금까지의 핵심 흐름입니다.

돈이 들어오고 계약이 정상적으로 생성되는지 검증하는 가장 중요한 단계입니다. 실명인증 우회 등을 통해 고객을 등록하고, 가입설계에서 주계약과 특약을 선택해 보험료가 자동 계산되는지 확인합니다.

이후 상품 설명 동의 등 완전판매를 거쳐 청약을 입력하고 심사를 통과시킵니다.

회 보험료 수납 처리 후 신계약 성립 확정을 통해 최종적으로 상태가 정상으로 변경되며 증권번호가 부여되는지 확인하는 것이 이 단계의 핵심입니다.

두 번째는 유지 관리, 즉 보전 및 대출 프로세스입니다.

이미 생성된 정상 상태의 계약 데이터를 변경했을 때 오류가 없는지 검증합니다.

통합 조회에서 생성한 증권번호의 데이터 정합성을 체크하고, 주소나 수익자 변경 시 고객 및 계약 정보가 잘 연동되는지 봅니다.

경과 기간에 따른 해약환급금이 상품 및 계리 로직대로 조회되는지, 그리고 그 환급금 범위 내에서 보험계약대출 한도가 잡히고 실제 대출 실행 시 원장에 반영되는지 테스트합니다.

변액상품이라면 펀드 변경 이력이 적립금에 잘 반영되는지도 확인해야 합니다.

세 번째는 지급 및 손익을 다루는 사고 및 재무회계 프로세스입니다.

돈이 나가는 지급 프로세스와 회계 장부가 일치하는지 검증합니다.

사고 접수 시 해당 계약의 담보 내역이 자동으로 조회되는지, 청구 금액에 따라 전결 결재 규정이 제대로 동작하는지 확인합니다.

보험금 지급 완료 후 계약 상태가 사망 소멸인지 유지인지 체크하고, 재보험 출재 대상 조회에 고액 계약이 잡히는지도 봅니다.

마지막으로 오늘 수납한 보험료와 지급한 보험금이 일일 마감을 통해 계정별 원장에 찍히고 차대변 전표가 생성되었는지 확인합니다.

네 번째는 성과 및 관리를 위한 영업관리 및 통계 프로세스입니다.

설계사의 실적과 수수료가 제대로 처리되는지 검증합니다.

신규 위촉된 설계사 코드로 신계약 입력이 가능한지, 성립된 계약이 해당 설계사의 실적으로 잡혀 수수료가 규정대로 산출되는지 봅니다.

또한 계약 해지 처리 시 기지급된 수수료에 대한 환수 데이터가 정상적으로 생성되는지도 중요한 테스트 포인트입니다.

운영팀을 위한 통합 시나리오 기술서를 엑셀 등으로 작성할 때는 시나리오 ID, 시나리오 명, 선행 조건, 테스트 절차, 기대 결과, 운영 팁으로 열을 나누어 명세서가 없어도 어떤 화면에서 무엇을 확인해야 하는지 명확하게 적어두는 것이 좋습니다.

예를 들어 변액 연금 펀드 변경 시나리오라면, 선행조건으로 정상 설계사 코드를 두고, 신계약 성립부터 입금, 펀드 투입 비율 변경까지의 절차를 적은 뒤, 적립금 조회 화면 금액 노출 및 펀드 변경 이력 확인을 기대 결과로 작성하는 식입니다.

지금 당장 명세서 없이 테스트를 해야 하는 상황이라면 복잡한 계리 수식을 일일이 검증하려 하지 마십시오.

화면에 뜬 해약환급금 예시표와 실제 해지 처리 화면의 금액이 같은지만 비교하는 등 화면 간의 비교에 집중하는 것이 효율적입니다.

재무나 회계 역시 입금 또는 지급 버튼을 눌렀을 때 전표 조회 화면에 데이터가 생성되는지 여부만 일차적으로 확인하십시오.

무엇보다 신계약에서 만든 단 하나의 증권번호를 가지고 입금, 보전, 대출, 사고, 해지까지 돌려막기식으로 재사용해야만 데이터가 어떻게 연결되고 유지되는지 정확히 파악할 수 있습니다.

2. 명세서 없이 바로 쓰는 생명보험 기간계 E2E 통합 테스트 시나리오 템플릿 무료 공유 생명보험_기간계_E2E통합테스트_100Chain_Defect30

금융 IT 프로젝트, 특히 생명보험 기간계 시스템의 신규 구축이나 차세대 이관 후 운영 업무를 맡게 되면 제대로 된 요구사항 명세서나 화면 설계서가 부족해 막막한 경우가 많습니다.

시스템의 전체적인 데이터 흐름과 각 업무 모듈 간의 연관성을 파악하려면 단편적인 단위 테스트가 아닌, 계약의 시작부터 끝까지 이어지는 E2E 통합 테스트 시나리오가 반드시 필요합니다.

오늘 무료로 공유해 드리는 자료는 생명보험_기간계_E2E통합테스트_100Chain_Defect30 개념을 바탕으로 현업 및 IT 운영 실무자가 즉시 활용할 수 있도록 작성된 테스트 시나리오 엑셀 템플릿입니다.

이 자료는 고객 등록, 가입설계, 청약, 신계약 승인, 입금 체결부터 유지보전, 보험계약대출, 사고금 지급, 영업관리, 재무회계 마감까지 하나의 증권번호가 겪게 되는 모든 생애주기를 끊기지 않고 추적하도록 설계되었습니다.

생명보험 시스템 테스트의 가장 중요한 원칙은 데이터의 연속성입니다.

개별 모듈에서 임의의 데이터를 생성하여 테스트하는 것이 아니라, 신계약 단계에서 정상적으로 성립시킨 단 하나의 증권번호를 가지고 입금 처리, 보전 변경, 대출 실행, 최종적인 해지나 사고 지급까지 단계별로 진행해야 합니다.

이를 통해 데이터가 다음 모듈로 넘어갈 때 원장이 어떻게 변하는지, 회계 전표가 정확히 차대변 균형을 맞추며 생성되는지를 직관적으로 확인할 수 있습니다.

본 시나리오 문서에는 복잡한 계리 수식을 시스템 없이 수작업으로 검증하는 무리한 방법 대신, 가입설계 화면에 노출된 해약환급금 예시표의 금액과 실제 해지 시뮬레이션 화면의 산출 금액을 대조하는 방식 등 실질적이고 효율적인 검증 포인트들이 담겨 있습니다.

또한 테스트 수행 시 선행되어야 할 조건과 화면에서 입력해야 할 절차, 그리고 데이터가 어떤 원장으로 흘러가는지에 대한 가이드가 포함되어 있습니다.

첨부된 템플릿을 다운로드하신 후 현재 운영 중인 시스템의 실제 메뉴명이나 화면 구조에 맞게 항목들을 조금만 수정하시면, 명세서가 없는 열악한 환경에서도 훌륭한 시스템 인수인계 자료이자 장애 예방 지침서로 활용하실 수 있을 것입니다.

실무자 여러분의 안정적인 시스템 운영과 테스트 업무에 유용한 참고 자료가 되기를 바랍니다.

생명보험_기간계_E2E통합테스트_100Chain_Defect30.xlsx

0.01MB

신계약,보전사고,영업관리,소프트웨어테스트,금융IT,생명보험, 기간계, 통합테스트, E2E테스트, 테스트시나리오, 금융IT, 소프트웨어테스팅, 테스트케이스, 차세대시스템, 운영유지보수

"나만 모르는 디자인 툴? 피그마(Figma) vs 모컵스(Moqups) 5분 만에 완벽 정리"

testmanager — Wed, 8 Apr 2026 08:00:57 +0900

안녕하세요! 오늘은 웹이나 앱 서비스를 기획할 때 꼭 들리는 두 가지 이름, 피그마(Figma)와 모컵스(Moqups)에 대해 아주 쉽게 풀어보려고 합니다.

"디자인은 포토샵으로 하는 거 아냐?"라고 생각하셨다면 주목해 주세요!

1. 피그마(Figma): "디자인계의 구글 문서"

피그마는 현재 전 세계 디자이너들이 가장 많이 사용하는 툴입니다.

특징: 여러 명이 동시에 접속해서 실시간으로 디자인을 수정할 수 있어요.

구글 문서처럼 링크만 있으면 누구나 들어와서 의견을 남길 수 있죠.

장점: 실제 앱처럼 작동하는 '프로토타입'을 만들기 좋습니다. 버튼을 누르면 다음 페이지로 넘어가는 효과 등을 아주 정교하게 구현할 수 있어요.

누구에게 추천? 전문적인 UI/UX 디자이너, 개발자와 긴밀하게 협업해야 하는 팀.

2. 모컵스(Moqups): "아이디어를 슥슥 그려내는 스케치북"

모컵스는 복잡한 기능보다는 '빠른 시각화'에 집중한 툴입니다.

특징: 드래그 앤 드롭 방식으로 미리 준비된 아이콘이나 버튼을 배치하기만 하면 됩니다.

전문적인 디자인 기술이 없어도 금방 '뼈대'를 잡을 수 있어요.

장점: 아주 쉽습니다.웹 브라우저에서 바로 실행되며, 복잡한 설정 없이도 서비스의 구조(와이어프레임)를 빠르게 그리는 데 최적화되어 있습니다.

누구에게 추천?

아이디어를 빠르게 시각화하고 싶은 기획자, 마케터, 혹은 디자인 입문자.

3. 한눈에 비교하기!

정밀함: 피그마(높음) > 모컵스(보통)

난이도: 피그마(조금 공부 필요) > 모컵스(매우 쉬움)

용도: 피그마는 '진짜 같은 완성본', 모컵스는 '아이디어 요약본'을 만들 때 유리합니다.

결론: 무엇을 써야 할까요?

완성도 높은 전문 디자인을 원한다면 피그마를, 복잡한 건 싫고 내 머릿속 아이디어를 빠르게 한 화면에 보여주고 싶다면 모컵스를 추천드립니다!

피그마, 모컵스, UI디자인, UX디자인, 와이어프레임, 프로토타입, 디자인툴추천, 웹기획, 앱디자인, 협업도구

엑셀 꿀팁: 아래로 드래그해도 옆으로(K열→L열) 자동 참조하는 마법의 수식! (#REF! 오류 해결)

testmanager — Tue, 7 Apr 2026 08:00:14 +0900

1. 왜 그냥 드래그하면 안 될까요?

엑셀은 아래로 당기면 "아래 칸으로 가라는 뜻이구나!"라고 생각해서 숫자만 키웁니다.

알파벳을 바꾸고 싶다면 엑셀에게 "내가 아래로 한 칸 갈 때마다, 너는 옆으로 한 칸 이동해서 데이터를 가져와!"라고 명령을 내려야 해요.

2. 해결사: OFFSET 함수 등장!

이럴 때 사용하는 마법의 수식이 바로 이것입니다. F3 셀에 아래 수식을 복사해서 넣어보세요.

=COUNTIF(OFFSET('01. 데이터'!K3:K4048, 0, ROW(A1)-1), "o")

3. 수식, 아주 쉽게 이해하기 (딱 3가지만 보세요)

'01. 데이터'!K3:K4048
: 우리의 기준점입니다. 제일 처음 시작하는 K열 범위를 딱 고정해둔 거예요.

ROW(A1)-1: 이 수식의 핵심 엔진입니다!

첫 번째 칸(F3)에서는 0이 되어 K열을 그대로 봅니다.

아래로 한 칸 내리면 자동으로 1이 되어, 기준점에서 오른쪽으로 1칸 옆인 L열을 봅니다.

또 내리면 자동으로 2가 되어 M열을 보게 되죠.

"o": 우리가 찾고 싶은 데이터(알파벳 o)의 개수를 세라는 뜻입니다.

4. 자주 발생하는 #REF! 오류, 왜 그럴까요?

혹시 수식을 넣었는데 #REF!라는 글자가 뜨나요?

이건 보통 "참조할 범위를 벗어났다"는 뜻이에요.

INDEX 함수를 쓸 때 범위를 K열 하나만 잡아놓고 "옆으로 가!"라고 하면 엑셀이 당황해서 오류를 냅니다.

위에서 알려드린 OFFSET 수식은 기준점만 있으면 알아서 옆으로 점프하기 때문에 오류 걱정 없이 안전하게 사용할 수 있습니다.

5. 마무리 팁

이제 F3 셀에 수식을 넣었다면, 오른쪽 하단 모서리를 잡고 F49 셀까지 쭉~ 내리세요. K열부터 BE열까지의 데이터가 순식간에 착착 계산될 거예요!

일일이 수정하던 노가다 작업은 이제 끝! 엑셀 함수 하나로 칼퇴하세요!

엑셀, 채우기핸들, 가로참조세로복사, OFFSET함수, ROW함수, 엑셀꿀팁, 직장인엑셀, 엑셀함수정리, REF오류해결, 열이동복사, COUNTIF응용, 엑셀독학, 업무자동화, 데이터집계, 엑셀수식오류

[유지 및 갱신] KOLAS 소프트웨어 시험기관 재평가(갱신) 절차 및 대비 전략 알아보니...

testmanager — Fri, 3 Apr 2026 08:00:55 +0900

안녕하세요! 지난 포스팅에서 신규 인정 절차를 다뤘다면, 오늘은 이미 인정받은 기관이 그 자격을 유지하기 위해 반드시 거쳐야 하는 KOLAS 재평가(갱신) 과정에 대해 알아보겠습니다.

KOLAS 인정은 한 번 받으면 영구적인 것이 아니라, 보통 4년마다 재평가를 통해 자격을 갱신해야 합니다.

기간을 놓치면 인정이 취소될 수 있으므로 미리 준비하는 것이 무엇보다 중요합니다.

1. 신청 시기 (가장 중요!)

재평가는 인정 유효기간이 만료되기 전 모든 절차를 마쳐야 합니다.

신청 기한: 유효기간 만료일 9개월 전에 신청하는 것이 권장됩니다.
주의사항: 심사 지연 등으로 인해 유효기간 내에 재인정 결정이 나지 않으면, 유효기간 만료일부터 재인정 공고일까지 공인성적서 발행이 중단될 수 있습니다.

2. 재평가 신청 전 필수 체크리스트

신규 인정과 마찬가지로, 재평가 전에도 반드시 완료되어야 하는 항목들이 있습니다.

숙련도 시험 참여: 인정받은 모든 소분류(범위)에 대해 유효기간 내에 최소 1회 이상 숙련도 시험에 참여하여 만족한 결과를 보유해야 합니다.
교육 이수: 기술책임자 및 품질책임자, 실무자의 정기적인 보수 교육 이수 여부를 확인합니다.
내부심사 및 경영검토: 최근 1년 이내에 실시한 내부심사와 경영검토 기록이 완벽히 구비되어야 합니다.
변경사항 보고: 지난 4년간 조직, 인력, 설비, 장소 등에 변경이 있었다면 제때 보고되었는지 점검합니다.

3. 재평가 신청 절차

접수: 온라인으로 신청합니다.
제출 서류: 재평가 신청서, 품질매뉴얼/절차서(최신본), 지난 주기의 사후관리 결과, 숙련도 시험 실적, 시험 실적 목록 등.
수수료: 신규 신청과 유사하게 신청 수수료 및 평가사 수당 등을 납부합니다.

4. 재평가 심사 (문서 및 현장 평가)

재평가는 지난 4년간의 운영 상태를 종합적으로 검토합니다.

운영 기록 확인: 단순한 시험 역량뿐만 아니라, 4년 동안 품질 시스템을 얼마나 성실히 운영했는지(부적합 관리, 고객 불만 처리, 데이터 보호 등)를 중점적으로 봅니다.
현장 시험(Witness): 인정 범위 내의 대표적인 소프트웨어 시험을 직접 시연하며 기술적 숙련도가 유지되고 있는지 확인받습니다.
기술적 유효성: 업데이트된 표준이나 최신 시험 기법이 절차서에 적절히 반영되었는지 평가합니다.

5. 부적합 시정 및 최종 승인

시정 조치: 평가에서 지적된 부적합 사항에 대해 근본 원인을 분석하고 시정 조치 결과 보고서를 제출합니다.
인정위원회 심의: 시정 조치가 완료되면 KOLAS 인정위원회의 심의를 거쳐 갱신 여부가 최종 결정됩니다.
인정서 갱신: 심의 통과 시 유효기간이 연장된 새로운 인정서를 교부받게 됩니다.

재평가 성공을 위한 핵심 팁

사후관리 기록 유지: 2년 주기로 진행되는 '사후관리' 결과를 잘 정리해두어야 재평가가 수월합니다.
데이터 무결성: 소프트웨어 시험 데이터의 수정 이력(Log) 관리와 보안이 더욱 강조되고 있으므로 이에 대한 관리를 철저히 하세요.
최신 표준 반영: 재평가 주기 동안 관련 ISO 표준이나 KOLAS 지침이 개정되었다면, 우리 기관의 문서에도 즉각 반영되어 있어야 합니다.

재평가는 단순한 자격 유지를 넘어 기관의 전문성을 다시 한번 증명하는 기회입니다.

철저한 준비로 공신력을 지속해 나가시기 바랍니다!

KOLAS, 소프트웨어시험기관, 재평가, 인정갱신, 유효기간연장, ISO/IEC17025, 사후관리, 숙련도시험, 품질경영시스템, 시험역량유지

[완벽 가이드] 소프트웨어 시험기관 KOLAS 최초 신규 인정 신청 절차 및 준비 사항 알아보니..

testmanager — Thu, 2 Apr 2026 21:37:11 +0900

안녕하세요! 오늘은 소프트웨어(SW) 품질의 신뢰성을 객관적으로 증명하기 위한 필수 관문인 KOLAS(한국인정기구) 소프트웨어 시험기관 신규 인정 신청 과정에 대해 상세히 알아보겠습니다.

소프트웨어 시험기관으로 인정을 받으면 국제적으로 통용되는 공인시험성적서를 발행할 수 있는 권한을 갖게 됩니다.

하지만 준비 과정이 매우 까다롭고 복잡하여 철저한 대비가 필요합니다. 그 핵심 과정을 단계별로 정리해 드립니다.

1. 사전 준비 단계 (시스템 구축)

가장 먼저 ISO/IEC 17025(시험기관 및 교정기관의 자격에 대한 일반 요구사항) 국제 표준에 부합하는 경영시스템을 구축해야 합니다.

품질문서 작성: 품질매뉴얼, 절차서, 지침서, 양식을 기관의 상황에 맞게 제정합니다.
조직 구성: 인력 양성 및 배치가 중요합니다. 기술책임자(TM), 품질책임자(QM)를 임명하고, 해당 인원들은 KOLAS에서 지정한 법정 교육을 반드시 이수해야 합니다.
시험 장비 및 환경: 소프트웨어 시험을 수행하기 위한 서버, PC, OS, 분석 도구 등 인프라를 갖추고 관리 대장을 작성합니다.

2. 내부 운영 및 실적 확보

문서만 있다고 신청할 수 있는 것이 아닙니다. 실제로 시스템이 운영되고 있다는 증거가 필요합니다.

숙련도 시험 참여: KOLAS가 인정하는 숙련도 시험 프로그램에 참여하여 시험 결과의 정확성을 입증해야 합니다. (최초 신청 시 필수)
내부심사 수행: 자체적으로 품질 시스템이 잘 작동하는지 내부심사를 실시하고 부적합 사항을 시정합니다.
경영검토: 최고경영자가 품질 시스템의 적절성과 유효성을 검토한 기록이 있어야 합니다.
시험 실적: 인정받고자 하는 범위(분야)에 대해 최소 1회 이상의 시험 실적(모의 시험 포함)을 확보해야 합니다.

3. 인정 신청 ( e-KOLAS(KOLAS 업무처리 시스템) )

모든 준비가 완료되면 온라인 시스템을 통해 신청서를 접수합니다.

접수처: KOLAS 온라인 시스템 (e-KOLAS)

제출 서류: 인정신청서, 법인등록증, 품질매뉴얼 및 절차서, 숙련도 시험 결과, 교육 이수증, 시험시설 현황 등.
수수료 납부: 신청 수수료 및 심사비 등을 납부합니다.

4. 문서 심사 및 현장 평가

신청서가 접수되면 KOLAS 사무국에서 심사반을 구성합니다.

문서 심사: 제출한 품질 문서가 요건에 부합하는지 먼저 검토합니다. 보완 사항이 발생하면 수정 후 다시 제출해야 합니다.
현장 평가: 심사위원이 직접 기관을 방문하여 인력, 장비, 환경, 시험 방법의 적절성을 평가합니다. 실제 소프트웨어 시험 시연(Witness)을 통해 기술적 역량을 집중적으로 점검합니다.

5. 부적합 시정 조치 및 심의

부적합 시정: 현장 평가에서 지적된 사항에 대해 일정 기간 내에 시정 조치를 완료하고 결과 보고서를 제출해야 합니다.
인정위원회 심의: 평가 결과와 시정 조치 내용을 바탕으로 KOLAS 인정위원회에서 최종 승인 여부를 결정합니다.

6. 인정서 교부 및 공고

최종 승인이 나면 KOLAS 공인시험기관 인정서가 교부되며, KOLAS 홈페이지에 해당 기관의 명칭과 인정 범위가 공고됩니다.

이제 공식적으로 공인시험성적서를 발행할 수 있습니다.

성공을 위한 팁

소프트웨어 분야는 측정불확도 산출이나 시험방법의 유효성 확인(Validation) 절차가 일반 하드웨어 시험과 달라 까다로울 수 있습니다.

따라서 관련 가이드라인을 충분히 숙지하고, 필요하다면 전문가의 컨설팅을 받는 것도 좋은 방법입니다.