AI를 안 쓰면 안 되는 세상에서 잘 적응하고 계실까요?
아래 목록처럼 상황에 따라, 업무 분야에 따라 다양한 AI를 사용하며 업무나 개인적인 작업에 효율적인 부분을 향상시키기 위해 AI를 활용하고 있다고 생각합니다.

저 역시 필요에 따라 GPT, Claude, IntelliJ AI 등을 활용하여 업무에 활용하고 있고, QA로써 어떤식으로 활용했는지 정리해 볼 겸 작성해보려고 합니다.
기획 문서를 활용한 매뉴얼 TC 초안 작성
요즘 Figma를 통한 기획 문서를 공유해서 기획 - 개발 - 품질 팀간 소통 하는 것을 많이 사용하는데, 저는 이렇게 작성된 이미지를 활용해서 TC 초안을 작성해 달라고 요청하는 편입니다.
예시로 Figma 무료 템플릿을 활용하여 TC 초안을 작성해보겠습니다

로그인 페이지, 회원가입 페이지, 비밀번호 찾기 페이지 3가지로 구분된 화면을 가져왔고, 이 이미지를 활용해서 Claude에 TC 초안을 생성해 달라고 해보겠습니다.

위처럼 테스트 케이스를 작성하되, 정상과 비정상 케이스를 구분해서 작성해 달라고 요청한 결과입니다.
간단한 이미지이지만 TC로 만들어본다면 생각보다 많은 TC가 출력되는 것을 알 수 있습니다.
출력된 내용은 아래 접은 글에 작성해 두겠습니다. 결과를 확인해 보실 분들은 "더보기" 버튼을 클릭해서 확인해 보세요!
테스트케이스 초안
1. Welcome Back (로그인) 화면
정상 테스트케이스
TC ID 테스트 항목 전제 조건 테스트 단계 예상 결과
| TC_LOGIN_001 | 유효한 사용자명/이메일과 비밀번호로 로그인 | 등록된 계정 존재 | 1. Username or Email 입력<br>2. Password 입력<br>3. Login 버튼 클릭 | 로그인 성공 및 메인 화면 이동 |
| TC_LOGIN_002 | 비밀번호 표시/숨김 토글 | - | 1. Password 입력<br>2. 눈 아이콘 클릭 | 비밀번호가 평문/마스킹 처리로 전환 |
| TC_LOGIN_003 | Google 소셜 로그인 | - | 1. Google 아이콘 클릭 | Google 인증 페이지로 이동 |
| TC_LOGIN_004 | Apple 소셜 로그인 | - | 1. Apple 아이콘 클릭 | Apple 인증 페이지로 이동 |
| TC_LOGIN_005 | Facebook 소셜 로그인 | - | 1. Facebook 아이콘 클릭 | Facebook 인증 페이지로 이동 |
| TC_LOGIN_006 | Forgot Password 링크 클릭 | - | 1. "Forgot Password?" 링크 클릭 | 비밀번호 찾기 화면으로 이동 |
| TC_LOGIN_007 | Sign Up 링크 클릭 | - | 1. "Sign Up" 링크 클릭 | 회원가입 화면으로 이동 |
네거티브 테스트케이스
TC ID 테스트 항목 전제 조건 테스트 단계 예상 결과
| TC_LOGIN_N001 | 잘못된 비밀번호로 로그인 시도 | 등록된 계정 존재 | 1. 올바른 Username or Email 입력<br>2. 잘못된 Password 입력<br>3. Login 버튼 클릭 | 로그인 실패 에러 메시지 표시 |
| TC_LOGIN_N002 | 존재하지 않는 계정으로 로그인 시도 | - | 1. 등록되지 않은 Username or Email 입력<br>2. 임의의 Password 입력<br>3. Login 버튼 클릭 | 계정이 존재하지 않음 에러 메시지 표시 |
| TC_LOGIN_N003 | 빈 필드로 로그인 시도 | - | 1. 모든 필드 비워둠<br>2. Login 버튼 클릭 | 필수 입력 필드 에러 메시지 표시 |
| TC_LOGIN_N004 | Username만 입력 후 로그인 시도 | - | 1. Username or Email만 입력<br>2. Login 버튼 클릭 | 비밀번호 입력 필요 에러 메시지 표시 |
| TC_LOGIN_N005 | Password만 입력 후 로그인 시도 | - | 1. Password만 입력<br>2. Login 버튼 클릭 | Username or Email 입력 필요 에러 메시지 표시 |
| TC_LOGIN_N006 | SQL Injection 공격 시도 | - | 1. Username 필드에 SQL Injection 코드 입력<br>2. Login 버튼 클릭 | 입력값 검증 및 로그인 실패 |
| TC_LOGIN_N007 | 특수문자만 입력 | - | 1. Username 필드에 특수문자만 입력<br>2. Password 필드에 특수문자만 입력<br>3. Login 버튼 클릭 | 적절한 에러 메시지 표시 |
2. Create an account (회원가입) 화면
정상 테스트케이스
TC ID 테스트 항목 전제 조건 테스트 단계 예상 결과
| TC_SIGNUP_001 | 유효한 정보로 회원가입 | - | 1. Username or Email 입력<br>2. Password 입력<br>3. Confirm Password에 동일한 비밀번호 입력<br>4. Create Account 버튼 클릭 | 회원가입 성공 및 확인 메시지 표시 |
| TC_SIGNUP_002 | 비밀번호 표시/숨김 토글 (Password) | - | 1. Password 입력<br>2. 눈 아이콘 클릭 | 비밀번호가 평문/마스킹 처리로 전환 |
| TC_SIGNUP_003 | 비밀번호 표시/숨김 토글 (Confirm) | - | 1. Confirm Password 입력<br>2. 눈 아이콘 클릭 | 비밀번호가 평문/마스킹 처리로 전환 |
| TC_SIGNUP_004 | 이메일 형식 유효성 검증 | - | 1. 올바른 이메일 형식 입력 (예: test@example.com) | 입력 허용 |
| TC_SIGNUP_005 | Google 소셜 회원가입 | - | 1. Google 아이콘 클릭 | Google 인증 페이지로 이동 |
| TC_SIGNUP_006 | Apple 소셜 회원가입 | - | 1. Apple 아이콘 클릭 | Apple 인증 페이지로 이동 |
| TC_SIGNUP_007 | Facebook 소셜 회원가입 | - | 1. Facebook 아이콘 클릭 | Facebook 인증 페이지로 이동 |
| TC_SIGNUP_008 | Login 링크 클릭 | - | 1. "Login" 링크 클릭 | 로그인 화면으로 이동 |
| TC_SIGNUP_009 | Register 체크박스 동의 | - | 1. "By clicking the Register button..." 문구 확인<br>2. Create Account 클릭 | 약관 동의 처리 |
네거티브 테스트케이스
TC ID 테스트 항목 전제 조건 테스트 단계 예상 결과
| TC_SIGNUP_N001 | 비밀번호 불일치 | - | 1. Username or Email 입력<br>2. Password 입력<br>3. Confirm Password에 다른 비밀번호 입력<br>4. Create Account 버튼 클릭 | 비밀번호 불일치 에러 메시지 표시 |
| TC_SIGNUP_N002 | 빈 필드로 회원가입 시도 | - | 1. 모든 필드 비워둠<br>2. Create Account 버튼 클릭 | 필수 입력 필드 에러 메시지 표시 |
| TC_SIGNUP_N003 | 잘못된 이메일 형식 입력 | - | 1. Username or Email에 잘못된 형식 입력 (예: test@)<br>2. 나머지 필드 정상 입력<br>3. Create Account 버튼 클릭 | 이메일 형식 오류 메시지 표시 |
| TC_SIGNUP_N004 | 이미 존재하는 계정으로 가입 시도 | 이미 등록된 이메일 존재 | 1. 기존 계정의 이메일 입력<br>2. 나머지 필드 입력<br>3. Create Account 버튼 클릭 | 이미 존재하는 계정 에러 메시지 표시 |
| TC_SIGNUP_N005 | 짧은 비밀번호 입력 | - | 1. Username or Email 입력<br>2. 너무 짧은 Password 입력 (예: 123)<br>3. Confirm Password에 동일 입력<br>4. Create Account 버튼 클릭 | 비밀번호 길이 요구사항 에러 메시지 표시 |
| TC_SIGNUP_N006 | Username만 입력 후 가입 시도 | - | 1. Username or Email만 입력<br>2. Create Account 버튼 클릭 | 필수 입력 필드 에러 메시지 표시 |
| TC_SIGNUP_N007 | 특수문자만으로 비밀번호 설정 | - | 1. Username or Email 입력<br>2. Password에 특수문자만 입력<br>3. Confirm Password에 동일 입력<br>4. Create Account 버튼 클릭 | 비밀번호 복잡도 요구사항 에러 메시지 표시 |
| TC_SIGNUP_N008 | XSS 공격 시도 | - | 1. Username 필드에 스크립트 코드 입력<br>2. Create Account 버튼 클릭 | 입력값 검증 및 가입 실패 |
3. Forgot password (비밀번호 찾기) 화면
정상 테스트케이스
TC ID 테스트 항목 전제 조건 테스트 단계 예상 결과
| TC_FORGOT_001 | 유효한 이메일로 비밀번호 재설정 요청 | 등록된 계정 존재 | 1. 등록된 이메일 주소 입력<br>2. Submit 버튼 클릭 | 비밀번호 재설정 이메일 발송 성공 메시지 표시 |
| TC_FORGOT_002 | 이메일 형식 유효성 검증 | - | 1. 올바른 이메일 형식 입력 (예: test@example.com) | 입력 허용 |
네거티브 테스트케이스
TC ID 테스트 항목 전제 조건 테스트 단계 예상 결과
| TC_FORGOT_N001 | 빈 이메일 필드로 제출 | - | 1. 이메일 필드 비워둠<br>2. Submit 버튼 클릭 | 이메일 입력 필요 에러 메시지 표시 |
| TC_FORGOT_N002 | 잘못된 이메일 형식 입력 | - | 1. 잘못된 형식 입력 (예: test@, @test.com)<br>2. Submit 버튼 클릭 | 이메일 형식 오류 메시지 표시 |
| TC_FORGOT_N003 | 등록되지 않은 이메일로 요청 | - | 1. 등록되지 않은 이메일 주소 입력<br>2. Submit 버튼 클릭 | 계정을 찾을 수 없음 에러 메시지 표시 또는 보안을 위해 성공 메시지 표시 |
| TC_FORGOT_N004 | 특수문자만 입력 | - | 1. 특수문자만 입력<br>2. Submit 버튼 클릭 | 이메일 형식 오류 메시지 표시 |
| TC_FORGOT_N005 | 공백만 입력 | - | 1. 공백만 입력<br>2. Submit 버튼 클릭 | 이메일 입력 필요 에러 메시지 표시 |
| TC_FORGOT_N006 | 중복 요청 (짧은 시간 내) | 이미 요청 완료 | 1. 유효한 이메일 입력<br>2. Submit 버튼 클릭<br>3. 즉시 다시 Submit 클릭 | 재요청 제한 에러 메시지 표시 또는 쿨다운 안내 |
공통 UI/UX 테스트케이스
정상 테스트케이스
TC ID 테스트 항목 전제 조건 테스트 단계 예상 결과
| TC_UI_001 | 반응형 디자인 (모바일) | - | 1. 다양한 모바일 화면 크기에서 확인 | 모든 요소가 적절히 표시 |
| TC_UI_002 | 버튼 hover 효과 | - | 1. 버튼에 마우스 올림 | hover 효과 표시 |
| TC_UI_003 | 입력 필드 포커스 | - | 1. 입력 필드 클릭 | 포커스 인디케이터 표시 |
| TC_UI_004 | 화면 간 네비게이션 | - | 1. 각 화면 간 이동 링크 클릭 | 올바른 화면으로 전환 |
네거티브 테스트케이스
TC ID 테스트 항목 전제 조건 테스트 단계 예상 결과
| TC_UI_N001 | 매우 긴 텍스트 입력 | - | 1. 입력 필드에 매우 긴 텍스트 입력 (1000자 이상) | 적절한 길이 제한 또는 스크롤 처리 |
| TC_UI_N002 | 네트워크 오류 시뮬레이션 | - | 1. 네트워크 연결 끊음<br>2. Submit/Login 버튼 클릭 | 적절한 에러 메시지 표시 |
| TC_UI_N003 | 버튼 연속 클릭 (Double submit) | - | 1. Submit 버튼 빠르게 여러 번 클릭 | 중복 요청 방지 처리 확인 |
이 테스트케이스들은 초안이므로, 실제 프로젝트의 요구사항과 비즈니스 로직에 맞춰 수정하거나 추가해야 할 수 있습니다.
그렇다면 이 TC들은 바로 적용할 수 있을까요?
물론 특정 부분은 바로 사용할 수 있겠지만, 저는 출력된 결과를 확인해서 TestRail 같은 TC 관리 툴에 적용할 TC를 선별하고, 부족한 부분을 추가하거나 수정하여 TC를 관리합니다.
이렇게 활용한다면 가장 큰 장점은 기획 문서에서 도출할 TC의 아이디어 시간을 줄일 수 있습니다.
기획 문서를 보면서 내가 생각하지 못했던 부분이나, 놓칠 수 있는 부분까지 확인해 주는 역할을 AI가 진행하게 되며, 저는 가져온 결과를 눈으로 확인하고 재검토만 하면 TC를 빠르게 찍어낼 수 있다는 장점이 있어서 자주 활용하였습니다.
하지만 분명 부족한 부분이나 필요 이상의 것들을 가져오기에 사용자가 반드시 검토해서 활용하는 것이 필요하다고 생각하며, AI를 나만의 업무 비서 역할로 활용하여 협업하는 방식으로 활용하는 것을 추천드립니다 👍
테스트 자동화 환경 구성 중 문제 해결 역할
저는 Playwright 수행 서버를 동작하기 위해 Jenkins 환경이 필요해서 서버에 Jenkins 설치부터 운영까지 진행해 본 적이 있습니다.
Jenkins를 써보기만 했지 구축이나 파이프라인 코드 작성은 한 번도 해본 적이 없었는데, 이때도 AI를 활용해서 구축할 수 있었습니다.
서버에 환경 구성 시 필요한 설정은 어디서 다루는지, 오류 메시지가 출력되었을 때 어떻게 해결해야 하는지에 대한 의견을 AI를 통해 질의하면서 환경을 구축했습니다.

