스펙이에요, 버그예요? - QA의 영원한 의문

스펙이에요, 버그예요? - QA의 영원한 의문

스펙이에요, 버그예요? - QA의 영원한 의문 오늘도 똑같은 질문 출근했다. 커피 마시고 어제 빌드 확인. 로그인 화면에서 이메일 입력창이 있다. 근데 띄어쓰기가 들어간다. test @gmail.com 이런 식으로. 당연히 로그인 안 된다. 버그다. Jira 티켓 올리려고 했다. 근데 생각이 든다. '이거 원래 막아야 하는 거 맞나?' 스펙 문서 찾아봤다. 이메일 유효성 검사 항목이 있다. 근데 띄어쓰기에 대한 언급은 없다. 개발자한테 물어봤다. "이거 띄어쓰기 들어가는데요." "아, 그거요? 스펙에 없어서 안 막았는데요." 그렇다. 시작됐다.스펙이 명확하지 않을 때 이메일 띄어쓰기 건으로 기획자한테 물었다. "이메일에 띄어쓰기 들어가도 되나요?" "어? 그건 당연히 막아야죠." "스펙에는 없는데요." "그 정도는 당연한 거 아닌가요?" 당연한 게 어디 있나. 개발자는 스펙에 없으면 안 만든다. 기획자는 당연한 건 안 쓴다. QA는 그 사이에서 '이게 버그인지 스펙인지' 판단해야 한다. 티켓을 올렸다. 'Critical' 등급으로. 개발자가 댓글 달았다. "이거 스펙 추가 아닌가요? 원래 구현 범위 아닌데." 기획자도 댓글 달았다. "이건 기본적인 유효성 검사인데요." 나는 그 사이에서 우선순위 협의 중이다. 결국 회의가 잡혔다. 30분짜리. 결론: 버그로 등록, 다음 스프린트에서 수정. 회의 시간 30분. 구현 시간 10분. 효율적이다.'당연한 것'의 함정 QA 4년 하면서 배운 게 있다. '당연한 것'은 없다. 비밀번호 입력창에서 복사 붙여넣기가 된다. 보안상 막아야 할까? 누군 막아야 한다고 하고, 누군 편의성이라고 한다. 결제 버튼을 두 번 누르면 두 번 결제된다. 버그다. 근데 스펙에는 '중복 결제 방지' 항목이 없다. "그 정도는 당연히 막아야죠." 당연하면 스펙에 쓰든가. 검색창에서 특수문자 입력하면 앱이 죽는다. 버그 티켓 올렸다. 개발자: "서버에서 필터링하는 거 아닌가요?" 서버 개발자: "클라이언트에서 먼저 걸러주는 거 아닌가요?" 기획자: "둘 다 해야 하는 거 아닌가요?" 나: "누가 하든 일단 고쳐주세요." 결국 또 회의다. 이런 일이 하루에 세 번씩 일어난다. 스펙 문서의 현실 우리 회사 스펙 문서는 Confluence에 있다. 작성자: 기획자 최종 수정일: 2개월 전 실제 구현: 3주 전 일치율: 70% 나머지 30%는 QA가 찾아낸다. "이거 스펙이랑 다른데요?" "아, 그거 개발하면서 바꿨어요. 문서는 아직 안 고쳤네요." 그러면 나는 뭘 기준으로 테스트하나. 스펙 문서인가, 실제 구현인가, 기획자 말인가, 개발자 말인가. 정답: 전부 다 봐야 한다. 스펙 읽고, 실제 앱 써보고, 기획자한테 물어보고, 개발자한테 확인받고, 그래도 애매하면 유사 기능 참고하고, 경쟁사 앱 확인하고. 그렇게 판단한다. '이건 버그다' 또는 '이건 스펙 누락이다'애매한 경계선 가장 어려운 건 UX/UI 관련이다. 버튼을 눌렀을 때 반응 속도가 느리다. 0.8초 걸린다. 버그인가? 스펙인가? 스펙에는 "즉시 반응" 이라고만 쓰여 있다. 0.8초는 즉시인가? 기획자는 "좀 느린 것 같은데요" 한다. 개발자는 "서버 응답 기다려야 해서 어쩔 수 없어요" 한다. 나는 티켓을 올린다. "UX 개선" 등급으로. 우선순위: Low 결과: 3개월째 백로그에 있다. 또 다른 예시. 팝업 닫기 버튼이 왼쪽 위에 있다. 근데 다른 화면들은 전부 오른쪽 위다. 일관성 문제다. 버그인가? "이 화면만 디자인이 달라요." "의도된 건가요?" "글쎄요. 디자이너한테 물어볼게요." 디자이너: "어? 그거 실수인데요. 오른쪽으로 바꿔주세요." 실수였다. 그럼 버그다. 근데 이미 2주 전에 배포됐다. 아무도 신고 안 했다. 그래도 고쳐야 한다. 일관성은 중요하니까. 회색지대 판단법 4년 하면서 나름의 기준이 생겼다. 1. 사용자 관점 사용자가 이상하다고 느낄까? 느낀다 → 버그 가능성 높음 안 느낀다 → 우선순위 낮음 2. 일관성 다른 화면/기능과 다른가? 다르다 → 버그 또는 스펙 누락 같다 → 의도된 것일 수 있음 3. 비즈니스 영향 이게 돈/사용자에 영향을 주나? 준다 → Critical 안 준다 → Low 4. 재현율 항상 발생하나? 항상 → 버그 가끔 → 환경 이슈 가능성 5. 경쟁사 비교 다른 앱들은 어떻게 하나? 대부분 막음 → 우리도 막아야 할 듯 제각각 → 정답 없음 이 기준으로 판단한다. 그래도 애매하면 티켓 올리고 우선순위는 팀에서 정하게 한다. 내가 전부 판단할 순 없으니까. 개발자와의 대화 "이거 버그 같은데요." "스펙에 없는데요." "그래도 이상하지 않아요?" "스펙에 추가해주시면 해드릴게요." 이 대화를 일주일에 다섯 번은 한다. 개발자 입장도 이해한다. 스펙에 없는 걸 왜 만들어야 하나. 그건 추가 작업이니까. 하지만 QA 입장에서는 답답하다. 상식적으로 이상한 걸 왜 놔두나. 결국 기획자 불러서 스펙 추가한다. 개발자: "스펙 추가됐으니 다음 스프린트에 할게요." 나: "이번에 못 해요? Critical인데." 개발자: "이번 스프린트 이미 꽉 찼어요." 나: "배포 후에 사용자가 발견하면 어떡해요?" 개발자: "그럼 핫픽스 하죠." 핫픽스는 내가 밤새서 테스트한다. 미리 고치는 게 낫지 않나. 이 논리가 안 먹힌다. 일정이 우선이니까. 기획자와의 대화 "이거 스펙에 없는데요." "당연한 거 아닌가요?" "당연한 게 어딨어요. 명시해주세요." "그럼 스펙 문서가 너무 길어지는데요." 길어지면 어때. 명확한 게 중요하지. 기획자는 큰 그림을 그린다. 세부사항은 '알아서' 하는 거라고 생각한다. 하지만 개발은 명시된 것만 만든다. 그 사이 갭을 QA가 메운다. "이 경우는 어떻게 해요?" "이 경우는 안 쓰여 있는데요." "에러 메시지는 뭘로 해요?" "로딩 시간이 길면 어떻게 해요?" 전부 물어봐야 한다. 안 물어보면 나중에 버그가 된다. 실제 사례: 로그인 타임아웃 최근에 겪은 일이다. 로그인 API 타임아웃이 30초로 설정됐다. 스펙에는 "로그인 실패 시 에러 메시지 표시" 라고만 있다. 30초 동안 로딩만 돈다. 아무 메시지도 없다. 사용자는 앱이 죽은 줄 안다. 버그 티켓 올렸다. 개발자: "타임아웃은 서버 설정이에요. 클라이언트는 응답 기다리는 거고요." 나: "30초는 너무 긴데요. 사용자가 기다릴까요?" 개발자: "서버팀한테 말해보세요." 서버 개발자: "30초는 표준이에요. 네트워크 느릴 수 있으니까." 나: "그럼 중간에 로딩 메시지라도 보여주면 안 될까요?" 기획자: "좋은 생각이네요. 스펙에 추가할게요." 2주 후 적용됐다. "로그인 중입니다... 잠시만 기다려주세요." 이게 없었으면 사용자는 앱 끄고 재설치했을 거다. 이런 게 스펙에 없었다. 당연하지 않았나? 당연하지 않다. 누군가 생각하고 제안해야 한다. 그게 QA 일이다. 버그 vs 스펙 판단 기준표 내가 만든 체크리스트다. 명확한 버그:앱이 죽음 데이터 유실 보안 문제 스펙 문서와 다름 이전 버전에서 됐는데 안 됨스펙 누락:엣지 케이스 미처리 에러 케이스 없음 일관성 문제 UX 불편함 경쟁사는 다 하는데 우리만 안 함애매한 영역:성능 (얼마나 빨라야 빠른가?) 디자인 (얼마나 예뻐야 예쁜가?) 편의성 (꼭 필요한가?) 우선순위 낮은 버그애매한 건 팀 논의로 간다. 혼자 판단하려 하지 않는다. 책임 분산도 중요하니까. QA가 해야 할 일 명확하지 않은 요구사항이 오면 QA가 해야 할 일: 1. 재현 가능한지 확인 이게 항상 발생하나? 특정 조건에서만 발생하나? 재현 스텝을 명확히 한다. 2. 스펙 문서 확인 문서에 뭐라고 나와 있나? 없으면 유사 기능 찾는다. 3. 기획자에게 질문 "이 경우는 어떻게 의도하신 건가요?" 예/아니오로 답할 수 있게 구체적으로 묻는다. 4. 개발자에게 확인 "기술적으로 가능한가요? 얼마나 걸리나요?" 일정과 난이도를 파악한다. 5. 우선순위 제안 Critical / High / Medium / Low 비즈니스 영향과 사용자 경험을 고려해서 제안한다. 6. 티켓 등록 재현 스텝, 스크린샷, 로그, 기대 동작, 실제 동작 명확하게 쓴다. 추가 질문 없게. 이게 루틴이다. 하루에 이런 판단을 10번은 한다. 스펙 명확화 요청 요즘은 아예 스펙 리뷰를 미리 한다. 기획 단계에서 QA도 참여한다. "이 경우는요?" "저 경우는요?" "에러는요?" "로딩은요?" 처음엔 기획자가 귀찮아했다. "그건 개발하면서 정하면 되죠." 안 된다. 개발하면서 정하면 전부 버그가 된다. 지금은 기획자도 인정한다. "QA 리뷰 안 거치면 나중에 티켓 폭탄 맞아요." 맞다. 미리 물어보는 게 서로 편하다. 스펙이 명확하면 개발도 빠르고, 테스트도 명확하고, 버그도 줄어든다. Win-win이다. 판단의 책임 가끔 생각한다. 내가 '이건 버그 아니에요' 라고 판단했는데, 배포 후에 사용자가 불편해하면? 내가 '이건 Critical이에요' 라고 했는데, 실제론 아무도 신경 안 쓰면? 판단의 책임이 무겁다. 틀릴 수도 있다. 나도 사람이니까. 그래서 중요한 건 기록이다. "기획자에게 확인했으나 스펙 외라고 판단" "개발팀과 논의 후 우선순위 Low로 조정" "사용자 시나리오상 발생 가능성 낮음" 근거를 남긴다. 나중에 문제되면 그때 다시 논의한다. 완벽한 판단은 없다. 최선의 판단만 있을 뿐. 개발자가 이해하는 날 신기한 경험을 했다. 개발자가 먼저 물어봤다. "민수님, 이거 어떻게 생각하세요? 버그 같긴 한데 스펙에는 없거든요." 오. 개발자도 이제 안다. 스펙에 없다고 다 아닌 건 아니라는 걸. "그거 버그 맞죠. 사용자 불편할 것 같은데요." "그쳤죠? 제가 미리 고쳐놨어요. 다음 빌드에 들어가요." 감동이다. 4년 만에 개발자가 먼저 버그를 판단했다. 협업의 승리다. 서로 이해하는 데 4년 걸렸다. 기획자가 변하는 날 최근 기획서를 받았다. 놀랐다. 엣지 케이스가 전부 적혀 있다. "입력값이 100자 초과 시 에러 메시지: '100자 이내로 입력해주세요'" "네트워크 끊김 시: 재시도 버튼 표시" "로딩 3초 이상 시: 로딩 메시지 변경" 완벽하다. 기획자한테 물었다. "갑자기 왜 이렇게 자세히 쓰셨어요?" "매번 민수님이 물어보시잖아요. 미리 쓰는 게 빠르더라고요." 그렇다. 협업은 서로 배우는 거다. 나도 배웠고, 팀도 배웠다. 이제 '스펙이에요 버그예요?' 질문이 조금 줄었다. 조금만. 여전히 애매한 것들 그래도 여전히 애매한 게 있다. "이 애니메이션 자연스러워요?" 자연스러움은 주관이다. "이 색깔 괜찮아요?" 색깔은 취향이다. "이 문구 이상하지 않아요?" 어감은 사람마다 다르다. 이런 건 여러 명이 봐야 한다. 디자이너, 기획자, 개발자, QA 전부 의견 내고, 최종 결정은 PM이 한다. 그래도 배포 후에 누군가는 불만이다. 완벽한 제품은 없다. 최선을 다할 뿐. 배포 후 발견되는 것들 조심스럽게 배포했다. 테스트 다 했다. 2주 후 고객센터에서 연락 왔다. "OO 상황에서 앱이 이상하게 동작한다는 문의가 들어왔어요." 재현해봤다. 진짜다. 버그다. 근데 테스트 때는 안 나왔다. OO 상황이 테스트 시나리오에 없었다. 스펙에도 없었다. 기획자도 생각 못 했다. 사용자는 우리가 생각 못 한 방식으로 쓴다. 그게 현실이다. 핫픽스 들어갔다. 밤샘했다. 이럴 때마다 생각한다. '내가 놓쳤나?' 아니다. 우리 모두 놓쳤다. 함께 놓친 건 함께 책임진다. 그게 팀이다. 4년 차 QA의 결론 '스펙이에요 버그예요?' 이 질문은 앞으로도 계속될 거다. 명확한 답이 없는 경우가 많으니까. 하지만 4년 하면서 배운 건: 판단은 혼자 하는 게 아니다. 기획자, 개발자, 디자이너, PM 모두 함께 판단한다. QA는 그 과정을 촉진하는 사람이다. 질문하고, 확인하고, 기록하고, 제안한다. 틀릴 수도 있다. 괜찮다. 다시 논의하면 된다. 완벽한 스펙은 없다. 스펙은 계속 보완된다. 개발하면서, 테스트하면서, 출시하면서. 그 과정에서 QA가 많은 걸 발견한다. 사용자 관점이 답이다. 애매하면 사용자 입장에서 생각한다. 불편한가? 이상한가? 위험한가? 그게 기준이다. 오늘도 질문한다. "이거 스펙인가요, 버그인가요?" 대답은 회의실에서 나온다. 그게 QA의 일상이다.내일도 누군가는 물을 거다. "이거 버그 맞죠?" 나는 대답할 거다. "회의 잡을게요."

