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 리포트는 거짓말 안 한다. 숫자가 한 주를 말해준다.

버그를 발견했을 때의 그 느낌 - 쾌감인가, 불안감인가?

버그를 발견했을 때의 그 느낌 - 쾌감인가, 불안감인가?

오늘도 버그 하나 오전 10시. 새 빌드 테스트 중이다. 로그인 플로우 확인하다가 이상한 걸 발견했다. SNS 로그인 후 프로필 사진 안 뜬다. 와이파이에선 되는데 LTE에선 안 된다. 가슴이 뛴다. 이거다. 버그다. 재현 한 번 더. 또 된다. 타이밍 문제는 아닌 거 같다. Charles Proxy 켜서 트래픽 캡처. API 타임아웃 3초인데 이미지 서버 응답이 4초. LTE는 느려서 걸리는 거다. 찾았다. Jira 켜고 이슈 작성 시작. 재현 스텝, 예상 결과, 실제 결과. 스크린샷 3장, 로그 파일, 네트워크 캡처. 우선순위 Medium. 심하면 High인데 일단은. 등록 버튼 누르는 순간. 묘한 쾌감이 온다.이상한 기분 버그 찾으면 기분이 좋다. 이게 정상인가 싶다. 회사 제품에 문제가 있다는 건데. 사용자가 불편하다는 건데. 개발자가 고쳐야 한다는 건데. 나는 기분이 좋다. 개발자한테 멘션 날렸다. "민호님, 이거 확인 부탁드려요." 10분 뒤 답장 온다. "아 이거 제가 놓쳤네요. 고맙습니다." 고맙다고? 내가 고맙다. 점심 먹으러 가면서 생각했다. 나는 왜 버그 찾으면 좋을까. 다른 사람들은 어떨까. 여자친구한테 물어봤다. "환자 증상 정확히 찾아내면 기분 어때?" "당연히 좋지. 그래야 치료하잖아." 맞다. 그거다.직업병이라는 거 주말에 배달 앱 쓰다가 버그 발견했다. 주소 입력란에 특수문자 넣으니까 앱이 뻗었다. "#" 하나 넣었을 뿐인데. 여자친구가 웃었다. "너 진짜 직업병이다." "이거 제보해야 하나?" "그냥 밥이나 먹어." 맞다. 직업병이다. 은행 앱도 그렇다. 뒤로가기 연타하면 이상한 화면 나온다. 게임도 그렇다. 엣지 케이스만 자꾸 시도한다. 정상적으로 쓰는 게 없다. 항상 꼬아서 본다. "이러면 어떻게 되지?" "여기서 저기로 바로 가면?" 버그 나오면 또 기분 좋다. "역시." "이건 놓쳤을 거야." 그런데 이게. 내 일이다.쾌감의 정체 왜 기분이 좋을까. 며칠 생각해봤다. 첫째, 내가 잘했다는 거. 버그 찾는 게 내 일이다. 못 찾으면 못하는 거다. 찾으면 잘하는 거다. 둘째, 사용자를 보호한 거. 내가 못 찾으면 사용자가 겪는다. 리뷰에 "버그 많아요" 뜬다. 평점 떨어진다. 내가 먼저 찾으면 막을 수 있다. 셋째, 제품이 좋아지는 거. 버그 하나 고칠 때마다. 앱이 조금씩 단단해진다. 다음 빌드는 더 나아진다. 넷째, 인정받는 거. "QA가 잘 잡아줘서 다행이에요." 이 말 들을 때. 내 일이 의미 있다고 느껴진다. 그러니까. 버그 찾으면 기분 좋은 게. 이상한 게 아니다. 의사가 병 진단하면 기분 좋은 거랑 같다. 정비사가 고장 찾으면 기분 좋은 거랑 같다. 내 일을 제대로 하고 있다는 증거다. 불안감도 있다 그런데 솔직히. 불안하기도 하다. 버그 찾으면 기분 좋은데. 못 찾으면 불안하다. 테스트 끝내고 리포트 쓸 때. "발견된 이슈 없음" 이렇게 쓰면. 진짜 없는 건가? 내가 못 찾은 건가? 배포 후가 제일 무섭다. CS 문의 들어올까 봐. "이런 버그 있어요." "QA는 뭐 했어요?" 그럴 때마다. 내가 놓친 거다. 내 책임이다. 작년에 있었다. 결제 페이지 버그. 특정 카드사에서만 오류 나는 거. 나는 다른 카드로만 테스트했다. 배포 후 문의 폭주. 핫픽스 긴급 배포. 팀장이 불렀다. "이거 왜 못 잡았어?" "테스트 케이스에 없었습니다." "그럼 만들었어야지." 맞는 말이다. 그날 밤 잠 못 잤다. 그래서 이제는. 버그 못 찾으면 더 불안하다. 찾으면 안심이다. 쾌감이면서. 동시에 안도감이다. 숫자로 보는 것 이번 달 통계 봤다. 내가 등록한 이슈 67건. 개발자가 수정한 거 58건. Invalid 처리 9건. 87% 정확도. 나쁘지 않다. 근데 놓친 게 몇 개일까. 배포 후 발견된 거 이번 달 3건. 내가 못 잡은 거다. 완벽할 순 없다. 알고 있다. 그래도 찝찝하다. 시니어 QA가 말했다. "버그 제로는 불가능해." "우리가 할 수 있는 건 리스크 최소화." "Critical 잡고, Major 잡고." "Minor는 우선순위에 따라." 맞다. 그래도 다 잡고 싶다. 욕심일까. 직업 의식일까. 둘 다인 거 같다. 다른 사람들은 QA 커뮤니티에 물어봤다. "버그 찾으면 기분 어때요?" 답글 20개 넘게 달렸다. "저도 기분 좋아요. 이상한가 했는데." "보물찾기 같은 느낌?" "개발자한테 미안하면서도 뿌듯해요." "못 찾으면 밤에 생각나요." 다들 비슷하다. 한 사람이 이렇게 썼다. "우리는 문제를 찾는 게 아니라." "해결의 시작점을 만드는 거예요." 와. 이 표현 좋다. 버그 찾는 게 끝이 아니다. 거기서부터 고치는 게 시작이다. 내가 안 찾으면. 아무도 모른다. 고칠 수도 없다. 내가 찾으면. 개발자가 고친다. 제품이 좋아진다. 사용자가 만족한다. 이 과정의 시작. 그게 내 역할이다. 그러니까. 기분 좋은 게 당연하다. 개발자와의 관계 가끔 개발자가 짜증 낸다. "또요? 이거 스펙이에요." "우선순위 낮은 거 아니에요?" 이해한다. 자기가 만든 걸 지적받는 거. 기분 안 좋을 수 있다. 그래도 나는 할 말 한다. "스펙 문서에는 이렇게 나와 있어요." "사용자 입장에서는 이상해요." 대부분은 인정한다. "아 맞네요. 고칠게요." "좋은 지적이에요." 친한 개발자는 이렇게 말했다. "민수 씨가 잡아줘서 다행이에요." "배포 전에 발견되는 게 최고죠." 맞다. 개발 중에 잡히는 게 제일 싸다. 배포 후는 비용이 10배다. 우리는 적이 아니다. 같은 팀이다. 목표는 하나. 좋은 제품 만들기. 내가 버그 찾는 건. 개발자 괴롭히려는 게 아니다. 같이 더 나은 걸 만들자는 거다. 그걸 아는 개발자랑은. 일하기 편하다. 모르는 사람이랑은. 힘들다. 성장의 증거 예전엔 못 찾던 거. 이제는 찾는다. 타이밍 이슈. 메모리 릭. 네트워크 오류 핸들링. 엣지 케이스. 경험이 쌓이면서. 보이는 게 많아진다. 2년 차 때는. 화면만 봤다. "버튼 안 눌려요." "화면 깨져요." 4년 차 지금은. 로그도 본다. 네트워크도 본다. 디바이스 스펙도 고려한다. "이 디바이스에서만 느린 이유가." "API 응답이 늦어서." "이미지 최적화 안 돼서." 원인까지 추정한다. 개발자가 놀란다. "어떻게 알았어요?" "로그 보면 나와요." 이럴 때. 내가 성장했다고 느낀다. 버그 찾는 게. 단순히 운이 아니라. 실력이라는 걸. 그래서 더 기분 좋다. 자동화와의 줄다리기 요즘 고민이다. 자동화 배워야 한다. 회사에서도 압박 온다. "수동 테스트만으로는 한계가 있어요." "자동화 스크립트 작성해보세요." 알고 있다. 시간이 없다. 매일 새 빌드 나온다. 테스트해야 할 케이스는 늘어난다. 리그레션만 해도 하루 종일이다. 자동화 배우는 건 야근 끝나고. 밤 11시부터. Appium 튜토리얼 보다가. 졸아서 포기. 주말에 스터디 가서. Python 기초부터. 배우는 건 재밌다. 스크립트 돌아가면 신기하다. 근데 두렵기도 하다. 자동화가 완성되면. 내 역할은 뭐가 되나. 시니어가 말했다. "자동화는 도구일 뿐이야." "사람이 생각하는 걸 대신 못 해." "엣지 케이스는 여전히 사람이 찾아." 맞는 말이다. 그래도 불안하다. 그래도 배워야 한다. 안 배우면 도태된다. 사용자를 만났을 때 작년에 사용자 인터뷰 참관했다. 5명 모셔서 앱 써보게 하는 거. 한 분이 말했다. "이 앱 진짜 안정적이에요." "다른 앱은 자꾸 꺼지는데." "이건 그런 거 없어요." 그 순간. 심장이 뛰었다. 내가 한 거다. 크래시 나는 거 다 잡았다. 배포 전에 다 테스트했다. 말은 안 했다. "저희 QA가 열심히 했습니다." 이렇게 말할 순 없다. 그냥 속으로만. 뿌듯했다. 다른 분은 이렇게 말했다. "버튼 위치가 좋아요." "누르기 편해요." 이것도. 내가 피드백 준 거다. "여기는 엄지 안 닿아요." "버튼 위치 조정 필요해요." 개발자가 수정했다. 사용자는 모른다. 그 과정을. 내 역할을. 그래도 괜찮다. 좋은 경험 주는 게 목표니까. 그게 내 일이니까. 앞으로도 버그는 계속 나올 거다. 완벽한 소프트웨어는 없다. 나는 계속 찾을 거다. 그게 내 일이니까. 찾으면 기분 좋을 거다. 이상한 게 아니라. 정상인 거다. 못 찾으면 불안할 거다. 그것도 정상이다. 책임감의 증거니까. 개발자랑 싸우기도 하고. 협력하기도 할 거다. 같은 목표 향해 가는 거니까. 자동화도 배울 거다. 천천히라도. 대체되지 않기 위해서가 아니라. 더 잘하기 위해서. 사용자는 모를 거다. 내가 뭘 했는지. 몇 개를 막았는지. 그래도 괜찮다. 앱이 잘 돌아가면. 그걸로 충분하다. 버그 찾는 쾌감. 그건 내 직업의 보상이다. 잘하고 있다는 신호다. 이상하지 않다. 자연스럽다. QA민수의 일상이다.오늘도 버그 3개 잡았다. 내일은 몇 개 나올까. 기대된다.

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 켜고 버그 찾는다. 네트워크는 거짓말 안 한다.

