Test

• 26 Dec, 2025
• • 테스트

회귀 테스트(Regression Test) - 내 일의 대부분이 이거다

회귀 테스트, 내 업무의 70% 오늘도 회귀 테스트다. 새 기능 하나 추가됐다. "소셜 로그인 카카오 추가"래. 그래서 뭐? 기존 이메일 로그인도 테스트해야 한다. 네이버 로그인도. 애플 로그인도. 로그아웃도. 자동 로그인도. 개발자가 말한다. "로그인 쪽 코드는 안 건드렸는데요?" 믿을 수 없다. 지난주에도 똑같은 말 들었다. 결제 모듈 수정했는데 장바구니가 깨졌었다. "안 건드렸다"는 말은 "모르겠다"랑 같은 말이다.회귀 테스트. Regression Test. 새 기능 때문에 기존 기능이 깨지는 걸 찾는 작업. 내 업무 시간의 70%가 이거다. 테스트 케이스 850개. 한 번 다 돌리면 3일 걸린다. 매번 다 할 수는 없다. 그래서 우선순위를 정한다. Critical 케이스 200개는 무조건. 로그인, 결제, 회원가입. 이거 깨지면 서비스 마비다. High 케이스 350개는 선택적으로. 이번 수정이랑 관련 있는 것 위주로. Medium 이하는 대충 샘플링. 시간 있으면 한다. 없으면 못 한다. 오늘의 참사 오전 10시. 빌드 받았다. 테스트 시작했다. 카카오 로그인 잘 된다. 좋아. 그런데 기존 이메일 로그인이 이상하다. 비밀번호 찾기 버튼 눌렀는데 화면이 안 뜬다. 뒤로가기도 안 된다. 앱이 멈춘다. 버그 등록했다. [BUG-2847] 이메일 로그인 > 비밀번호 찾기 화면 응답 없음. 재현 스텝 적었다:앱 실행 이메일 로그인 선택 '비밀번호를 잊으셨나요?' 클릭 화면 멈춤스크린샷 3장 첨부. 로그 파일 첨부. 디바이스 정보 적었다. 개발자한테 슬랙 날렸다. "민우님, BUG-2847 확인 부탁드려요." 답장 왔다. "제 폰에선 잘 되는데요?"여기서부터가 지옥이다. 내 폰 버전: Android 13, 갤럭시 S22 개발자 폰: Android 14, 갤럭시 S23 버전 차이일 수 있다. 다른 폰으로 해봤다. Android 12. 똑같이 멈춘다. 개발자 자리로 갔다. 내 폰 보여줬다. 재현했다. 화면 멈췄다. "아..." 개발자 얼굴이 굳었다. "네비게이션 스택 문제네요. 카카오 로그인 추가하면서 라우팅 로직 바꿨는데..." 그러니까 안 건드렸다는 게 아니었다. 간접적으로 건드린 거다. 이게 회귀 테스트의 본질이다. A를 고쳤는데 B가 깨진다. 코드는 다 연결돼 있다. 효율성 문제 오후 3시. 팀장이 물었다. "민수야, 회귀 테스트 언제까지 걸려?" "850개 케이스 다 하면 3일이요." "배포가 내일 모레인데?" "그럼 Critical이랑 High만 하면 1.5일?" "내일 오전까지 안 돼?" 불가능하다. 물리적으로 불가능하다. 결국 타협했다. Critical 200개만 오늘 안에. High는 내일 오전까지. Medium 이하는 포기. 이게 현실이다. 완벽한 회귀 테스트는 없다. 시간과 리소스는 한정돼 있다.그래서 전략이 필요하다. Risk-Based Testing 위험도 높은 것부터 한다. 결제 관련은 무조건 1순위 회원 데이터 관련 2순위 UI 깨짐은 나중에이번 수정이 로그인이면 로그인 주변을 집중적으로. Impact Analysis 개발자한테 물어본다. "이번에 어느 파일 수정했어요?" 로그인 모듈이면 로그인 관련 케이스 집중. API 레이어면 모든 네트워크 요청 체크. UI 컴포넌트면 해당 화면들 위주로. 개발자가 정확히 말 안 해주면 답이 없다. "그냥 여기저기요"라고 하면 끝이다. 전부 다 해야 한다. Test Case 우선순위화 엑셀에 정리해뒀다.ID Feature Priority Last Failed Execution TimeTC-001 로그인 Critical 2주 전 2분TC-002 결제 Critical 1주 전 5분Last Failed가 최근인 것부터 한다. 자주 깨지는 케이스가 또 깨질 확률이 높다. 자동화의 필요성 저녁 8시. Critical 200개 끝났다. 손목이 아프다. 클릭만 3000번 한 것 같다. 자동화해야 한다. 알고 있다. 다들 안다. 회사에 Appium 있다. Selenium도 있다. 아무도 안 쓴다. 이유가 있다. 시간이 없다 자동화 스크립트 짜려면 시간이 필요하다. 한 케이스당 1시간씩 잡아도 850시간. 6개월 풀로 매달려야 한다. 그 시간에 수동 테스트를 해야 한다. 배포는 매주 있다. 유지보수 비용 UI가 바뀌면 스크립트도 바뀌어야 한다. ID 하나 바뀌면 테스트 10개가 깨진다. 그럼 고치는 데 또 시간 쓴다. 차라리 수동으로 하는 게 빠를 때가 있다. 전문성 부족 나는 코딩을 잘 못한다. Python 기초는 안다. Appium 예제 따라는 할 수 있다. 근데 복잡한 시나리오는 못 짠다. 동적 요소 처리, 타이밍 이슈, 예외 처리. 어렵다. 개발자한테 부탁하면 "바빠요"라고 한다. 당연하다. 본인 일도 바쁜데. 그래도 해야 한다. 지금 상태로는 확장이 안 된다. 케이스는 계속 늘어난다. 나는 하나다. 자동화 시작 이번 주부터 시작했다. 매일 1시간씩 자동화 스크립트 짠다. 퇴근 전에. 우선 Critical 케이스부터. 로그인, 로그아웃, 결제. 이 20개만 자동화해도 2시간이 절약된다. Appium 튜토리얼 봤다. 첫 스크립트 짰다. # 로그인 테스트 driver.find_element(By.ID, "email_input").send_keys("test@test.com") driver.find_element(By.ID, "password_input").send_keys("test1234") driver.find_element(By.ID, "login_button").click()실행했다. 실패했다. ID가 안 맞는다. 개발자가 바꿨나 보다. 개발자한테 슬랙 날렸다. "ID 좀 고정으로 해주세요. 테스트 자동화 때문에." 답 왔다. "넵, 다음 빌드부터 적용할게요." 작은 진전이다. 자동화는 하루아침에 안 된다. 조금씩 쌓아야 한다. 회귀 테스트의 딜레마 밤 11시. 집 도착. 오늘 회귀 테스트에서 버그 8개 찾았다. 새 기능 테스트에서 찾은 건 3개. 회귀에서 찾은 게 더 많다. 이게 현실이다. 새 기능보다 기존 기능이 더 자주 깨진다. 그런데 회귀 테스트는 눈에 안 띈다. "민수는 오늘 뭐 했어?" "회귀 테스트요." "결과는?" "이상 없었어요." 이상 없으면 한 일이 없는 것처럼 보인다. 버그 안 찾으면 "일 안 한 거 아냐?" 찾으면 "QA가 늦게 찾아서 일정 밀렸다." 억울하다. 버그 안 나온 건 내가 잘 테스트해서가 아니다. 운이 좋았거나, 버그가 원래 없었거나. 내 공은 아니다. 버그 나온 건 내가 놓친 게 아니다. 케이스가 850개인데 200개밖에 못 했다. 시간이 없었다. 그래도 한다. 해야 한다. 내일도 회귀 내일도 회귀 테스트다. High 케이스 350개. 아침 9시부터 시작해서 내일 오후까지. 개발자가 오늘 수정한 버그들도 다시 체크해야 한다. Regression on regression. 점심시간 30분. 커피 한 잔. 클릭 클릭 클릭. 손목 아프다. 눈 아프다. 같은 화면 100번 본다. 그래도 이게 내 일이다. 품질을 지키는 일. 회귀 테스트 없으면 서비스는 망한다. 새 기능 하나 추가하고 기존 기능 열 개 깨지는 앱. 쓸 사람 없다. 자동화 조금씩 한다. 우선순위 정리 계속한다. 개발자랑 협업 개선한다. 언젠가는 나아질 거다. 아마도.회귀 테스트, 끝이 없다. 그래도 해야 한다.