Jira 티켓 200개, 어디부터 시작해야 할까?

Jira 티켓 200개, 어디부터 시작해야 할까?

월요일 아침의 선물 출근했다. Jira 열었다. 미해결 티켓 203개. 금요일에 180개였는데. 주말 사이 23개가 더 생겼다. 핫픽스 배포했다가 새 버그가 나온 거다. 예상했다. 커피 한 잔 마시고 화면을 봤다. P1, P2, P3, P4가 뒤섞여 있다. 어떤 건 상태가 "재확인 필요", 어떤 건 "개발 완료 대기". 정리 안 된 티켓이 반은 넘는다. 팀장이 슬랙 보냈다. "민수야, 이번 주 목표 티켓 30개 처리. 가능하지?" 30개. 하루에 6개씩이다. 재현 시간, 확인 시간, 리포트 작성 빼면 불가능하다. 하지만 "네" 라고 답장했다. 어차피 할 거니까.우선순위라는 이름의 정치 P1부터 봤다. 41개다. 심각도 높음, 긴급 처리. 그런데 진짜 긴급한 건 10개도 안 된다. 나머지는 누군가 급하다고 우긴 것들이다. "로그인 안 됨" - P1 맞다. "프로필 이미지 안 뜸" - P2인데 기획자가 P1 박았다. "특정 기종에서 폰트 이상" - P3이다. 근데 대표님 폰이라서 P1. 우선순위는 기술적 판단이 아니다. 정치다. 개발팀장은 자기 팀 버그는 P3로 낮추고 싶어 한다. 기획팀은 자기가 만든 기능 버그는 P1로 올리고 싶어 한다. 영업팀은 클라이언트가 말한 건 뭐든 P1이다. 결국 내가 판단해야 한다. 실제 사용자 영향도로. 기준을 만들었다. 엑셀에 정리했다. P1 (10개)앱 크래시 핵심 기능 동작 안 함 데이터 손실 가능성 보안 이슈P2 (35개)주요 기능 오작동 특정 기종 크래시 UI 심각하게 깨짐 결제 관련 오류P3 (98개)부가 기능 오류 텍스트 오타 디자인 의도와 다름 특정 상황에서만 재현P4 (60개)개선 제안 극히 드문 케이스 차기 버전 고려 스펙 논의 필요재분류했다. 기획자한테 메신저 왔다. "민수님, 제가 P1 올린 건데요?" "사용자 영향도 낮아서 P2로 조정했습니다." "근데 팀장님이 중요하다고 하셨거든요." "팀장님께 제가 말씀드릴게요." 이런 대화를 5번 했다. 점심 전에.현실적인 처리 계획 10개 P1부터 시작했다. 하지만 순서가 있다. 재현 가능한 것부터다. "특정 조건에서 크래시" - 재현 스텝 불명확. 개발자한테 물어봐야 함. 나중. "로그인 실패" - 바로 재현 가능. 지금. "결제 오류" - QA 서버에서 테스트 가능. 지금. 엑셀에 컬럼 추가했다.재현 가능 여부 예상 소요 시간 의존성 (다른 티켓이나 개발자 답변 필요) 테스트 환경 (Dev/QA/Prod)P1 10개 계획 세웠다.즉시 처리 가능: 4개 (2시간) 개발자 확인 필요: 3개 (대기 후 1시간) 특수 환경 필요: 2개 (내일 오전) 재현 불가: 1개 (리포터 추가 정보 요청)4개부터 시작했다. 첫 번째 버그. 로그인 화면에서 백버튼 누르면 크래시. 재현했다. Charles로 네트워크 확인했다. API 응답은 정상. 앱 로그 확인. Null Pointer Exception. 스크린샷 3장, 로그 파일, 재현 스텝 정리해서 Jira 업데이트. 개발자 assign. 20분 걸렸다. 두 번째 버그. 결제 완료 후 화면 멈춤. 재현 안 됨. QA 서버에서는. Prod에서만 발생한다는 리포트. 운영팀한테 Prod 로그 요청. 대기. 세 번째로 넘어갔다. 효율이다. 막힌 건 넘어가고 진행 가능한 것부터. 하루 종일 한 티켓만 붙잡고 있을 수 없다. 오후 3시. P1 4개 처리했다. P2 시작했다.리소스 관리의 현실 하루에 처리 가능한 티켓 수는 정해져 있다. 단순 계산. 근무 8시간.회의 1시간 점심 1시간 이메일/슬랙 응대 1시간 실제 작업 시간 5시간버그 하나당 평균 소요 시간.재현: 15분 원인 파악: 20분 리포트 작성: 15분 개발자 커뮤니케이션: 10분 총 60분하루 5개가 현실적이다. 근데 예상 밖 변수가 있다.재현 안 되는 버그: +30분 디바이스 세팅 시간: +20분 긴급 이슈 터짐: +1시간 기획 스펙 확인: +30분실제로는 하루 3-4개다. 주 5일이면 15-20개. 팀장이 원하는 30개가 안 된다. 솔직하게 말했다. "30개는 어렵습니다. 현실적으로 20개 목표 잡겠습니다." "왜 안 돼?" "평균 처리 시간이 1시간인데, 예상 외 이슈 대응 시간 빼면 하루 4개가 한계입니다." "야근하면 되지 않아?" "야근해도 집중력 떨어지면 버그 놓칩니다. 그럼 배포 후 더 큰 문제 됩니다." 팀장 표정이 안 좋았다. 하지만 인정했다. "알았어. 20개 목표로 하자." 숫자로 말하니까 통했다. 감정이 아니라 데이터로. 배치의 기술 200개를 20개씩 나눴다. 10주 걸린다. 현실성 없다. 그 사이 새 티켓이 100개는 더 생긴다. 다른 방법이 필요하다. 배치 처리. 비슷한 버그끼리 묶었다. 로그인 관련 (8개)한 번에 테스트 환경 세팅 연속으로 처리하면 컨텍스트 스위칭 없음 2시간 안에 끝결제 플로우 (12개)QA 서버 결제 테스트 계정 필요 한 번에 몰아서 테스트 3시간UI 버그 (25개)디바이스별 확인 스크린샷 찍으면서 체크리스트 2시간특정 기종 이슈 (15개)해당 디바이스 세팅 한 번만 4시간월요일: 로그인 + 회원가입 관련 화요일: 결제 플로우 수요일: UI 버그 집중 목요일: 특정 기종 테스트 금요일: 긴급 이슈 대응 + 정리 효율이 올라갔다. 컨텍스트 스위칭이 줄었다. 테스트 환경 세팅을 반복 안 해도 됐다. 첫 주에 23개 처리했다. 목표보다 3개 더. 커뮤니케이션 비용 버그 처리보다 시간 많이 드는 게 있다. 설명이다. 개발자: "이거 재현 안 되는데요?" 나: "재현 스텝 Jira에 있습니다." 개발자: "그대로 했는데 안 돼요." 나: "화면 공유 해드릴까요?" 개발자: "네." 화면 공유 10분. 재현 보여줌. 개발자: "아 제 빌드가 달라서 그런가 봐요." 나: "..." 이런 일이 하루에 5번. 그래서 리포트 양식 만들었다. [재현 스텝] 1. 앱 실행 2. 로그인 (테스트 계정: qa_test01) 3. 마이페이지 진입 4. 프로필 수정 버튼 탭 5. 닉네임 입력 (20자 이상) 6. 저장 버튼 탭 → 크래시 발생[환경] - 빌드: v2.3.1 (build 451) - OS: Android 13 - 기기: Galaxy S23 - 서버: QA 서버[로그] (첨부)[기대 동작] 닉네임 저장 후 완료 토스트 메시지[실제 동작] 앱 크래시, 재실행 시 닉네임 변경 안 됨[추가 정보] iOS에서는 정상 동작 확인이렇게 쓰니까 "재현 안 돼요" 가 줄었다. 하지만 여전히 질문은 온다. 기획자: "이거 버그예요 스펙이에요?" 나: "스펙 문서에는 A인데 실제는 B입니다." 기획자: "음... 원래 B가 맞는 것 같은데." 나: "그럼 스펙 문서 수정해주세요." 기획자: "네, 근데 이미 개발된 거 바꾸기 애매한데..." 이런 대화 20분. 결론은 "다음 회의 때 논의". 티켓 상태를 "Pending - 스펙 확인 중"으로 바꿨다. 내 할 일 목록에서 뺐다. 안 그러면 계속 신경 쓰인다. 포기의 기술 200개를 다 할 수 없다는 걸 인정했다. P4 60개는 사실상 안 한다. "차기 버전 검토" 라벨 붙이고 백로그로 보냈다. P3 중에서도 "재현 불가" 30개는 "추가 정보 필요" 상태로 리포터한테 돌려보냈다. 1주일 안에 답 안 오면 자동 종료. 실제 처리 대상은 110개. 이것도 많다. 하지만 200개보다 심리적으로 낫다. 팀장한테 보고했다. "P4 60개는 다음 분기로 이관하겠습니다." "왜?" "리소스 대비 사용자 영향도가 낮습니다. 대신 P1, P2를 2주 안에 정리하겠습니다." "음... 알았어." 전부 다 하려고 하면 중요한 것도 못 한다. 포기할 걸 정하는 것도 능력이다. 진행 상황 추적 매일 아침 30분. 엑셀 업데이트했다. [주간 목표] 목표: 20개 완료: 23개 진행중: 5개 블록: 3개[티켓 상태] Open: 176개 (203→176, -27) In Progress: 8개 Pending: 12개 Resolved: 15개 (이번 주)숫자가 보이니까 뿌듯했다. 203에서 176. 한 주만에 27개 줄었다. 물론 새로 생긴 것도 있다. 하지만 처리 속도가 더 빠르다. 팀장한테 주간 리포트 보냈다. 슬랙에 공유했다. 개발팀장이 답했다. "오 민수님 고생 많으시네요." 인정받는 기분. 나쁘지 않다. 자동화의 유혹 P3 중에 반복 작업이 많다. "5개 기종에서 UI 확인" - 30분씩 5번, 2시간 반. "20개 화면 레이아웃 체크" - 1시간. 자동화하면 30분으로 줄어든다. 문제는 자동화 스크립트 짜는 데 5시간 걸린다는 거다. 계산했다. 이 테스트를 앞으로 10번 이상 할 거면 본전이다. UI 회귀 테스트는 매 배포마다 한다. 2주에 한 번. 1년이면 26번. 투자 가치 있다. 퇴근 후 집에서 Appium 튜토리얼 봤다. 2시간. 간단한 스크립트 짰다. 5개 화면 자동 캡처. 1시간 걸렸다. 아직 완벽하지 않다. 하지만 시작했다. 다음 주부터 하나씩 자동화 케이스 늘리기로 했다. 실전 팁 200개 티켓 앞에서 멘붕 안 오려면. 1. 일단 분류부터 우선순위 재조정. 30분 투자해서 전체 보기. 2. 배치 처리 비슷한 것끼리 묶어서. 컨텍스트 스위칭 줄이기. 3. 블로킹 이슈 따로 관리 진행 안 되는 건 Pending 처리. 내 리스트에서 빼기. 4. 매일 목표 작게 하루 5개. 달성 가능한 숫자. 5. 숫자로 추적 엑셀이든 뭐든. 진행 상황 시각화. 6. 커뮤니케이션 효율화 리포트 템플릿. 반복 질문 줄이기. 7. 포기할 것 정하기 P4는 과감히 백로그로. 집중력 분산 방지. 8. 자동화 조금씩 반복 작업부터. 5시간 투자해서 20시간 아끼기. 한 달 후 4주 지났다. Jira 티켓 128개. 203에서 75개 줄었다. 물론 새로 생긴 것도 있다. 하지만 관리 가능한 수준이다. 팀장이 말했다. "민수야, 이번 달 티켓 처리율 좋던데?" "네, 배치 처리 방식 바꿔서요." "다른 팀원들도 좀 공유해줘." 오후에 팀 회의. 내 방법 설명했다. 15분. 신입 QA가 물었다. "그럼 우선순위는 누가 정해요?" "우리가 정해야죠. 사용자 영향도 기준으로." "근데 기획팀에서 P1 올리면요?" "데이터로 설명하세요. 사용자 몇 명한테 영향 가는지, 얼마나 자주 발생하는지." 신입이 고개 끄덕였다. 회의 끝나고 슬랙에 정리 문서 공유했다. 내가 쓴 엑셀 템플릿이랑 우선순위 기준표. 3명이 따봉 달았다.티켓은 계속 쌓인다. 하지만 이제 안다. 전부 다 할 필요 없다는 걸. 중요한 것부터, 효율적으로, 숫자로 증명하면서. 그게 프로고 살아남는 방법이다.