간단한 예시로 Jenkins Slack 알림 연동할 때 어떤 식으로 파이프라인을 구성해야 하는지 상세히 설명해 주기 때문에 설정에 문제가 있는 부분들은 빠르게 AI를 활용해서 해결하고, QA 업무에 더 집중할 수 있었습니다.
예전에는 오류 메시지를 구글에 검색해서 나와 유사한 사람의 질의를 확인하고 환경 구성을 했다면, 지금은 내 환경에 대한 문제를 확인하고 알려주기 때문에 구글링 했을 시절과는 큰 차이가 생겼죠! (라떼는..🥲)
그래서 AI 활용해서 테스트 서버 환경 구축이나 CI/CD 환경을 구성할 때 사전 지식이 부족해도 AI에게 많은 질의를 한다면 간단한 환경 구성은 금방 할 수 있었습니다 :)
업무에 필요한 기술조사, 자료를 모아달라!
예전에는 구글링을 통해서 새로운 기술에 대한 조사를 했다면, 요즘은 AI를 활용해서 기술조사를 하고 있습니다.
당연히 그냥 질의하고 답변해 준 내용을 다 맞다고 생각해서 조사하면 문제가 많을 수 있겠죠..?
그래서 프롬프트에 항상 근거 기반으로 참고자료도 함께 요청을 해달라고 하면서 질의를 하는 편입니다.

