Showing Posts From

테스트

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

회귀 테스트(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번 본다. 그래도 이게 내 일이다. 품질을 지키는 일. 회귀 테스트 없으면 서비스는 망한다. 새 기능 하나 추가하고 기존 기능 열 개 깨지는 앱. 쓸 사람 없다. 자동화 조금씩 한다. 우선순위 정리 계속한다. 개발자랑 협업 개선한다. 언젠가는 나아질 거다. 아마도.회귀 테스트, 끝이 없다. 그래도 해야 한다.

재현 스텝이 없는 버그 리포트는 범죄다

재현 스텝이 없는 버그 리포트는 범죄다

아침 9시 30분, 슬랙 알림 출근했다. 커피 뽑았다. 슬랙 켰다. "@민수님 버그요! 앱 안 돼요 ㅠㅠ" 심장이 철렁했다. 배포한 지 이틀째다. 메시지 클릭했다. 내용 전부다. "앱 안 돼요 ㅠㅠ" 뭐가 안 되는데? 어디서? 언제? 어떻게? 답장 쳤다. "어떤 기능에서 문제가 발생했나요? 재현 스텝 부탁드립니다." 10분 후. "로그인이요." 아... 진짜. 로그인이 뭐가 안 된다는 건지. 버튼이 안 눌리는 건지, 에러가 뜨는 건지, 앱이 꺼지는 건지. "구체적으로 어떤 증상인가요? 스크린샷 있으실까요?" 30분 지나도 답 없다. 테스트 못한다. 버그 재현 못하면 리포트 못 올린다. 개발자한테 뭐라고 전달하나. 점심시간 되어서야 답장 왔다. "아 제 폰에선 이제 되네요." 되네요가 아니라.재현 스텝 없는 리포트는 쓰레기다 냉정하게 말한다. 재현 스텝 없는 버그 리포트는 쓰레기통 직행이다. 4년 차 하면서 깨달은 거. QA의 핵심은 버그를 찾는 게 아니다. 버그를 전달하는 거다. 버그를 찾았어도 개발자가 재현 못 하면 소용없다. "제 PC에선 안 그러는데요?" 듣고 끝이다. 실제로 있었던 일이다. 지난달에 결제 버그 발견했다. 특정 상품에서 할인이 안 먹혔다. 처음엔 나도 당황했다. 어? 왜 안 되지? 근데 차근차근 해봤다.앱 실행 로그인 (테스트 계정: test001) 홈 > 카테고리 > '전자제품' 상품 A 선택 (상품코드: ELEC-1234) 수량 2개 선택 장바구니 담기 결제하기 클릭 할인 쿠폰 적용 (쿠폰코드: SALE20) 결제 금액 확인→ 기대값: 20% 할인 적용 (19,200원) → 실제값: 할인 미적용 (24,000원) 이렇게 정리해서 Jira에 올렸다. 디바이스 정보도 넣었다. 갤럭시 S23, Android 14, 앱 버전 2.4.1. 스크린샷 3장. 영상도 첨부했다. 개발자가 30분 만에 재현했다. 1시간 만에 수정했다. 이게 정상이다. 근데 보통은? "결제가 이상해요" 이런 식이다. 뭐가 이상한데.정보 없으면 시간만 버린다 재현 스텝 없는 리포트 받으면 뭐가 문제냐. 시간 낭비다. 실제로 계산해봤다. 불완전한 버그 리포트 하나당 평균 2시간 쓴다.리포터한테 추가 정보 요청: 30분 답변 기다리기: 1시간 재현 시도: 30분2시간이면 테스트 케이스 20개는 돌린다. 한 달에 이런 리포트 10개만 받아도 20시간이다. 20시간이면 2.5일이다. 일주일에 반나절씩 날리는 거다. 더 큰 문제는 타이밍이다. 버그 리포트가 늦게 완성되면 픽스도 늦어진다. 배포 일정 밀린다. 그럼 누구 책임이냐. QA다. "QA가 제대로 확인 안 했네" 소리 듣는다. 억울하다. 정보를 안 줬는데 어떻게 확인하나. 지난주에 PM이 물었다. "이 버그 심각도 어떻게 돼요?" 모른다. 재현도 못 했는데 심각도를 어떻게 매기나. 결국 개발 회의 때 "확인 중입니다" 했다. 다음 날 PM이 또 물었다. "아직도 확인 중이에요?" 짜증 났다. 정보 없으면 확인할 수가 없다고. 최소한의 정보 5가지 정리했다. 버그 리포트에 꼭 들어가야 할 정보. 1. 재현 스텝 가장 중요하다. 1단계부터 끝까지. "앱 켜고 → 로그인하고 → 설정 들어가고 → 알림 토글 끄면 → 앱 꺼짐" 이 정도는 되어야 한다. "설정에서 문제 생김" 이건 안 된다. 2. 기대 결과 vs 실제 결과 뭐가 나와야 하는데 뭐가 나왔는지. "저장 완료 팝업 떠야 하는데 → 에러 메시지 뜸" 명확하다. "저장이 안 됨" 이건 애매하다. 무슨 의미인지 모른다. 3. 환경 정보 디바이스, OS 버전, 앱 버전. 갤럭시냐 아이폰이냐에 따라 다르다. Android 12냐 14냐에 따라 다르다. "폰에서요" 이러면 곤란하다. 4. 계정 정보 테스트 계정이 뭔지. 어떤 권한인지. 일반 회원이냐 프리미엄 회원이냐. 로그인 상태냐 비로그인이냐. 차이가 크다. 5. 재현 빈도 항상 되는지, 가끔 되는지. "10번 중 10번" vs "10번 중 1번" 심각도 판단에 중요하다. 이 5가지만 있어도 80%는 해결된다.실제 사례: 좋은 리포트 vs 나쁜 리포트 비교해본다. 나쁜 리포트 사례: "제목: 앱 오류 내용: 앱에서 오류 나요. 확인 부탁드립니다." 이게 끝이다. 뭘 확인하라는 건지. 어디서 오류가 났는지. 어떤 오류인지. 개발자한테 이거 전달했다가 욕먹는다. 좋은 리포트 사례: "제목: [결제] 포인트 사용 시 최종 금액 계산 오류 재현 스텝:앱 실행 후 로그인 (테스트 계정: test_user_01, 보유 포인트: 5,000P) 홈 화면 > 추천 상품 섹션 진입 '무선 이어폰' 상품 선택 (상품번호: PROD-9876, 가격: 89,000원) '구매하기' 버튼 클릭 결제 화면에서 '포인트 사용' 체크박스 선택 사용할 포인트 입력: 5,000P '결제하기' 버튼 클릭기대 결과:최종 결제 금액: 84,000원 (89,000원 - 5,000P) 결제 완료 후 보유 포인트: 0P실제 결과:최종 결제 금액: 89,000원 (포인트 차감 안 됨) 결제 완료 후 보유 포인트: 5,000P (그대로 유지)환경:디바이스: iPhone 14 Pro OS: iOS 17.1.2 앱 버전: 3.2.1 (빌드 #245) 네트워크: WiFi재현 빈도:5회 시도 중 5회 동일 증상 발생추가 정보:스크린샷 첨부 (결제 화면, 완료 화면) 영상 첨부 (재현 과정 30초) 로그 파일: payment_error_20250114.log"차이가 보이나. 두 번째 리포트는 그대로 개발자한테 넘긴다. 추가 질문 없다. 첫 번째 리포트는 30분 동안 추가 정보 뽑아내야 한다. 버그 리포트 템플릿 만들었다 귀찮아서 템플릿 만들었다. Jira에 커스텀 필드로 박아뒀다. ## 재현 스텝 1. 2. 3. ## 기대 결과## 실제 결과## 환경 정보 - 디바이스: - OS 버전: - 앱 버전: - 계정:## 재현 빈도 [ ] 항상 (10/10) [ ] 자주 (7~9/10) [ ] 가끔 (3~6/10) [ ] 드물게 (1~2/10)## 첨부 - [ ] 스크린샷 - [ ] 영상 - [ ] 로그이거 공유했다. 팀 전체에. 처음엔 귀찮아했다. "너무 복잡한 거 아니냐"고. 근데 2주 지나니까 다들 쓴다. 이유는 간단하다. 버그 처리 속도가 2배 빨라졌다. 예전엔 버그 하나당 평균 2일 걸렸다. 지금은 1일 안에 끝난다. 개발자들도 좋아한다. "이제 뭔지 알겠다"고. PM도 만족한다. 진척도 파악이 쉽다고. 그래도 안 쓰는 사람들 문제는 외부다. 고객센터에서 올라오는 버그 리포트. CS팀 통해서 오는 거. 여전히 "앱이 이상해요" 수준이다. CS팀 탓은 아니다. 고객이 그렇게 말하니까. 그래서 CS팀이랑 미팅했다. "고객한테 이렇게 물어봐 주세요" 했다.어떤 화면에서 문제가 생겼나요? 어떤 버튼을 눌렀나요? 화면에 뭐라고 떴나요? 스크린샷 찍어주실 수 있나요?CS팀장이 고개 끄덕였다. "그럼 스크립트 만들어주시면 좋겠어요." 만들었다. A4 한 장짜리. "버그 접수 시 체크리스트" CS팀 모니터에 붙여놨다. 효과 있었다. 고객 리포트 질이 올라갔다. 완벽하진 않아도 전보다 낫다. 개발자도 마찬가지다 거꾸로 생각해봤다. 개발자가 나한테 "이거 테스트 부탁해요" 할 때. 가끔 정보가 없다. "로그인 수정했어요. 테스트 부탁드려요." 뭘 수정했는데? 물어본다. "어떤 부분 수정하셨어요?" "코드 리팩토링이요." 그래서 뭐가 바뀐 건데. "기능은 똑같은데 내부 로직만 바꿨어요." 그럼 테스트 범위가 다르잖아. 리팩토링이면 리그레션 테스트다. 기존 기능 전부 확인해야 한다. 새 기능 추가면 신규 기능만 집중 테스트하면 된다. 정보 없으면 테스트 계획 못 세운다. 그래서 개발팀이랑도 약속했다. "테스트 요청할 때 이거 써주세요." ## 변경 사항 - 무엇을 수정했나요? - 왜 수정했나요?## 테스트 범위 - 어느 부분 테스트하면 되나요? - 연관 기능은 뭐가 있나요?## 주의사항 - 특별히 확인해야 할 케이스가 있나요?지금은 잘 지켜진다. 서로 편하다. 왜 안 쓰는 걸까 생각해봤다. 왜 사람들은 재현 스텝을 안 쓸까. 이유 1: 귀찮다 솔직히 귀찮다. 1~10까지 쓰는 게. "대충 말하면 알아서 하겠지" 생각한다. 근데 그게 더 오래 걸린다. 이유 2: 중요성을 모른다 "버그 있다"고만 하면 된다고 생각한다. 재현 스텝이 왜 필요한지 모른다. 교육이 필요하다. 이유 3: 시간이 없다 급하다. 빨리 올려야 한다. 근데 불완전한 리포트는 결국 더 느리다. 이유 4: 방법을 모른다 뭘 써야 할지 모른다. 템플릿 주면 해결된다. 내가 하는 방식 나는 이렇게 한다. 버그 발견하면 바로 메모한다. 폰 메모장에. 실시간으로. "1. 앱 켬 2. 로그인 3. 설정 4. 알림 5. 토글 끔 6. 앱 꺼짐" 짧게. 나중에 정리하려면 기억 안 난다. 그리고 녹화한다. iOS는 화면 녹화 기본 기능 쓴다. Android는 AZ Screen Recorder 쓴다. 영상 있으면 스텝 빠뜨릴 일 없다. 스크린샷도 찍는다. 문제 발생한 순간. 로그도 뽑는다. Android는 adb logcat. iOS는 Xcode Console. 이 모든 게 5분이면 된다. 그리고 Jira에 정리한다. 10분. 총 15분이면 완벽한 버그 리포트 완성된다. 이게 습관이 되면 자동이다. 재현 안 되는 버그도 있다 현실적으로 말한다. 재현이 안 되는 버그도 있다. 간헐적 버그. 타이밍 이슈. 네트워크 지연. 이런 건 스텝 써도 재현이 안 된다. 그럼 어떻게 하나. 최대한 정보를 모은다.언제 발생했나? (정확한 시각) 몇 번 시도 중 몇 번 발생했나? 발생 직전에 뭐 했나? 네트워크 상태는? (WiFi/LTE/5G) 다른 앱 켜져 있었나?패턴을 찾는다. "WiFi에선 안 되고 LTE에선 됐다" "백그라운드에서 돌아왔을 때만 그렇다" "특정 계정에서만 발생한다" 이런 정보가 힌트가 된다. 개발자가 원인 찾는 데 도움 된다. 재현 안 돼도 포기하면 안 된다. 버그 리포트는 커뮤니케이션이다 깨달은 게 있다. 버그 리포트는 단순한 기록이 아니다. 커뮤니케이션이다. 나와 개발자 사이의. 명확하게 전달해야 명확하게 해결된다. 애매하게 말하면 애매하게 처리된다. "앱이 느려요" → 개발자: "제 폰에선 빠른데요?" "홈 화면 로딩 시간이 3초 → 5초로 늘었어요 (이전 버전 대비)" → 개발자: "확인하겠습니다" 차이가 크다. QA는 통역가다. 사용자의 불편함을 개발자가 이해할 수 있는 언어로 바꿔주는 거. 재현 스텝은 그 언어의 문법이다. 품질은 디테일에서 나온다 결국 품질이다. 앱 품질은 버그를 얼마나 빨리 정확하게 고치느냐에 달렸다. 정확하게 고치려면 정확하게 전달해야 한다. 재현 스텝은 그 시작이다. "대충" 하면 결과도 "대충"이다. 꼼꼼하게 하면 결과도 탄탄하다. 사용자는 모른다. 뒤에서 얼마나 꼼꼼하게 했는지. 그냥 "앱 잘 되네" 하고 쓴다. 그게 우리 일이다. 보이지 않는 곳에서 디테일 챙기는 거. 마지막으로 재현 스텝 없는 버그 리포트는 범죄다. 과장 아니다. 시간 낭비, 품질 저하, 팀 스트레스. 모두의 발목 잡는다. 템플릿 만들어라. 5분이면 된다. 습관 들여라. 2주면 자동이다. 공유해라. 팀 전체가 같은 언어 쓰게. 그럼 달라진다. 배포가 편해진다. 버그가 줄어든다. 팀워크가 좋아진다. 나도 처음엔 귀찮았다. 지금은? 이게 없으면 일 못 한다.재현 스텝은 선택이 아니다. 필수다.

TestRail 리포트를 보며 한 주를 반추한다

TestRail 리포트를 보며 한 주를 반추한다

주말 저녁의 루틴 일요일 저녁 8시. 노트북을 켰다. TestRail 대시보드가 뜬다. 습관이다. 다른 사람들은 주말에 이런 거 안 본다. 나도 안 보려고 했다. 근데 월요일 아침이 불안하다. 그래서 일요일 밤에 본다. 이번 주 테스트 실행 횟수: 347건. Pass: 289건. Fail: 41건. Blocked: 17건. 숫자를 보면 한 주가 정리된다. 뭘 했는지 기억난다.월요일: 새 빌드의 시작 월요일 아침 9시. 새 빌드가 올라왔다. v2.3.5 → v2.3.6. 릴리즈 노트에 'Bug fixes'라고만 적혀 있다. 뭘 고쳤는지 물어봤다. "로그인 이슈요." 그게 다였다. 테스트 케이스 35개를 돌렸다. 로그인 관련 15개, 연관 기능 20개. 4시간 걸렸다. Pass 32건. Fail 3건. 로그인은 고쳐졌는데 프로필 이미지가 안 뜬다. 새 버그다. Jira 티켓을 만들었다. 재현 스텝 8단계. 스크린샷 4장. 로그 첨부. 개발자한테 슬랙 보냈다. "확인했습니다." 답장은 30분 후. TestRail에 결과 입력했다. 월요일 실행 건수: 35건. Pass율 91%. 나쁘지 않다. 화요일: 리그레션의 늪 화요일은 리그레션 테스트 날이다. 매주 화요일. 루틴이다. 전체 케이스 120개를 돌린다. 결제, 검색, 알림, 설정, 전부. 하루 종일 걸린다. 오전에 60개 끝냈다. 점심 먹고 오니까 빌드가 또 올라왔다. v2.3.7. "프로필 이슈 핫픽스요." 처음부터 다시. 60개 날아갔다. 오후 2시부터 다시 시작. 5시에 80개 끝냈다. 남은 40개는 야근. 8시 반에 마무리. TestRail에 결과 입력하면서 눈이 풀렸다. 화요일 실행 건수: 120건. Pass율 94%. Fail 7건은 전부 Known Issue. 재테스트 필요 없다. 집에 가는 지하철에서 TestRail 모바일로 한 번 더 봤다. 숫자 확인이 안심된다.수요일: 애매한 버그들 수요일 오전. 신기능 테스트. '추천 알고리즘 개선'이라는데 뭐가 개선됐는지 모르겠다. 기획서를 다시 읽었다. "사용자 행동 기반 맞춤 추천" 구체적 기준이 없다. PM한테 물어봤다. "어느 정도까지가 정상인가요?" "음... 합리적이면 되죠." 합리적. 참 좋은 단어다. 테스트 케이스에 못 쓴다. 일단 엣지 케이스를 생각했다.신규 유저는? 데이터 없는 유저는? 탈퇴 후 재가입은? 추천 거부한 유저는?20가지 시나리오를 만들었다. 하나하나 테스트했다. 신규 유저한테 추천이 안 뜬다. 버그인가? 스펙인가? 개발자한테 물었다. "데이터가 없으면 기본 추천이 나와야 하는데." 버그다. Jira 등록. Medium 우선순위. "이거 꼭 고쳐야 해요?" 기획자가 물었다. "신규 유저 온보딩에 영향 줍니다." "그럼 High로 올릴게요." TestRail에 Fail 체크. 수요일 실행 건수: 78건. Pass율 87%. 애매한 버그가 제일 힘들다. 목요일: 개발자와의 대화 목요일 오전. 개발자가 왔다. "어제 올린 버그요." "네." "재현이 안 되는데요." 시작됐다. 내 폰을 보여줬다. "여기서 이렇게 하면..." 버그가 재현됐다. "아, 제 폰에선 안 그랬는데." 당연하다. 환경이 다르다. 같이 30분 테스트했다. 조건을 찾았다. "로그인 → 로그아웃 → 재로그인 하면 나오네요." "이거 엣지 케이스 아닌가요?" 개발자가 말했다. "MAU 30만 중 10%는 이렇게 씁니다." 데이터를 보여줬다. "알겠습니다." 수정하기로 했다. 오후에 커피 마시면서 또 불렀다. "이 케이스도 봐주실래요?" 같이 테스트했다. 1시간 걸렸다. TestRail에 Note 필드를 채웠다. "재현 조건: 로그아웃 후 재로그인 상태" 다음 테스터가 볼 수 있게. 목요일 실행 건수: 52건. Pass율 96%. 개발자랑 같이 하면 Pass율이 오른다.금요일: 배포 전 긴장 금요일. 배포 예정일. 오전 10시 배포 회의. "이번 주 버그 현황 공유해주세요." 내 차례다. TestRail 리포트를 공유했다. "총 347건 실행. Pass율 92%." "Open 버그 5건. Critical 0건. High 2건." "배포 가능한가요?" CTO가 물었다. High 2건을 설명했다. "하나는 신규 유저 이슈. 영향 범위 작음." "다른 하나는 특정 디바이스 이슈. iOS 14.2 이하." "iOS 14.2 사용자 비율은?" "2.3%입니다." "배포 진행하죠." 결정됐다. 오후 3시. 배포 시작. TestRail에서 최종 체크리스트를 봤다. Smoke Test 25건. 하나씩 실행했다. 로그인. 회원가입. 결제. 푸시. 딥링크. 전부 Pass. 5시. 배포 완료. "수고하셨습니다." 슬랙 메시지. 집에 가는 길. 마음 한편이 불안하다. 주말에 장애 알림 올까? 주말: 숫자로 보는 한 주 일요일 저녁. 다시 TestRail. 한 주 리포트를 뽑았다.항목 수치총 실행 347건Pass 289건 (83%)Fail 41건 (12%)Blocked 17건 (5%)발견 버그 23건수정 완료 18건테스트 시간 약 32시간Pass율 83%. 지난주보다 2% 떨어졌다. Fail 41건을 하나씩 봤다.15건: 수정 완료 후 Pass 12건: Known Issue 8건: Blocked (개발 미완) 6건: 다음 주 재테스트6건이 신경 쓰인다. 월요일에 제일 먼저 할 일. 발견한 버그 23건. Jira에서 상태 확인했다.Resolved: 18건 In Progress: 3건 To Do: 2건To Do 2건이 마음에 걸린다. 우선순위가 낮아서 밀린 거다. 언젠가 터질 폭탄. 다음 주 계획 TestRail에 다음 주 테스트 플랜을 만들었다. "Week 23 Test Plan" 우선순위를 정했다.이번 주 Fail 6건 재테스트 신기능 'AI 채팅' 테스트 iOS 17 대응 확인 정기 리그레션AI 채팅이 걱정이다. 스펙이 계속 바뀐다. 테스트 케이스를 못 만들었다. 월요일 아침에 기획자 붙잡아야겠다. "정확한 스펙 주세요." 매번 하는 말. TestRail에 Draft 케이스를 만들었다. 일단 30개. 월요일에 리뷰 받고 추가할 것. 마음 한편 TestRail 리포트를 보면 한 주가 정리된다. 숫자로 보이니까 안심된다. 근데 동시에 불안하다. 내가 놓친 게 있을까? 배포된 앱에 숨은 버그가 있을까? 지난주에 장애가 하나 있었다. 결제 오류. 내가 테스트한 케이스였다. "Pass 했는데 왜 터졌어요?" 팀장이 물었다. "테스트 환경이랑 달랐습니다." 변명처럼 들렸다. 그 뒤로 테스트 케이스를 더 추가했다. 환경 변수 체크 항목. 네트워크 상태별 시나리오. Pass율이 떨어진 이유다. 케이스가 늘어나면 Fail도 늘어난다. 근데 그게 맞다. 더 많이 찾는 게 내 일이다. 숫자 너머 TestRail 숫자가 전부는 아니다. Pass 289건 뒤에는 사용자가 있다. 매끄럽게 로그인하는 사람. 오류 없이 결제하는 사람. 앱 켜자마자 크래시 안 나는 사람. 그게 내가 한 일이다. 숫자로는 안 보인다. 개발자는 기능을 만든다. 나는 기능이 깨지지 않게 지킨다. 화려하지 않다. 누가 칭찬하지도 않는다. "QA 덕분에 앱이 안정적이에요" 같은 말은 안 들린다. 대신 욕은 들린다. "버그가 왜 이렇게 많아?" 발견했으니까 많은 거다. 찾지 않으면 사용자가 찾는다. 리뷰에 별점 1점으로. 월요일 아침을 위해 일요일 밤 10시. TestRail 탭을 닫았다. 다음 주 체크리스트를 노트에 적었다. Fail 6건 재테스트 AI 채팅 스펙 확인 iOS 17 디바이스 세팅 리그레션 플랜 업데이트내일 아침 9시에 출근하면 바로 시작할 수 있다. 미리 정리해두면 월요일이 덜 힘들다. 노트북을 덮었다. 주말이 끝난다. 근데 마음은 편하다. 준비됐으니까.TestRail 리포트는 거짓말 안 한다. 숫자가 한 주를 말해준다.

Charles Proxy로 네트워크 버그 잡는 방법 - 초보자 가이드

Charles Proxy로 네트워크 버그 잡는 방법 - 초보자 가이드

Charles Proxy로 네트워크 버그 잡는 방법 - 초보자 가이드 Charles 처음 깔았을 때 2년 전이다. 선배가 말했다. "민수야, 이거 깔아. 네트워크 보면 버그 금방 찾아." Charles Proxy. 처음 들어봤다. 깔았다. 실행했다. 암호 같은 화면이다. 뭐가 뭔지 모르겠다. 그냥 껐다. 그때 몰랐다. 이게 내 무기가 될 줄.선배가 옆에서 보여줬다. 앱 실행하니까 Charles에 뭔가 주르륵 뜬다. "봐, 이게 다 네트워크 통신이야." 신기했다. 앱이 서버랑 뭘 주고받는지 보인다. 근데 SSL이라고 자물쇠 그림만 보인다. "이건 어떻게 봐요?" "인증서 설치해야지." 그날 3시간 걸렸다. 인증서 설치. iOS는 더 복잡했다. 프로필 신뢰, 인증서 신뢰. 두 번 해야 한다. 몰랐다. 처음 잡은 네트워크 버그 한 달 뒤였다. 결제 화면에서 "결제 실패" 팝업이 뜬다. 근데 결제는 됐다. 이상하다. 개발자한테 물었다. "로그 좀 보내줄래요?" "제 폰에선 재현이 안 되는데요." 또 시작이다. Charles 켰다. 앱 실행했다. 결제 버튼 눌렀다. 실패 팝업 떴다. Charles 봤다. POST /api/payment - 200 OK GET /api/payment/result - 504 Gateway Timeout 찾았다. 결제는 성공했다. 근데 결과 조회가 타임아웃이다. 앱은 결과 못 받아서 실패로 처리한 거다.스크린샷 찍었다. 지라에 올렸다. "결제 API는 성공, 결과 조회 API가 504" 개발자가 답했다. "아, 서버 타임아웃 설정이 짧았네요." 버그 수정됐다. 그때부터다. Charles 없으면 불안하다. SSL Proxying 설정의 함정 초보 때 자주 헤맸다. SSL Proxying Settings 메뉴. 처음엔 *:443 하나만 넣었다. 안 보이는 도메인이 많았다. 왜지? 찾아봤다. 443 포트만 캐치한다. 8443 같은 건 안 잡힌다. 그래서 지금은 이렇게 한다. : - 전부 다 근데 이것도 문제다. 필요 없는 것까지 다 잡는다. 로그가 너무 많다. 찾기 힘들다. 그래서 요즘은 도메인 지정한다. api.회사도메인.com:* 이렇게. 깔끔하다. 우리 API만 보인다. Breakpoints 기능 이거 알고 나서 세상이 바뀌었다. Breakpoints는 통신을 멈춘다. Request를 수정할 수 있다. Response도 바꿀 수 있다. 예를 들어. 사용자 정보 API가 있다. GET /api/user/profile Response는 이렇다: { "name": "홍길동", "grade": "VIP", "point": 5000 }궁금했다. grade가 "VVIP"면 어떻게 보일까? point가 음수면? 이름이 100자면?Breakpoint 설정했다. 통신이 멈췄다. Response 수정했다. grade를 "VVVVVVVIP"로 바꿨다. Execute 눌렀다. 앱 화면이 깨졌다. UI가 삐져나왔다. 버그 찾았다. 긴 텍스트 처리 안 돼 있다. 티켓 올렸다. 재현 스텝에 스크린샷 첨부했다. "Charles로 Response 조작해서 확인" 개발자가 물었다. "이거 어떻게 한 거예요?" 알려줬다. 고마워했다. Map Local로 서버 없이 테스트 배포 전날이었다. 서버가 죽었다. 점검 중이다. 근데 테스트는 해야 한다. Map Local 기능 썼다. 로컬 파일로 Response를 대체한다. 순서는 이렇다.원하는 API 우클릭 Map Local 선택 JSON 파일 경로 지정서버 없어도 테스트 가능하다. 꿀팁이다. 에러 상황도 테스트했다. error.json 파일 만들었다: { "error": "SERVER_ERROR", "message": "서버 오류입니다" }Map Local로 연결했다. 앱이 에러 처리를 제대로 하는지 확인했다. 개발자는 몰랐다. "서버 없는데 어떻게 테스트했어요?" 비법 알려줬다. Throttle Settings로 느린 네트워크 테스트 가장 많이 쓰는 기능이다. Proxy 메뉴 → Throttle Settings 여기서 네트워크 속도를 조절한다. 3G로 설정했다. 앱이 느려졌다. 로딩이 오래 걸린다. 이때 버그가 나온다.로딩 화면 없이 멈춘 것처럼 보임 중복 클릭으로 API 두 번 호출 타임아웃 처리 안 됨지하철에서 쓰는 사용자 생각했다. 느린 네트워크는 현실이다. Throttle 없이는 못 찾는다. QA가 사무실 와이파이로만 테스트하면 놓친다. 요즘은 배포 전에 꼭 한다. Throttle 켜고 전체 시나리오 한 번 더. Repeat 기능으로 부하 테스트 동시 접속 버그 있었다. 같은 API를 빠르게 여러 번 호출하면 에러. 재현하기 어려웠다. 손으로 빠르게 클릭? 불가능하다. Charles의 Repeat 기능 썼다. API 우클릭 → Repeat Advanced 설정했다. Iterations: 10번 Concurrency: 5개 동시 실행했다. 서버가 500 에러 뱉었다. 개발자 불렀다. "이것 좀 보세요." 재현 성공했다. 동시성 처리 안 돼 있었다. 트랜잭션 락 문제였다. 수정했다. 다시 Repeat 돌렸다. 이번엔 괜찮았다. Recording Settings 정리 처음엔 Recording이 계속 켜져 있었다. 브라우저 켜면 크롬 통신도 다 잡힌다. 찾기 힘들다. Recording Settings에서 조절한다. Include에 넣는다:우리 API 도메인 테스트할 도메인Exclude에 넣는다:광고 도메인 분석 도메인 (Google Analytics 등) OS 업데이트 체크깔끔해졌다. 필요한 것만 보인다. Rewrite 기능 활용 Map Local보다 간단할 때 쓴다. 특정 값만 바꾸고 싶을 때. 예시: 서버가 주는 버전 정보가 있다. { "min_version": "1.0.0" }이걸 "9.9.9"로 바꾸고 싶다. Rewrite 설정한다. Type: Modify Body Where: Response Match: min_version": "1.0.0" Replace: min_version": "9.9.9" 실행했다. 앱이 "업데이트 필요" 팝업 띄웠다. 버전 체크 로직 확인 완료. No Caching 설정 캐싱 때문에 헷갈릴 때 많다. API 수정됐는데 앱이 옛날 데이터 보여준다. Tools 메뉴 → No Caching 체크했다. Cache-Control 헤더를 조작한다. 캐시를 무효화한다. 테스트할 때 필수다. 안 그러면 "어? 왜 안 바뀌지?" 한다. 실전 팁 모음 2년 쓰면서 배운 것들. 필터 활용 Structure 탭 위에 Filter 있다. 도메인 일부만 입력해도 된다. "api" 치면 api 들어간 것만 보인다. 차트 보기 Session Overview 탭. Timeline 그래프 있다. 어느 API가 느린지 한눈에 보인다. Export 기능 Session → Export API 호출 내역을 파일로 저장한다. 개발자한테 전달할 때 쓴다. Compose 기능 API를 직접 호출한다. Postman 없어도 된다. Request 우클릭 → Compose Focus 기능 특정 도메인만 집중해서 볼 때. 우클릭 → Focus 나머지는 흐려진다. Charles 없는 QA는 상상 못 한다 지금은 출근하면 Charles부터 킨다. 습관이다. 버그 잡는 속도가 다르다. "왜 안 돼요?" 대신 "이 API가 500 에러입니다" 말한다. 개발자도 좋아한다. 재현 스텝이 명확하다. 고치기 쉽다. 신입이 들어오면 제일 먼저 알려준다. Charles 설치부터 시작한다. 처음엔 어려워한다. 나도 그랬다. 근데 한 번 맛보면 빠진다. 보이지 않던 게 보인다. 앱이 서버랑 뭘 주고받는지. 어디서 터지는지. QA한테 Charles는 X-Ray다.오늘도 Charles 켜고 버그 찾는다. 네트워크는 거짓말 안 한다.