야근 수당보다 소중한 것 - QA의 자존감 찾기

야근 수당보다 소중한 것 - QA의 자존감 찾기

연봉 명세서를 펼친 밤연봉 협상 메일을 받았다. 4200만원에서 4500만원. 300만원 올랐다. 월 25만원. 기뻐야 하나. 같은 날 입사한 개발자 친구는 5800만원이 됐다고 한다. 작년에 이미 5500만원이었다. 나랑 똑같이 4년 차다. 대학도 같이 나왔다. "너도 개발 배워. QA는 한계 있어." 친구는 악의 없이 말했다. 근데 그게 더 아프다. 야근 수당 포함하면 4700만원 정도 된다. 배포 전날은 거의 매번 새벽까지다. 수당이 없으면 난 뭐지. 개발자는 야근 안 해도 기본이 높다. QA는 야근해야 겨우 따라간다. 이게 맞나. 회의실의 온도차오늘 연봉 협상 미팅이었다. 팀장님이 말했다. "민수씨 열심히 하는 거 안다. 근데 QA 시장 단가가 그래." 시장 단가. 이 말을 세 번째 듣는다. "개발은 구하기 어렵잖아. 경쟁이 심해서 어쩔 수 없이." 그럼 QA는 쉽게 구하냐. 제대로 할 수 있는 사람이 몇이나 되냐. 테스트 케이스 짜고, 엣지 케이스 찾고, 재현 스텝 정리하고, 개발자 설득하고. 이게 아무나 하는 일이냐. "자동화 배우면 연봉 더 올릴 수 있어." 자동화. 맨날 듣는다. 근데 언제 배우라는 거지. 매일 야근하는데. 주말에 공부하라는 건가. 개발자는 회사에서 React 새 버전 배우면 업무 시간에 한다. QA는 Selenium 배우려면 개인 시간 써야 한다. 이것도 시장 단가냐. 팀장님은 좋은 분이다. 근데 설득이 안 된다. "다른 회사도 비슷할 거야." 알아봤다. 맞다. 다 비슷하다. 그래서 더 화난다. 버그 900개의 가치 지난 1년간 내가 등록한 버그는 917개다. Jira에 다 있다. Critical 52개, Major 284개, Minor 581개. Critical 버그 중 28개는 배포 전에 발견했다. 출시됐으면 서비스 터졌을 것들이다. 로그인 무한 루프, 결제 금액 오표시, 푸시 중복 발송, 개인정보 노출 취약점. 이거 하나만 나가도 회사 망한다. 뉴스 나온다. 주가 떨어진다. 근데 내 연봉엔 안 보인다. 개발자는 "이 기능 제가 만들었어요" 할 수 있다. 눈에 보인다. QA는? "이 버그 제가 찾았어요" 말하면 "그게 네 일이잖아" 돌아온다. 맞다. 내 일이다. 근데 왜 개발자 일은 대단하고 내 일은 당연한 건데. 기능 하나 추가하는 것보다 서비스 안 터지게 하는 게 더 중요한 거 아닌가. 퇴근길의 자문자답9시에 퇴근했다. 배포 일주일 전이라 요즘 이렇다. 지하철에서 생각했다. 나 왜 이 일 하지. 돈? 아니다. 개발 배우면 더 번다. 적성? 글쎄. 테스트는 좋은데 인정은 별로다. 그럼 뭐지. 홍대입구역에서 한 할머니가 스마트폰 보고 계셨다. 우리 회사 앱이다. 결제하시다가 멈추셨다. 네트워크 끊겼나 보다. 근데 3초 후에 다시 진행됐다. 그거 내가 찾은 버그다. 2주 전에. "네트워크 끊기면 무한 로딩 도는데요. 타임아웃 처리 필요합니다." 개발자는 귀찮아했다. "확률 낮은데 꼭 해야 해요?" "할머니가 지하철에서 쓸 수도 있잖아요." 결국 고쳤다. 지금 할머니가 불편 없이 쓰신다. 그게 내 일이다. 연봉 명세서엔 안 나온다. 근데 가치는 있다. 개발자와의 대화 사무실로 돌아왔다. 핫픽스 확인 요청이 왔다. 개발자 성진이가 물었다. "민수야, 너 이직 생각 없어?" "왜?" "QA는 연봉 한계 있잖아. 개발 배워." 웃었다. 오늘만 몇 번째 듣는 소린지. "나도 알아. 근데 나는 개발보다 이게 맞는 것 같아." "그래도 돈은 중요하잖아." 맞다. 중요하다. 여자친구랑 결혼 생각하면 더 그렇다. 근데 성진이한테 말했다. "너 지난주에 만든 기능 있잖아. 가입 플로우." "응." "내가 테스트하면서 17개 버그 찾았어. 그 중에 회원가입 안 되는 거 3개." "...그랬지." "그거 내가 안 찾았으면 출시됐어. 신규 가입 0명이었겠지." "고마워." "난 그게 좋아. 너희가 만든 거 완성시키는 거." 성진이가 웃었다. "그래도 연봉은 나보다 적잖아." "알어. 근데 니가 내 돈 벌어다 줄 거 아니잖아." 둘이 웃었다. 근데 진짜다. 내가 선택한 일이다. 돈이 전부는 아니다. 자존감의 정의 밤 11시. 핫픽스 확인 끝났다. 테스트 리포트 작성한다. "총 23개 테스트 케이스, 모두 Pass. 배포 가능." 이 한 줄을 쓰기 위해 3시간 테스트했다. 개발자들은 이 메시지 보고 안심하고 배포한다. 내가 확인했으니까. 그 믿음이 내 가치다. 연봉 명세서에는 안 나온다. 근데 없으면 안 된다. 작년에 신입 QA가 왔었다. 2개월 만에 관뒀다. "버그 찾아도 인정 안 해주고, 개발자들이 무시하고, 연봉도 낮고. 뭐 하러 이 일 해요?" 이해한다. 나도 맨날 생각한다. 근데 안 그만둔다. 왜냐면 알기 때문이다. 서비스 품질을 지키는 마지막 사람이 나라는 걸. 개발자가 놓친 버그를 찾는 사람이 나라는 걸. 사용자가 불편 없이 쓸 수 있게 하는 사람이 나라는 걸. 그게 내 자존감이다. 야근 수당의 의미 야근 수당 들어온다. 이번 달 110만원. 배포 3번 있었다. 새벽까지 3번 남았다. 시급으로 계산하면 얼마 안 된다. 근데 이게 있어서 연봉이 개발자를 조금이라도 따라간다. 슬픈 일이다. 친구가 말했다. "야근 수당으로 연봉 메꾸는 거 이상하지 않아?" 이상하다. 근데 이게 현실이다. QA 시장 단가. 개발자보다 낮은 대우. 아무나 할 수 있다는 인식. 다 알고 있다. 그래도 계속한다. 왜냐면 야근 수당보다 소중한 게 있으니까. 배포 후에 모니터링하는 30분. 심장 쫄깃하다. 버그 없이 지나가면 안도한다. "이번에도 잘 넘어갔네." 그 안도감. 그게 내 보상이다. 돈으로 환산 안 된다. 근데 가치 있다. 여자친구가 물었다. "개발자가 돈 더 버는데 왜 안 배워?" "나는 지키는 게 좋아. 만드는 것보다." "그게 뭔데?" "품질. 사용자 경험. 서비스 안정성." "그게 돈이 돼?" "안 돼. 근데 의미 있어." 여자친구는 이해 못 한다. 괜찮다. 나도 가끔 이해 못 한다. 내일의 선택 내일도 출근한다. 9시. 어제 올라온 빌드 확인한다. 테스트 시작한다. 버그 찾으면 등록한다. 개발자가 "제 PC에선 안 그러는데요?" 말하면 재현해준다. 배포 일주일 전이면 야근한다. 새벽에 최종 확인한다. 연봉은 개발자보다 낮다. 야근 수당이 없으면 더 낮다. 그래도 한다. 왜? 품질을 지키는 사람이 필요하니까. 아무나 못 하니까. 내가 할 수 있으니까. 자동화 배울 거다. 연봉 더 올릴 거다. 이직도 알아볼 거다. 근데 QA는 안 그만둔다. 이게 내 일이다. 자부심 있다.야근 수당은 숫자다. 자존감은 선택이다. 나는 후자를 택했다.