여자친구에게 설명할 수 없는 일상 - QA 엔지니어의 한숨

여자친구에게 설명할 수 없는 일상 - QA 엔지니어의 한숨

여자친구에게 설명할 수 없는 일상 - QA 엔지니어의 한숨 오늘 뭐 했어? 퇴근하고 여자친구 만났다. 항상 묻는 질문이 온다. "오늘 뭐 했어?" 나는 3초 멈춘다. 머릿속으로 돌아간다. 오늘 아침 9시부터 저녁 7시까지. 앱 빌드 20개 받았다. 테스트 케이스 147개 실행했다. 버그 8개 등록했다. 개발자랑 재현 영상 3번 주고받았다. 크래시 로그 10개 분석했다. 리그레션 테스트 2회차 돌렸다. "...일했지." 여자친구 표정이 묘해진다. "구체적으로?" 구체적으로. 이게 문제다.설명의 늪 "앱 테스트했어." "앱 만드는 거 아니었어?" "아니, 난 만드는 사람이 아니라..." 시작부터 꼬인다. "개발자가 만든 앱을 내가 확인하는 거야." "확인?" "버그 찾는 거지." "버그가 뭔데?" 숨을 크게 들이쉰다. "프로그램이 잘못 작동하는 거." "그럼 개발자가 잘못 만든 거네?" "...뭐 그렇게 볼 수도." "그럼 개발자가 고치면 되는 거 아냐?" 맞다. 논리적으로 맞다. 근데 내 직업을 부정당한 기분이다. "버그를 먼저 찾아야 고치지." "개발자가 자기가 만든 건 자기가 확인하면 되는 거 아니야?" 5초 침묵. 이 대화를 몇 번째 하는 건지 모르겠다.간호사는 다르다 여자친구는 간호사다. 그녀가 오늘 한 일을 말할 때는 다르다. "오늘 응급실 진짜 바빴어. 환자 10명 왔는데 2명은 중증이었어." 고개를 끄덕인다. 이해된다. "링거 꽂고, 활력징후 체크하고, 의사 선생님한테 보고하고..." 구체적이다. 명확하다. "한 환자분이 고마워요 하시는데 진짜 보람찼어." 감동적이기까지 하다. 내 차례가 온다. "나도 오늘 바빴어. 빌드 20개 받았거든." "빌드가 뭐야?" "...개발자가 만든 프로그램?" "하루에 20개를 만들어?" 설명이 길어진다. 빌드는 버전이고, 수정할 때마다 올라오고, 내가 확인해야 하고... 여자친구 눈빛이 흐려진다. "아 그래. 힘들었겠다." 공감이 아니다. 이해 포기의 눈빛이다. 버그 설명의 한계 어제 찾은 버그가 재밌었다. 누군가에게 말하고 싶었다. "어제 대박 버그 찾았어." 여자친구가 관심을 보인다. "어떤 거?" "로그인하고 프로필 들어가서 설정 누르고 알림 켜면 앱이 죽어." "...죽어?" "크래시. 꺼지는 거." "그럼 그냥 안 켜면 되는 거 아냐?" 논리적이다. 하지만 포인트를 놓쳤다. "사용자가 그렇게 생각하고 안 켜면 되는 게 아니라..." "왜?" "그냥 켜야 하는데 안 켜지면 문제잖아." "음..." 그녀는 고개를 끄덕인다. 이해한 게 아니라 대화를 끝내려는 끄덕임이다. 간호사 친구들 만나면 다르다고 한다. "오늘 중환자실에서 심정지 왔는데 5분 만에 소생시켰어!" "대박! 어떻게?" 직업의 드라마가 다르다. 내 드라마는 모니터 안에만 있다.야근의 의미 "오늘 야근해야 돼." "왜?" "배포 전이라서." "배포가 뭔데?" 또 시작이다. "앱스토어에 올리는 거." "그거 버튼 하나 누르면 되는 거 아냐?" "...그 전에 확인해야 하니까." "뭘 확인해?" "버그 있는지." "아직도 버그가 있어? 맨날 확인하는 거 아니었어?" 맞다. 맞는 말이다. 근데 설명할 수가 없다. 회귀 테스트, 스모크 테스트, 최종 검증. 이 단어들을 어떻게 설명하나. "그냥 마지막으로 한 번 더 보는 거야." "그럼 한 시간이면 되는 거 아냐?" "...3시간?" "왜 그렇게 오래 걸려?" 케이스가 많아서, 디바이스별로 봐야 해서, 네트워크 환경 바꿔가면서 봐야 해서. 말이 길어진다. 여자친구는 한숨을 쉰다. "알았어. 조심히 들어와." 조심히 들어와. 야근하는 사람한테 하는 말이 아니다. 밤길 조심하라는 말이다. 성취감의 차이 여자친구는 환자를 살린다. 나는 버그를 죽인다. 그녀는 "고맙습니다" 소리를 듣는다. 나는 "이거 버그 맞아요?" 소리를 듣는다. 그녀는 퇴근하면 뿌듯하다고 한다. 나는 퇴근하면 '내일 또 버그 나오면 어쩌지' 생각한다. "오늘 환자분이 퇴원하셨어. 일주일 전만 해도 많이 아프셨는데." 눈이 반짝인다. 보람이 보인다. "나도 오늘 치명적 버그 잡았어." "...그래?" "앱 결제할 때 두 번 결제되는 버그였어. 사용자들 돈 두 번 빠질 뻔했어." 잠깐 침묵. "그럼 그거 원래 만든 사람이 잘못한 거네?" "...응." "근데 넌 뭘 한 거야?" "발견한 거지." 발견. 그게 내 일이다. 근데 왜 이렇게 작게 들릴까. 연봉 이야기 친구들 만나면 연봉 얘기가 나온다. 여자친구 간호사 친구들도 온다. "저는 3년 차인데 야간 포함하면 4800 정도 받아요." "오 괜찮네요." 내 차례. "저는 4년 차고 4200이요." "어? 개발자 아니었어요?" "QA요." "...뭐 하는 건데요?" 여자친구가 대신 설명한다. "버그 찾는 거래요." "아~ 개발자 밑에서 일하는 거?" 밑이라는 표현. 틀린 말은 아닌데 기분이 묘하다. "같이 일하는 거죠." "그래도 개발자가 더 중요한 거 아니에요?" "...뭐." 여자친구가 내 손을 잡는다. 위로의 손길이다. 근데 위로받고 싶지 않다. 설명하고 싶다. 내 일의 중요성을. 말이 안 나온다. 직업의 무게 택시 타면 기사님이 묻는다. "무슨 일 하세요?" "IT 회사 다녀요." "아~ 개발자시구나. 요즘 잘 나가죠?" "...네." 개발자라고 말한다. 정정하기 귀찮다. 여자친구 부모님 만났을 때도 그랬다. "따님 남자친구 뭐 하는 사람이에요?" "IT 회사 다녀요." "요즘 IT가 대세죠. 연봉도 좋고." 여자친구 어머니 표정이 밝다. "정확히는 QA 엔지니어예요." "...큐에이?" "품질 관리요." "아~ 그래요." 표정이 살짝 어두워진다. 미묘한 변화다. 하지만 느껴진다. 여자친구가 나중에 말했다. "엄마가 개발자인 줄 아셨대." "그렇구나." "괜찮아. 뭐 하든 상관없어." 상관없다는 말. 위로 같지만 상처다. 이해받고 싶은 순간 배포 다음 날이었다. 새벽 3시까지 일했다. 아침에 출근했다. 모니터링한다. 크래시 리포트 확인한다. 0건. 가슴이 뛴다. 내가 잡은 버그들 덕분이다. 팀장님이 지나가면서 말한다. "어제 수고했어. 깔끔하게 배포됐네." 이 순간을 여자친구한테 말하고 싶었다. 저녁에 만났다. "어제 밤샘한 보람 있었어. 배포 완벽하게 됐어." "그래? 다행이다." "버그 하나도 안 나왔어." "원래 안 나와야 하는 거 아냐?" 숨이 막힌다. 맞다. 원래 안 나와야 한다. 근데 그게 당연한 게 아니라는 걸 어떻게 설명하나. "내가 미리 다 잡았으니까 안 나온 거야." "그럼 잘한 거네." "응." 잘한 거네. 끝이다. 더 이상 할 말이 없다. 간호사는 다르다. "오늘 응급 처치 완벽하게 해서 환자분 살렸어." "대단해!" 개발자도 다르다. "오늘 알고리즘 최적화해서 속도 30% 빨라졌어." "와 천재 아냐?" QA는? "버그 안 나왔어." "...원래 안 나와야 하는 거 아냐?" 자동화 공부 요즘 자동화 공부한다. Selenium, Appium 독학 중이다. 여자친구한테 말했다. "나 요즘 자동화 공부해." "자동화? 뭐가?" "테스트 자동화. 내가 손으로 하던 걸 프로그램이 하게." "그럼 네 일을 없애는 거네?" 뜨끔. "그게 아니라 더 효율적으로..." "그럼 나중에 너 자리 없어지는 거 아냐?" 말문이 막힌다. 맞을 수도 있다. 하지만 안 배우면 도태된다. "배워야 살아남아." "힘들겠다." 힘들겠다는 말. 공감이지만 해결책은 아니다. 간호사는 면허가 있다. 개발자는 코드가 있다. QA는 뭐가 있나. 경력? 4년 차 경력이 과연 무기가 될까. 잠이 안 온다. 그래도 어제 여자친구가 물었다. "너 왜 그 일 해?" 3초 생각했다. "재밌어서." "뭐가 재밌어?" "버그 찾는 게." 진심이었다. 엣지 케이스 생각하는 거. 아무도 생각 못 한 시나리오 찾는 거. 크리티컬 버그 잡았을 때 그 쾌감. "이상한 사람이네." 이상한 사람. 인정한다. 일반 사용자들은 앱 쓰면서 버그 만나면 짜증 낸다. 나는 버그 보면 신난다. "어떻게 재현되지?" "어떤 조건에서 터지지?" 이게 내 직업병이고 특기다. 설명할 순 없어도 나는 안다. 내 일이 중요하다는 걸. 평행선 여자친구와 나는 평행선이다. 그녀는 사람을 살린다. 나는 서비스를 살린다. 그녀는 환자를 본다. 나는 버그를 본다. 그녀는 감사받는다. 나는 당연시된다. 하지만 둘 다 필요한 일이다. 언젠가 여자친구가 말했다. "네가 하는 일 완벽히 이해는 못 하지만, 네가 열심히 하는 건 알아." 그거면 된다. 완벽한 이해는 바라지 않는다. 같은 업계 사람도 QA를 오해한다. 다만 인정. 내가 하는 일이 의미 있다는 것. 그것만 있으면 된다. 마무리 오늘도 여자친구가 물을 것이다. "오늘 뭐 했어?" 나는 또 3초 멈출 것이다. 그리고 말할 것이다. "일했지." 구체적으로 설명할 순 없다. 하지만 열심히 했다. 그거면 된다. 사랑하는 사람이 내 일을 이해 못 해도 괜찮다. 나는 안다. 내 일의 가치를. 버그 없는 세상. 그게 내가 만드는 세상이다. 보이지 않아도 중요하다.설명 못 해도 계속한다. 이게 내 일이니까.