사람도 실수하는 것처럼 AI도 실수할 수 있다고 생각해서 가져온 자료들을 어디서 확인하고 가져온 것인지 알려달라고 하면, 설명 항목에 관련 링크도 함께 제공해주고 있습니다.
저는 1차적으로 AI의 응답 결과를 확인하고 제대로 확인해야 하는 부분들에 대해서는 참고 자료 링크를 직접 들어가서 내용을 확인하고 정보를 사용하는 방식으로 업무를 진행합니다.
상사가 기술조사에 대한 근거를 물었을 때 AI가 그렇게 말하던데요?_? 라고 할 순 없으니까요!
확실히 예전에는 직접 Docs 문서를 확인하고, 관련 자료를 수집하는데 오래 걸렸다면 요즘은 AI를 활용하여 손쉽게 정보를 가져올 수 있다고 생각합니다.
이외에도 IDE 툴에서 제공하는 코드 자동생성이나 Commit Message 자동 생성기능, 코드리뷰에도 사용하고 있으나, 많이 사용하고 계실 것 같아서 제외하였습니다.
그리고 MCP를 활용해서 자동화 스크립트도 구성해 봤지만 유지보수를 위한 코드 작성 방식, 이미 구성한 모델을 학습시키는 Rule을 적용하여 생성 요청을 해도 잘 안 되는 부분, 다른 사람과 협업할 때 더 어려워지는 부분 등 단점으로 보이는 부분이 있었기에 제외하였습니다.
그래도 AI는 계속 발전하고 있고 내년에는 더 새로운 기능들이 제 일자리를 압박할 수도 있을 것 같은데..
지지 않기 위해 잘 부려먹는 능력도 쌓아야 할 것 같습니다 :)
'QA > 업무 방식' 카테고리의 다른 글
| 테스트? 그냥 하면 되는거 아니야? STLC란? 무엇...? (4) | 2025.10.20 |
|---|---|
| SDLC(개발 방법론)와 활용 모델에서 QA는...? (2) | 2025.10.15 |
| 테스트 레벨 별 비정상 테스트 케이스 작성 방식 (매뉴얼 TC) (3) | 2025.08.24 |
| 테스트 레벨 별 네거티브 테스트케이스 작성 방식 (API TC) (3) | 2025.08.16 |
| TC(Test Case)는 어떤 기준으로 작성하나요? (4) | 2024.12.09 |