금요일 오후 5시 59분, 배포 요청이 들어왔다

금요일 오후 5시 59분, 배포 요청이 들어왔다

5시 59분 금요일 오후 5시 59분. 슬랙이 울렸다. "민수님, 급한 배포 건이 있어서요. 월요일 아침까지 올려야 해요." 기획팀 김과장이다. 배포는 내일 토요일 오전 10시래. 내일. 10시. 지금부터 15시간.무슨 변경인데 "어떤 기능이요?" "결제 플로우 일부 수정이요. UX 개선." 결제. 플로우. 가장 건드리면 안 되는 부분이다. "스펙 문서 있어요?" "아, 지금 정리 중이에요. 30분 뒤에 드릴게요." 30분. 6시 30분이면 된다는 거다. 개발은 언제 끝나냐고 물었다. "밤 10시쯤요? 늦어도 11시?" 밤 11시. 그럼 테스트 시작은 자정. 토요일 새벽부터 오전 10시까지. 10시간. 결제 플로우 전체를 10시간 안에. 계산 책상 앞에 앉았다. 계산기를 켰다. 결제 테스트 케이스: 총 147개. 풀 테스트하면 8시간. 리그레션까지 하면 12시간. 시간이 4시간 부족하다. 범위를 줄여야 한다. 어디를.스펙 문서 7시 10분. 스펙이 왔다. 40분 늦었다. 열어봤다. 4페이지. "결제 버튼 위치 변경" "카드 선택 UI 개선" "쿠폰 적용 로직 수정" 로직 수정? "쿠폰이랑 포인트 동시 사용 가능하게" 이건 단순 UI가 아니다. 비즈니스 로직이다. 쿠폰, 포인트, 할인율, 최종 금액. 경우의 수가 몇 개지. 쿠폰 3종류, 포인트 전액/일부, 상품 할인... 최소 20개 케이스. 개발자 호출 개발팀 이대리한테 전화했다. "대리님, 쿠폰이랑 포인트 동시 사용. 테스트 어디까지 해야 돼요?" "음... 일단 정상 케이스만요. 시간 없잖아요." 정상 케이스만. "근데 쿠폰 여러 개 적용은요?" "아, 그건 원래 안 되는 거라 괜찮아요." 원래 안 되는 게 괜찮다는 게 아니라, 이번에 안 건드렸다는 거다. "포인트 부족하면요?" "그것도 기존 로직 그대로요." 기존 로직. 그럼 새로 테스트 안 해도 되나. "근데 화면은 바뀌잖아요." "네, 화면만요." 화면만. 그래도 확인은 해야 한다. 범위 결정 화이트보드에 적었다. 필수:쿠폰+포인트 동시 사용 (정상) 결제 버튼 위치 확인 카드 선택 UI 동작준필수:포인트 부족 시나리오 쿠폰 단독 사용 최종 금액 계산 검증제외:쿠폰 여러 개 조합 배송지 변경 (이번 건 무관) 리워드 적립 (서버 로직, 별도)제외 항목을 보니 불안하다. 배송지는 정말 무관할까. 최종 금액이 배송비에 영향 주지 않나.PM한테 물었다 "배송비 로직은 변경 없죠?" 기획팀 김과장이 답했다. "네, 그건 안 건드렸어요." "확실해요?" "...개발팀한테 확인할게요." 5분 뒤. "아, 배송비 무료 조건이 '할인 전 금액' 기준으로 바뀌었대요." 바뀌었다고. "그럼 쿠폰 쓰면 배송비 나올 수 있다는 거네요?" "네... 그렇네요?" 그렇네요가 아니다. 테스트 케이스 15개 추가다. 8시 30분 여자친구한테 문자 왔다. "저녁 먹자. 치킨?" "오늘 야근. 미안." "또? 금요일인데." "배포." "배포가 뭐길래 매번." 설명할 기운이 없다. "내일 저녁에. 내가 살게." "...ㅇㅇ" ㅇㅇ. 화났다는 거다. 빌드 대기 밤 10시. 빌드를 기다렸다. 개발팀 단톡방을 봤다. "빌드 언제 나와요?" "조금만요. 충돌 해결 중." "11시는 될 것 같아요." 11시. 또 늦는다. 컵라면을 끓였다. 사무실 비상 재고. 매운 맛. 밤샘할 때 먹는 맛. 11시 47분 빌드가 올라왔다. 바로 다운로드. 설치. 앱 실행. 로그인. 상품 담기. 결제 화면 진입. UI가 바뀌었다. 버튼 위치가 아래로. 카드 선택 탭이 깔끔해졌다. 쿠폰 선택. 포인트 입력. 최종 금액 확인. 정상이다. 첫 번째 케이스 통과. 시간은 자정 넘어 12시 3분. 두 번째 케이스 포인트만 사용. 쿠폰 없이. 결제 진행. "오류가 발생했습니다." 터졌다. 재현해봤다. 또 터진다. 찰스 프록시 켰다. 로그 확인. "couponId: null" null을 못 받는다. 개발팀 단톡에 올렸다. "포인트만 쓰면 에러나요. couponId null 처리 안 됨." 이대리가 답했다. "아... 수정할게요. 30분?" 새벽 1시에 30분. 1시 30분이면 다시 빌드. 대기 시간 책상에 엎드렸다. 30분. 잘 수는 없다. 테스트 케이스를 다시 봤다. 우선순위를 재조정했다. null 처리 버그. 심각도 높음. 다른 곳에도 있을까. 배송지 null, 카드 정보 null, 쿠폰 코드 invalid... 체크리스트를 만들었다. Null/Empty 체크:쿠폰 미선택 포인트 0원 배송 메모 없음 카드 없을 때전부 확인해야 한다. 2시 10분 빌드가 또 올라왔다. 1시 30분 약속은 지켰다. 다시 설치. 로그인. 포인트만 사용. 테스트. 통과. 쿠폰만 사용. 통과. 둘 다 사용. 통과. 쿠폰+포인트+배송비. 금액 계산 확인. 9,800원 상품. 2,000원 쿠폰. 3,000원 포인트. 결과: 4,800원 + 배송비 3,000원. 맞다. 근데 할인 전 금액 기준 배송비 무료는 10,000원부터. 9,800원은 300원 모자라니까 배송비 나온다. 이게 맞나. 유저는 혼란스러울 것 같은데. PM한테 물었다 새벽 2시 30분에 슬랙을 보냈다. "배송비 무료 기준이 할인 전 금액이면, 9,800원 상품에 쿠폰 써도 배송비 나와요. 의도 맞아요?" 답이 없다. 당연하다. 잘 시간이다. 기획 의도를 모르겠으면 테스트를 어떻게 하나. 일단 버그는 아니니까 통과 처리. 이슈로 남겼다. "배송비 정책 UX 혼란 가능성 있음. 기획 검토 필요." 3시 47분 결제 완료까지 갔다. 주문 내역 확인. 정상. 쿠폰 차감됨. 포인트 차감됨. 리워드 적립. 확인. 여기까지 8개 케이스 완료. 남은 건 7개. 배송지 변경 케이스, 카드 여러 개 케이스, 할부 개월 수... 눈이 감긴다. 커피를 마셨다. 네 번째. 결제 취소 환불 테스트를 시작했다. 쿠폰 쓴 주문 취소. 쿠폰 복구돼야 함. 취소 완료. 쿠폰함 확인. 없다. 쿠폰이 안 돌아왔다. 다시 해봤다. 또 안 돌아온다. 심각하다. 단톡에 올렸다. "결제 취소 시 쿠폰 복구 안 됨. Blocker." 4시 21분 개발자가 답했다. 이대리가 아니라 팀장이다. "확인했습니다. 수정 중. 5시까지." 5시. 배포까지 5시간 남았다. 5시 13분 빌드 올라왔다. 다시 테스트. 쿠폰 결제. 취소. 쿠폰함 확인. 돌아왔다. 포인트도 확인. 정상. 통과. 남은 케이스 6개. 시간은 5시간. 할 수 있다. 7시 카드 할부 케이스 테스트 중. 3개월 할부. 정상. 6개월. 정상. 12개월. 금액 계산 이상함. 수수료가 두 번 붙었다. 또 버그다. 심각도는 중간. Blocker는 아니다. 12개월 할부 쓰는 사람 많지 않음. 하지만 금액 오류는 민감하다. 올렸다. "12개월 할부 수수료 중복 계산." 답이 없다. 아직 개발팀이 안 왔다. 8시 40분 개발팀이 출근했다. 이대리가 단톡 확인했다. "12개월 할부 버그는 배포 후 핫픽스 가능할까요?" 가능할까요가 아니라. PM이 답했다. "일단 배포하고 다음 주에 수정해요." 다음 주. 유저가 12개월 할부 쓰면 손해 본다. 그냥 배포한다고. 9시 20분 남은 케이스 2개. 배송 메모 특수문자, 긴 텍스트. 둘 다 통과. 테스트 완료. 총 15개 케이스. 버그 3건. Blocker 1건 수정 완료. 중간 심각도 1건 다음 주 수정. 낮은 심각도 1건 이슈 등록. 배포 승인 PM한테 보고했다. "테스트 완료. 배포 가능합니다. 단, 12개월 할부 버그 있음. 다음 주 수정 예정." "고생하셨어요. 10시에 배포 진행할게요." 고생하셨어요. 15시간 일하고 듣는 말. 10시 배포 앱스토어에 올라갔다. 배포 완료. 모니터링 시작. 슬랙, 센트리, 파이어베이스 크래시 리포트. 에러 없다. 30분 지났다. 아직 조용하다. 1시간. 여전히 조용하다. 다행이다. 11시 30분 집에 왔다. 샤워하고 침대에 누웠다. 여자친구한테 문자 보냈다. "끝났어. 저녁 먹자. 7시?" 답이 바로 왔다. "ㅇㅇ 어디?" 아직 화났나. "네가 고르면 내가 살게." "그럼 스테이크." 비싸다. 근데 어쩔 수 없다. "ㅇㅇ" 월요일 출근했다. 슬랙에 알림 하나. CS팀이다. "결제 관련 문의 들어왔어요. 12개월 할부 금액이 이상하대요." 시작됐다. 개발팀 단톡에 포워딩했다. "금요일에 리포트한 버그입니다. 수정 일정 알려주세요." 이대리가 답했다. "오늘 수정해서 내일 배포 가능해요." 내일 배포면 내가 또 테스트한다.금요일 5시 59분. 그 1분이 주말을 날렸다. 근데 배포는 성공했다. 그게 다행인 건가, 불행인 건가. 모르겠다.