모니터링 중 발견한 버그 vs 사용자가 먼저 발견한 버그

모니터링 중 발견한 버그 vs 사용자가 먼저 발견한 버그

모니터링 중 발견한 버그 vs 사용자가 먼저 발견한 버그 배포 후 30분 배포가 끝났다. 오후 2시. 개발자들은 점심 먹으러 갔다. 나는 모니터 3개 앞에 앉아 있다. 왼쪽 모니터: 실서버 로그 중앙 모니터: 앱스토어 리뷰 오른쪽 모니터: 고객센터 문의 심장이 빨리 뛴다. 배포 후 한 시간이 가장 무섭다.새로고침을 누른다. 로그에 에러가 없다. 다시 누른다. 여전히 없다. 5분마다 새로고침. 괜찮은가 보다. 그런데 불안하다. 배포 후 1시간까지는 내가 먼저 찾아야 한다. 그게 QA의 자존심이다. 내가 먼저 발견했을 때 오후 2시 40분. 로그에 이상한 게 보였다. "결제 API 타임아웃 20건." 앱을 켰다. 결제 화면으로 들어갔다. 로딩이 조금 길다. 다시 시도. 또 길다. 세 번째. "오류가 발생했습니다." 찾았다. 재현 스텝을 정리했다.앱 실행 상품 선택 결제 버튼 클릭 3초 후 타임아웃스크린샷 3장. 로그 캡처. Charles Proxy 패킷 덤프. Jira에 티켓을 등록했다. 제목: [긴급] 결제 API 타임아웃 발생 우선순위: Critical 담당자: 백엔드 팀장 슬랙에 메시지를 보냈다. "@channel 결제 장애 확인. 티켓 확인 부탁드립니다." 10분 후 회신이 왔다. "확인했습니다. 서버 스케일업 중." 30분 후 해결됐다. "민수님 덕분에 빨리 잡았네요." 이럴 때 기분이 좋다. 사용자가 모르게 해결했다. 이게 진짜 QA다.사용자가 먼저 발견했을 때 최악의 시나리오. 오후 3시. 아직 점심 안 먹었다. 모니터링 중이었다. 슬랙 알림이 울렸다. 고객센터 채널이다. "결제가 안 된다는 문의 들어왔어요." "저도 방금 받았습니다." "저도요. 3건." 심장이 멎었다. 앱을 켰다. 결제를 시도했다. 에러가 났다. 로그를 확인했다. 30분 전부터 에러가 쌓여 있었다. 왜 못 봤지. 로그 필터를 잘못 걸었나. 아니다. 그냥 못 본 거다. Jira에 티켓을 급하게 올렸다. 슬랙에 메시지를 보냈다. "@channel 결제 장애 발생. 사용자 리포트 들어왔습니다." 분위기가 다르다. "언제부터였어요?" "30분 전부터요." "왜 이제 알렸어요?" 할 말이 없다. 백엔드 개발자가 말했다. "모니터링 뭐 하고 있었어요?" QA 팀장이 들어왔다. "민수씨, 잠깐 얘기 좀." 1시간 후 해결됐다. 하지만 기분이 다르다. 앱스토어 리뷰에 별 1개가 3개 달렸다. "업데이트 후 결제 안 됨" "환불해주세요" "테스트 안 하나요?" 마지막 리뷰가 제일 아프다.30분의 차이 똑같은 버그다. 똑같은 심각도다. 똑같은 해결 시간이다. 하지만 평가가 다르다. 내가 먼저 발견: "민수님 덕분에" 사용자가 먼저: "모니터링 뭐 했어?" 30분 차이다. 억울하다고 생각했다. 같은 버그인데 왜. 근데 맞는 말이다. 사용자가 겪기 전에 막는 게 QA다. 죄책감의 무게 사용자가 먼저 발견한 버그는 무겁다. 테스트는 완벽하게 했다. 배포 전 체크리스트 다 통과했다. 리그레션 테스트도 했다. 그런데 나왔다. 누구 잘못일까. 개발자는 말한다. "테스트 환경에선 안 그랬는데." 기획자는 말한다. "스펙대로 만들었는데." 디자이너는 말한다. "디자인은 문제없는데." 그럼 QA 잘못인가. 명확한 답은 없다. 하지만 사용자는 생각한다. "테스트 안 하나?" 그 한 줄이 제일 아프다. 모니터링의 압박 배포 후 모니터링은 전쟁이다. 새로고침을 200번 넘게 누른다. 에러 로그를 실시간으로 본다. 앱스토어 리뷰를 5분마다 확인한다. 점심도 못 먹는다. 화장실도 빨리 다녀온다. 왜 이렇게까지 하냐고. 30분 차이 때문이다. 내가 먼저 발견하면 영웅. 사용자가 먼저 발견하면 무능. 극단적이다. 알고 있다. 하지만 현실이 그렇다. 완벽한 배포는 없다 4년 차 QA다. 배포를 100번 넘게 했다. 완벽한 배포는 한 번도 없었다. 크고 작은 버그가 항상 나온다. 테스트 환경과 실서버는 다르다. 사용자 패턴은 예측 불가다. 그래서 모니터링이 중요하다. 내가 먼저 발견하는 게 최선이다. 사용자보다 1분이라도 빨리. 사용자 리포트의 무게 고객센터에서 버그 리포트가 올라오면. 그날은 집에 가도 찝찝하다. 샤워하면서도 생각난다. "내가 뭘 놓쳤지?" 자기 전에 테스트 케이스를 다시 본다. 어디서 놓쳤는지 찾는다. 대부분은 찾지 못한다. 엣지 케이스였거나. 실서버 환경 이슈였거나. 타이밍 이슈였거나. "이건 못 찾을 수밖에 없었어." 스스로 위로한다. 근데 별로 위로가 안 된다. 다음 배포 다음 배포 때는 더 꼼꼼히 본다. 체크리스트를 늘린다. 모니터링 시간을 늘린다. 새로고침 주기를 줄인다. 그래도 버그는 나온다. 완벽은 없다. 하지만 계속 노력한다. 내가 먼저 발견하기 위해서. QA의 자존심 사용자보다 먼저 버그를 찾는 것. 이게 QA의 자존심이다. 개발자에게 물어봤다. "QA 왜 필요한 것 같아요?" "버그 찾아주니까요." 반만 맞다. 사용자보다 먼저 찾아주니까다. 오늘의 배포 오늘도 배포가 있다. 오후 2시. 점심은 간단히 먹었다. 모니터 앞에 앉았다. 새로고침 준비 완료. 이번엔 내가 먼저 찾을 거다.30분 먼저 발견하는 게 QA의 일이다.