엣지 케이스 사냥꾼 일지 - 버그는 디테일에 숨어있다

엣지 케이스 사냥꾼 일지 - 버그는 디테일에 숨어있다

엣지 케이스 사냥꾼 일지 - 버그는 디테일에 숨어있다 오늘도 엣지 케이스가 날 찾아왔다 출근했다. 테스트 빌드가 와 있다. 개발팀에서 "간단한 수정"이라고 했다. 간단한 수정일수록 더 무섭다는 걸 4년 차면 안다. 빌드 설치하고 앱 켰다. 정상 시나리오부터 돌린다. 문제없다. 이제부터가 진짜다. 나는 엣지 케이스 사냥꾼이다. 정상 사용자가 절대 안 할 것 같은 동작. 그게 내 테스트 범위다.네트워크를 미친 듯이 끊어봤다 첫 번째 타겟. 네트워크. 앱 실행 → 로그인 → 메인 화면. 여기서 와이파이 껐다. 정상 사용자는 안 그런다고? 지하철 타면 터널이다. 계속 끊긴다. 엘리베이터 타도 끊긴다. 이게 엣지 케이스가 아니라 일상이다. 데이터 로딩 중에 끊었다. 로딩 표시가 멈췄다. 무한 로딩. 뒤로 가기도 안 된다. 앱 죽일 수밖에. 버그 등록했다. 재현 스텝 꼼꼼히 적었다. "데이터 로딩 시작 후 2초 시점에 네트워크 차단 → 무한 로딩 → 사용자 액션 불가" 개발자 답변 왔다. "실제로 그럴 일이 있나요?" 있다. 매일 있다.텍스트 필드에 미친 짓을 했다 두 번째 타겟. 입력 필드. 회원가입 화면 띄웠다. 이름 입력란이 보인다. 정상 입력: "홍길동" 내 입력: 이모지 100개. 🎉🎉🎉🎉🎉🎉🎉... 계속. 앱이 버벅거렸다. 입력은 됐다. 다음 버튼 눌렀다. 서버 에러. 500. 또 입력했다. 이번엔 특수문자. !@#$%^&*() 되긴 된다. 저장도 된다. 마이페이지 가서 확인했다. 레이아웃 깨졌다. 글자가 화면 밖으로. 버그 두 건 등록. "이모지 100자 이상 입력 시 서버 에러" "특수문자 포함 이름 저장 시 UI 깨짐" 개발자가 물었다. "누가 이름에 이모지 100개를 넣어요?" 몰라. 근데 막을 거 아니면 처리해야지. 전화번호 입력란도 테스트했다. 숫자 말고 문자 넣어봤다. "가나다" 입력이 된다. 막혀야 하는데. 인증번호 요청 눌렀다. 당연히 실패. 근데 에러 메시지가 이상하다. "undefined error occurred" 세 번째 버그 등록. "전화번호 필드 문자 입력 허용, 에러 메시지 미정의" 오전에 버그 3개. 아직 점심 전이다. 화면 회전을 미친 듯이 돌렸다 점심 먹고 왔다. 세 번째 타겟. 화면 회전. 결제 화면 띄웠다. 가로로 돌렸다. 세로로 돌렸다. 가로. 세로. 가로. 세로. 5번쯤 돌렸을 때 앱이 죽었다. 재현했다. 또 죽었다. 버그 등록. "결제 화면에서 화면 회전 반복 시 앱 크래시" 개발자 반응. "누가 결제 중에 화면을 돌려요?" 누가 알아. 근데 돌릴 수 있으면 대응해야지.동시에 눌러봤다 네 번째 타겟. 동시 액션. '저장' 버튼이 있다. 한 번 누르면 저장된다. 정상. 양손으로 동시에 눌렀다. 연타했다. 5번. 저장 완료 메시지가 5번 떴다. 데이터 확인했다. 같은 데이터가 5개 저장됐다. 중복 저장 방지 안 됨. 버그 등록. "저장 버튼 연타 시 중복 저장 발생" 개발자: "그렇게 빨리 누를 수가 있나요?" 있다. 터치 반응 느리면 사용자가 연타한다. 실제로 CS에서 중복 결제 문의 들어온 적 있다. 좋아요 버튼도 테스트했다. 연타했다. 숫자가 이상하게 올라간다. 1 → 3 → 2 → 5 → 4 API 호출 타이밍 문제인 듯. 버그 추가 등록. 오후에 버그 2개 더. 백그라운드에서 복귀했다 다섯 번째 타겟. 앱 상태 전환. 앱 켜고 로딩 중에 홈 버튼. 10초 기다렸다. 앱 복귀. 화면이 하얗다. 데이터가 안 보인다. 앱 죽이고 다시 켜야 한다. 버그 등록. "백그라운드 복귀 시 데이터 미표시" 개발자: "생명주기 처리 놓쳤네요" 알고 있었다. QA가 없으면 배포됐을 버그다. 푸시 알림도 테스트했다. 앱 켜진 상태에서 푸시 받았다. 알림 탭했다. 해당 화면으로 이동. 뒤로 가기 눌렀다. 앱이 종료됐다. 스택이 잘못 쌓였다. 버그 등록. 하루에 버그 7개. 평균치다. 권한을 미친 듯이 껐다 여섯 번째 타겟. 권한. 카메라 권한 필요한 기능이다. 권한 거부했다. 안내 팝업 뜬다. 정상. 설정 가서 권한 껐다. 앱으로 돌아왔다. 카메라 실행 버튼 눌렀다. 앱이 죽었다. 권한 체크 안 함. 버그 등록. "카메라 권한 거부 상태에서 크래시" 위치 권한도 테스트했다. '항상 허용'에서 '앱 사용 중에만' 변경. 지도 화면 갔다. 내 위치가 업데이트 안 된다. 권한 변경 감지 안 함. 버그 추가. 알림 권한 껐다. 앱에서 알림 설정 화면 들어갔다. 스위치가 다 켜져 있다. 실제론 안 오는데 UI는 켜진 상태. 또 버그. 오늘 10개. 오래된 데이터를 불러왔다 일곱 번째 타겟. 데이터 상태. 1년 전 테스트 계정이 있다. 로그인했다. 마이페이지 들어갔다. 프로필 이미지가 안 보인다. URL이 만료됐나 보다. 오래된 게시글 눌렀다. 댓글이 이상하게 보인다. 탈퇴한 사용자 표시가 안 됨. 찜 목록 들어갔다. 삭제된 상품이 그대로 있다. 눌렀더니 404 에러. 버그 3개 더 등록. "만료된 이미지 URL 처리 미흡" "탈퇴 사용자 댓글 표시 오류" "삭제된 상품 찜 목록 표시" 개발자들이 안 보는 데이터. 오래된 것, 삭제된 것, 만료된 것. 여기서 버그가 나온다. 이상한 조합을 시도했다 여덟 번째 타겟. 기능 조합. 검색하면서 필터 바꿨다. 정렬하면서 새로고침 했다. 동영상 재생 중에 화면 잠갔다. 검색어 입력 중에 필터 변경. 검색어가 사라졌다. 입력 상태 초기화. 버그. 동영상 재생 중 화면 잠금. 5분 후 해제. 동영상이 계속 재생 중이다. 소리는 안 나는데 재생은 됨. 배터리가 닳는다. 버그. 장바구니에 담고 로그아웃. 다른 계정으로 로그인. 장바구니가 이전 계정 거다. 데이터 안 지워짐. 심각한 버그. 오늘 15개. 배포 전이라 다행이다. 개발자와의 대화 버그 리포트 15건 올렸다. 개발자가 채팅 보냈다. "민수님, 이거 다 고쳐야 해요?" "네." "근데 이런 상황 실제로 일어나나요?" "네. 다 재현했어요." "우선순위 좀 정해주세요." 버그 심각도 다시 봤다. Critical: 3개 (앱 크래시, 데이터 유실) High: 7개 (기능 동작 안 함) Medium: 5개 (UI 깨짐, 불편) "Critical 3개는 배포 전에 필수요." "High는 다음 배포까지요." 개발자가 물었다. "이런 엣지 케이스를 어떻게 다 생각해요?" 몰라. 그냥 생각난다. 앱 쓰다 보면 자동으로 떠오른다. '이렇게 하면 어떻게 될까?' '여기서 끊으면?' '이걸 동시에 누르면?' 4년 차 직업병이다. 엣지 케이스가 일상이 된 순간 퇴근길 지하철. 유튜브 보다가 터널 들어갔다. 네트워크 끊겼다. 버퍼링. 터널 나왔다. 재생 재개. '이거 우리 앱은 어떻게 되지?' 테스트했었다. 버그 있었다. 고쳐졌을까? 내일 확인해야지. 편의점 들렀다. 결제 앱 켰다. 바코드 표시. '화면 밝기 최저일 때는?' '화면 회전하면?' '배터리 1%일 때는?' 다 테스트해봐야겠다. 내일 할 일이 또 생겼다. 집 와서 배달 앱 켰다. 주문하다가 앱이 튕겼다. '재현 가능한가?' 다시 켰다. 또 튕겼다. 리뷰 남겼다. "주문 중 앱 크래시, 아이폰 14 Pro, iOS 17.2, 재현 가능" 재현 스텝까지 적었다. 친구가 물었다. "너 왜 리뷰를 버그 리포트처럼 써?" 습관이다. 고칠 수가 없다. QA의 자부심 사람들은 묻는다. "QA가 뭐 하는 건데요?" "버그 찾는 거요." 틀렸다. 우리는 사용자를 보호한다. 정상 사용자가 안 할 동작을 내가 대신 한다. 앱이 죽을 수 있는 상황을 내가 먼저 찾는다. 엣지 케이스는 엣지가 아니다. 누군가에겐 일상이다. 네트워크가 불안정한 사람. 터치를 빨리 하는 사람. 화면을 자주 돌리는 사람. 백그라운드 전환이 잦은 사람. 그 사람들이 버그를 만나기 전에 내가 먼저 만난다. 개발자들은 정상 시나리오를 만든다. 나는 비정상 시나리오를 만든다. 둘 다 필요하다. 오늘 찾은 버그 15개. 배포 후 사용자가 만났을 버그 15개. 내가 막았다. 내일의 엣지 케이스 내일 테스트 계획 세웠다. 메모리 부족 상황 테스트. 앱 여러 개 켜놓고 우리 앱 실행. 백그라운드에서 죽는지 확인. 저장 공간 부족 상황. 파일 다운로드 시도. 에러 처리 되는지 확인. 시간대 변경 테스트. 해외 시간대로 바꾸고 날짜/시간 표시 확인. 언어 변경 테스트. 영어로 바꿨을 때 레이아웃 깨지는지 확인. 접근성 테스트. VoiceOver 켜고 스크린 리더로 사용 가능한지. 할 게 많다. 엣지 케이스는 끝이 없다. 그래도 좋다. 버그 찾을 때 짜릿하다. '이거 아무도 생각 못 했을 텐데' 싶은 버그 찾으면 이상하게 기분이 좋다. 나는 엣지 케이스 사냥꾼이다. 디테일에 숨은 버그를 찾는다. 그게 내 일이다.오늘도 버그 15개. 내일은 몇 개나 찾을까.