Showing Posts From

버그

엑셀은 내 친구 - QA와 스프레드시트의 떨어질 수 없는 관계

엑셀은 내 친구 - QA와 스프레드시트의 떨어질 수 없는 관계

아침부터 엑셀 출근하면 가장 먼저 여는 건 엑셀이다. Jira보다 먼저다. 어제 테스트하다 말았던 시트를 연다. 초록색 셀은 Pass, 빨간색 셀은 Fail, 노란색은 Pending. 한눈에 들어온다. 리드가 물어본다. "어제까지 진행률이요?" 엑셀 하단에 자동 계산해둔 셀을 본다. "78.3%요." 3초 만에 답한다. Jira에서는 이 답을 3분 안에 못 구한다.TestRail은 좋은데 우리 회사도 TestRail 쓴다. 연간 라이선스 수백만 원짜리다. 근데 실제로는. TestRail에는 정식 테스트 케이스만 올린다. 문서화된 것. 검증된 것. 배포 전 최종 확인용. 진짜 테스트는 엑셀에서 한다. 탐색적 테스트하면서 발견한 것들. "이거 확인해봐야겠다" 싶은 것들. 임시로 추가한 체크리스트. 빌드별로 달라지는 테스트 범위. 이런 건 TestRail에 올리기 애매하다. 정식 케이스도 아니고. 매번 바뀌는데 거기 다 넣으면 관리가 안 된다. 결국 엑셀이다. 팀장님도 알고 계신다. "TestRail은 형식이고, 엑셀이 실전이지." 그렇게 말씀하신다.내가 엑셀로 관리하는 것들 1. 일일 테스트 체크리스트 매일 아침 만든다. 오늘 테스트할 기능 리스트. 우선순위 표시. 예상 소요시간. 실제 소요시간. 차이 기록. 이거 쌓이면 나중에 일정 산정할 때 근거가 된다. "로그인 기능 테스트는 보통 2시간 걸립니다." 데이터로 말한다. 2. 버그 트래킹 보조 시트 Jira에 버그는 다 올린다. 당연히. 근데 내 시트에는 더 많은 정보가 있다. 재현율. 특정 디바이스에서만 나오는지. 개발자 반응. 픽스 예상일. 내 체감 심각도. Jira는 공식 기록. 엑셀은 내 전투 일지다. 3. 디바이스별 테스트 현황 iPhone 12, 13, 14. Galaxy S21, S22, S23. 각 OS 버전별. 어떤 디바이스로 어떤 기능을 언제 테스트했는지. 이번 빌드에서 어떤 디바이스가 아직 안 됐는지. 시각적으로 표시한다. 색깔로. 조건부 서식으로. 개발자가 "그거 테스트했어요?" 물으면 바로 확인 가능하다. "iPhone 13에서 어제 했고, Galaxy는 오늘 오후 예정입니다." 4. 빌드 히스토리 빌드 번호. 날짜. 주요 변경사항. 발견한 버그 개수. 심각한 버그 여부. 배포 여부. 나중에 "이 버그 언제부터 있었죠?" 물으면 이거 보고 답한다. "빌드 234부터요. 9월 15일자." 5. 배포 체크리스트 배포 전날 밤. 이걸 보면서 최종 확인한다. 필수 시나리오 50개. 하나씩 체크. Pass 확인. 스크린샷 첨부 경로 기록. 이거 없으면 불안해서 못 잔다.왜 자동화 못 하냐고요 이번 주 회의에서 나왔다. "QA도 자동화 전환해야죠. 엑셀로 언제까지 하시게요?" 말은 맞다. 나도 안다. 근데 현실은. 시간이 없다. 당장 다음 주 배포인데 자동화 스크립트 짤 시간이 어딨나. 매뉴얼 테스트도 빠듯하다. "자동화 공부할 시간 드릴게요." 일주일에 2시간 준다. 2시간으로 뭘 하나. 변경이 너무 잦다. 이번 주 스펙 바뀐 게 세 번이다. UI도 계속 바뀐다. 자동화 스크립트 짜놓으면 다음 주에 못 쓴다. Selector가 바뀌어서. 플로우가 바뀌어서. 유지보수하는 시간이 처음 짜는 시간보다 더 든다. 모든 걸 자동화할 순 없다. UI 깨짐. 미묘한 애니메이션 버그. 특정 상황에서만 나오는 크래시. 이런 건 사람 눈으로 봐야 한다. 탐색적 테스트가 필요하다. 자동화는 정형화된 시나리오만 된다. 우리 앱에서 그런 게 30%밖에 안 된다. 인프라가 없다. 자동화 서버. CI/CD 파이프라인. 디바이스 팜. 이런 거 구축하려면 돈이 든다. 시간도 든다. 팀장님이 위에 보고하셨다. 거절당했다. "매출 늘어나면 검토하죠." 결국 엑셀로 돌아온다. 엑셀이 나쁜 건 아니다 개발자들은 엑셀 쓰는 걸 구식이라고 한다. "요즘 누가 엑셀로 테스트 관리해요?" 근데 나는 생각한다. 엑셀이 나쁜 게 아니라 상황이 그런 거다. 엑셀의 장점이 있다. 빠르다. 새 시트 만드는 데 10초. 템플릿 복사해서 쓰면 5초. Jira에서 새 대시보드 만들려면 설정에서 필드 추가하고 필터 설정하고 권한 확인하고. 20분 걸린다. 유연하다. 필요한 컬럼 바로 추가한다. 수식 넣는다. 차트 만든다. 내 맘대로. 전문 툴은 정해진 틀이 있다. 커스터마이징에 한계가 있다. 오프라인에서도 된다. 지하철에서도 본다. 회의실에서 인터넷 안 될 때도 쓴다. 클라우드 툴은 인터넷 끊기면 끝이다. 엑셀 다루는 건 모두가 안다. 신입이 와도 설명 안 해도 된다. 컬러 코딩 보여주면 바로 안다. 전문 툴은 온보딩에 일주일 걸린다. 물론 한계는 있다. 협업에 약하다. 버전 관리가 애매하다. 실시간 동기화 안 된다. 그래도 지금 우리 환경에서는 엑셀이 최선이다. 엑셀 장인의 길 4년 하다 보니 나만의 템플릿이 생겼다. 조건부 서식 활용 Pass는 초록, Fail은 빨강, Pending은 노랑. 자동으로 색 바뀌게. 마감일 지난 건 진한 빨강. 오늘이 마감인 건 주황. 숫자만 봐도 상황 파악된다. 피벗 테이블 디바이스별 버그 개수. 기능별 테스트 진행률. 주차별 테스트 커버리지. 데이터 쌓아놓고 피벗 테이블 돌리면 리포트 끝이다. 주간 회의 자료 만드는 데 10분이면 된다. 수식 자동화 VLOOKUP으로 버그 ID 넣으면 상태 자동으로 가져온다. COUNTIF로 Pass/Fail 개수 자동 집계. TODAY()로 오늘 날짜 기준 남은 날 자동 계산. 수동으로 하던 걸 수식으로 바꿨다. 실수도 줄고 시간도 줄었다. 매크로 반복 작업은 매크로로 만들었다. "새 테스트 시트 만들기" 버튼 하나로 템플릿 복사, 날짜 입력, 시트 이름 변경까지 자동. 3분 걸리던 게 3초 된다. VBA 공부한 건 아니다. 인터넷에서 찾아서 조금 수정했다. 그 정도면 충분하다. 엑셀과 툴의 공존 요즘 내 업무 플로우는 이렇다. 1단계: 엑셀로 계획 이번 주 테스트 범위. 우선순위. 일정. 다 엑셀에 정리. 빠르게 초안 만든다. 수정도 빠르다. 2단계: 툴로 공식화 정해진 것만 TestRail에 올린다. Jira에 티켓 만든다. 공식 기록용이다. 팀 전체가 보는 것. 3단계: 엑셀로 실행 실제 테스트할 때는 내 엑셀 시트 본다. 더 디테일하다. 더 빠르다. 내 손에 익었다. 4단계: 툴로 보고 결과는 다시 툴에 입력한다. Jira 버그 상태 업데이트. TestRail 테스트 결과 입력. 이건 해야 한다. 공식 프로세스니까. 5단계: 엑셀로 분석 주말에 데이터 정리한다. 트렌드 본다. 다음 주 계획 세운다. 엑셀이 가장 편하다. 이중 작업 같지만 각각 목적이 다르다. 툴은 협업과 기록용. 엑셀은 실무와 분석용. 둘 다 필요하다. 주변의 시선 다른 팀 사람들은 모른다. "아직도 엑셀 쓰세요? 우리는 다 Notion으로 옮겼는데." Notion도 써봤다. 예쁘다. 세련됐다. 근데 테이블 편집이 불편하다. 수식이 제한적이다. 로딩이 느리다. 결국 엑셀로 돌아왔다. 개발자들도 가끔 비웃는다. "QA는 엑셀만 보네요." 내가 답한다. "네, 엑셀로 당신 버그 트래킹하고 있어요." 농담처럼 말하지만 사실이다. 신입 때는 부끄러웠다. 남들 다 멋진 툴 쓰는데 나만 엑셀이라고. 지금은 신경 안 쓴다. 결과가 중요하지 수단이 중요한 게 아니다. 내가 제시간에 정확하게 테스트하고, 버그 잘 찾아내고, 리포트 빠르게 만들면 된다. 그게 엑셀로 되면 엑셀 쓰는 거다. 미래는 어떨까 솔직히 모르겠다. 5년 후에도 엑셀 쓰고 있을까. 자동화 비중이 늘어나면 엑셀 쓸 일이 줄긴 할 것이다. AI가 테스트하는 시대가 오면 내 엑셀도 쓸모없어질지 모른다. 근데 지금은 아니다. 지금은 엑셀이 내 무기다. 내 작업 속도를 2배로 만들어주는 도구다. 동료가 물어봤다. "엑셀 장인 되는 게 목표예요?" 아니다. 좋은 QA가 되는 게 목표다. 엑셀은 수단일 뿐이다. 근데 지금은 최고의 수단이다. 나중에 더 좋은 게 나오면 그걸 쓸 것이다. 도구에 집착하진 않는다. 다만 지금 이 순간, 엑셀만큼 내 일을 잘 이해해주는 툴은 없다. 오늘도 엑셀을 연다 퇴근 30분 전이다. 내일 테스트 시트를 만든다. 템플릿 복사. 날짜 입력. 테스트 항목 정리. 5분이면 끝난다. 팀장님이 지나가면서 본다. "또 엑셀이네요." "네, 제일 편해서요." "그래도 자동화는 공부해야죠." "네, 주말에 강의 들을 거예요." 진짜 들을 건지는 모르겠다. 아마 또 미룰 것이다. 당장 다음 주 배포가 급하다. 엑셀 파일을 저장한다. 백업도 한다. 4년 치 데이터가 여기 있다. 내 QA 커리어가 여기 있다. 누가 뭐래도 이건 내 자산이다. PC를 끈다. 가방을 챙긴다. 내일 아침, 가장 먼저 열 파일은 이미 정해져 있다. 역시 엑셀이다.엑셀 없으면 일 못 한다. 그게 현실이다.

QA 커뮤니티 스터디 - 자동화 입문기

QA 커뮤니티 스터디 - 자동화 입문기

6시 30분 퇴근, 7시 스터디 퇴근했다. 6시 반. 구로디지털단지역 근처 카페로 간다. 스터디 7시 시작. 밥은 편의점 삼각김밥. 먹으면서 노트북 켠다. 오늘 과제: Selenium 기초.4년 차인데 아직도 매뉴얼이다. 주변 동기들은 자동화 넘어갔다. 나만 스크립트 못 짠다. 카페 도착. 5명 모였다. 다들 비슷하다. 퇴근하고 온 티. 한 명은 야근 빠지고 왔다고. 파이썬은 어렵다 스터디장이 화면 공유한다. "오늘은 XPath 선택자입니다." driver.find_element(By.XPATH, "//button[@id='login']")이게 뭔 소린지. HTML 구조 파악이 먼저래. 개발자 도구 열어본다.30분 따라 하는데 에러. "ElementNotFound Exception" 뭐가 문젠지 모르겠다. 옆 사람이 봐준다. "이거 iframe이에요." 아, 그래서 안 잡혔구나. 매뉴얼 테스트는 감으로 했다. 화면 보고 누르면 됐다. 코드는 정확해야 한다. 틀리면 바로 에러. 대충이 안 통한다. 머리 아프다. 현실은 매뉴얼 회사 돌아가면 다르다. 아침부터 빌드 테스트. 자동화? 그럴 시간 없다. 어제 배운 거 써먹고 싶다. 로그인 자동화라도. 근데 PM이 부른다. "민수씨, 긴급 테스트요." "신규 기능 내일 배포래요." 케이스 50개. 오늘 다.자동화는 저녁에. 일단 손으로 테스트. 화면 켜고 터치하고. 기획자가 묻는다. "자동화하면 빠르지 않아요?" 빠르지. 근데 스크립트 짜는 시간이. 처음 만드는 게 오래 걸린다. 케이스 50개 자동화? 2주는 걸린다. 손으로 하면 오늘 끝. 당장은 수동이 빠르다. 그게 함정이다. 스터디 3주 차 점점 어려워진다. assert 문, 예외 처리. Page Object Model. "유지보수 쉽게 하려면요." 스터디장이 설명한다. 클래스로 페이지 관리. 회사에 적용 상상해본다. 우리 앱 화면 100개. 클래스 100개? 머리 복잡하다. 그냥 하나씩 스크립트 짜면 안 되나. 안 된다고 한다. 나중에 지옥. 한 명이 말한다. "저희 회사는 자동화율 70%예요." 부럽다. "처음엔 힘들었는데." "지금은 회귀 테스트 2시간." 우리는 3일 걸린다. 개발자와의 거리 점심시간에 개발자 옆자리. "민수씨, 테스트 끝났어요?" "아직이요. 오후에." 슬쩍 물어본다. "형, 파이썬 어렵지 않아요?" "어? 쓰면 되는데." 그냥 쓰면 된다고. 나한텐 산이다. 개발자는 다른 세상 산다. 코드 리뷰 미팅. 다들 깃허브 본다. 나만 모른다. QA도 코드 알아야 한다는데. 어디까지 알아야 하나. 개발자만큼? 아니면 자동화 스크립트만? API 테스트는? 성능 테스트는? 끝이 없다. 야근 후 스터디 갈까 말까 금요일 저녁 5시. 배포 준비. 최종 빌드 확인. 스터디는 7시. 갈 수 있을까. 5시 반, 버그 발견. 치명적이다. 로그인 안 됨. 개발자 호출. 6시, 핫픽스 빌드. 다시 테스트. 7시 넘었다. 카톡 온다. 스터디장. "오늘 못 오시나요?" "죄송해요. 배포라." 이게 5주째 2번째. 빠지면 못 따라간다. 근데 어쩌나. 회사가 우선이다. 배포 망하면 내 책임. 스터디는... 나중에. 8시, 배포 완료. 모니터링 시작. 집 가면 9시 반. 내일 보충해야지. 강의 영상 있으니까. 혼자 보면 되지. 근데 혼자 보면 모른다. 질문할 사람 없다. 결국 안 본다. 동기의 이직 대학 동기한테 카톡. "형 나 이직했어." 자동화 QA로. 연봉 6천. 나보다 1800 많다. 자동화 할 줄 안다고. 부럽다. 솔직히 많이. "형도 공부해." "수요 진짜 많아." 안다. 나도 안다. 근데 안 된다. 시간이 없다. 아니, 핑계다. 퇴근하면 피곤하다. 주말엔 쉬고 싶다. 여자친구도 만나야지. 동기는 어떻게 했을까. 독하게 했겠지. 나는 안 독하다. 그게 차이다. 스터디 중간 점검 8주 차. 중간 발표. 각자 만든 스크립트 공유. 나는 로그인 자동화. 겨우 만들었다. 5개 케이스. 다른 사람들. 한 명은 전체 플로우. 20개 케이스 돌린다. "매일 1시간씩 했어요." 매일. 나는 일주일에 2시간. 실력 차이 난다. 당연하다. 투자 시간이 다르니까. 스터디장이 말한다. "천천히 가도 됩니다." "포기만 안 하면." 위로가 된다. 조금은. 회사에서의 실험 용기 냈다. 팀장한테 말했다. "자동화 좀 해보고 싶어요." "뭘 하려고?" "로그인이요. 매번 반복이라." "시간 얼마나?" 솔직히 말했다. "2주요." "2주면 수동으로 몇 번 하지?" 계산했다. 로그인 테스트 30분. 배포 전 3번. 1.5시간. 한 달이면 6시간. 2주 투자하면 다음 달부터 회수. 설득했다. "해봐." 허락 떨어졌다. 시작했다. 출근해서 1시간씩. 스터디에서 배운 거. 3일 차, 에러. "NoSuchElement" ID가 바뀌었다. 개발자한테 물었다. "이거 ID 고정 가능해요?" "왜요?" "자동화하려고요." "아, 그럼 data-testid 넣어줄게요." 협조 받았다. 신기했다. 말하니까 도와준다. 개발자도 테스트 자동화 찬성. 일주일. 로그인 자동화 완성. 돌려봤다. 30초 만에 끝. 내가 하면 5분. 10배 빠르다. 뿌듯했다. 처음으로. 코드가 일했다. 현실의 벽 2주 후. UI 개편. 디자인 전체 바뀜. 자동화 스크립트. 다 깨졌다. XPath 다 바뀜. 고쳐야 한다. 또 2일. 허무하다. 이게 유지보수구나. 스터디에서 배운 거. POM 써야 했다. 처음부터 제대로 안 했다. 급하게 짜서. 나중에 고생. 다시 짠다. Page Object로. 또 3일. 팀장이 묻는다. "민수야, 자동화 언제 끝나?" "조금만요." "다음 배포 얼마 안 남았어." "수동으로 해." 결국 손으로. 자동화는 또 밀린다. 스터디 vs 현실 스터디에서 배우는 것. 이상적이다. 깔끔한 예제. 회사 현실. 레거시 코드. 스파게티 구조. 스터디: "ID로 찾으세요." 현실: ID 없음. XPath 지옥. 스터디: "테스트 데이터 고정하세요." 현실: 매번 달라짐. 운영 DB 공유. 스터디: "CI/CD 연동하세요." 현실: Jenkins도 없음. 수동 빌드. 간극이 크다. 배운 걸 못 써먹는다. 환경이 안 돼 있다. 누구 잘못일까. 회사? 나? 둘 다. 포기 vs 지속 12주 차. 스터디 거의 끝. 수료증 받는다. 배운 건 많다. Selenium, Pytest, Jenkins 기초. 근데 실무는? 로그인 자동화 하나. 그게 전부. 3개월 동안. 동기는 벌써 이직. 나는 아직도 여기. 차이는 뭘까. 집중력. 시간 관리. 절실함. 나한테 없는 것들. 여자친구가 묻는다. "오빠 요즘 힘들어?" "응. 좀." "자동화 공부 너무 무리하는 거 아냐?" 그럴 수도. 근데 안 하면? 계속 매뉴얼. 5년 차, 10년 차 돼도. 손으로 터치. 무섭다. 작은 성취 어느 날. 로그인 자동화 돌렸다. POM 적용한 버전. 30초 만에 통과. 리포트 자동 생성. 스크린샷도 찍힘. 팀장이 봤다. "오, 이거 괜찮은데?" "다른 것도 해볼래?" "네!" 대답했다. 신났다. 회원가입 자동화. 결제 플로우 자동화. 하나씩 늘린다. 느리다. 한 달에 하나씩. 근데 쌓인다. 6개월 후. 케이스 50개 자동화. 전체의 10%. 아직 멀었다. 근데 시작은 했다. 0에서 10%. 다음은 20%. 1년 후엔 50%? 희망 생긴다. 새로운 스터디 첫 스터디 끝났다. 다음 스터디 시작. 이번엔 API 테스트. Postman, RestAssured. 또 새로운 세계. 끝이 없다. 근데 재밌다. 조금씩. 손에 익는다. 코드 보는 게 덜 무섭다. 에러도 읽힌다. "아, 이거 타입 에러구나." 성장하고 있다. 느리지만. 멈추지 않는다. 1년 후의 나 상상해본다. 1년 후. 자동화율 50%. 아침에 출근하면. 스크립트 돌리고 커피. 1시간 후 결과 확인. 실패한 것만 수동 체크. 나머지 시간은? 새 자동화 작성. 야근 줄어든다. 배포 전에도 여유. 스크립트가 일한다. 이직도 가능. 자동화 QA 포지션. 연봉 협상력 생긴다. 꿈일까. 아니다. 목표다. 동료의 변화 팀 막내가 물어본다. "선배님, 저도 자동화 배우고 싶어요." "스터디 어디서 해요?" 알려줬다. 커뮤니티 링크. 시작 방법. 2주 후. 막내가 보여준다. "제가 짠 스크립트요." 신기하다. 내가 알려주는 사람이 됐다. 몇 달 전엔 나도 초보였는데. 팀 분위기도 바뀐다. 자동화 얘기 나온다. "이건 자동화하면 어때?" 팀장도 관심 생겼다. "우리 팀 자동화율 목표 정할까?" "분기별로 20%씩." 회사가 바뀐다. 한 명이 시작하면. 번진다. 여전한 고민 물론 쉽지 않다. 여전히 야근한다. 배포 전은 여전히 지옥. 자동화해도 예외는 있다. 신규 기능은 수동. 스크립트 없으니까. 자동화 유지보수도 일. 매주 뭔가 깨진다. 고치는 시간 필요. 개발자는 여전히 빠르다. 코딩이 업인 사람들. 나는 아직 따라갈 수 없다. 연봉도 여전히 차이. 자동화해도 개발자보다 적다. QA는 그런 거래. 불공평한가. 모르겠다. 그냥 현실. 그래도 계속 퇴근 후 카페. 또 스터디 간다. 12주 과정 2회차. 피곤하다. 당연하다. 회사 다니면서 배우는 거. 근데 안 하면? 그대로다. 변하지 않는다. 동기는 이직했다. 나도 할 수 있다. 시간 문제. 늦었다고 생각 말자. 4년 차에 시작. 5년 차엔 중급. 10년 차엔? 자동화 테스트 리드. 후배 가르치는 사람. 가능하다. 포기만 안 하면. 스터디장 말이 맞다. 노트북 열고 집 와서 11시. 씻고 침대 누웠다. 노트북 연다. 오늘 배운 거 복습. 30분만. 잠들기 전. 코드 쳐본다. 에러 난다. 고친다. 작동한다. 뿌듯하다. 오늘도 한 발. 내일도 출근. 매뉴얼 테스트. 손으로 터치. 근데 저녁엔 스터디. 또 배운다. 쌓인다. 언젠간 된다. 자동화 QA. 나도 할 수 있다.퇴근 후 스터디. 느리지만 간다. 내년엔 다를 거다.

한 달에 한 번 엄마한테 전화 - 일 얘기는 못 하고

한 달에 한 번 엄마한테 전화 - 일 얘기는 못 하고

한 달에 한 번 엄마한테 전화 - 일 얘기는 못 하고 통화 버튼을 누르기까지 일요일 저녁 8시. 폰을 본다. 엄마한테 전화해야 한다. 지난달 27일에 했으니까 오늘로 딱 한 달. 더 미루면 엄마가 먼저 전화한다. 그럼 마음이 더 불편하다. 통화 버튼을 누른다. 두 번 신호음. 엄마가 받는다. "어, 민수야?" "응, 엄마." "밥은 먹었어?" 매번 같은 시작이다.일 잘 되냐는 질문 밥 먹었다고 대답한다. 김치찌개 끓여 먹었다고. 엄마가 좋아한다. 집에서 밥 해먹는다는 게. "요즘 일은 어때?" 이 질문이 온다. 매번. "응, 괜찮아." 더 할 말이 없다. 사실 지난주에 배포 전날 새벽 3시까지 일했다. 최종 빌드에서 결제 버그가 나왔다. 재현 스텝 정리하고 개발자 불러내고 핫픽스 확인하고. 집에 와서 씻지도 못하고 잤다. 그런데 엄마한테 이걸 어떻게 설명하나. "회사에서 뭐 하는 거라고 했지? 컴퓨터로 뭐 고치는 거?" 작년에 설명했다. 올해도 설명했다. 엄마는 아직도 모른다. "앱 테스트하는 거야. 버그 찾는 거." "버그? 벌레?" "아니, 오류. 프로그램 오류." "아, 그래그래. 그거 하는구나." 이해 못 한다. 나도 안다.이해시키려고 했던 때 2년 전쯤. 명절에 대전 내려갔다. 친척들 모였다. 다들 물어본다. 뭐 하냐고. "IT 회사 다녀요. QA 엔지니어요." "오, 개발자구나!" "아니요, 테스트 하는..." "아, 그것도 개발이지 뭐." 설명했다. 개발자가 만든 앱을 테스트한다고. 버그를 찾아서 보고한다고. 품질을 책임진다고. 큰아버지가 물었다. "그럼 너는 만드는 건 아니고?" "네, 확인하는 거죠." "아... 그렇구나." 공기가 미묘하게 식었다. 사촌형이 물었다. "그거 연봉은 어때?" "4천 좀 넘어요." "오, 괜찮네." 근데 사촌형 연봉은 7천이다. 개발자다. 그날 이후로 일 얘기 자세히 안 한다. 엄마가 자랑하는 것들 엄마 친구들한테는 뭐라고 하는지 안다. "우리 아들 서울서 IT 회사 다녀." 거기까지만 한다. 구체적으로 뭐 하는지는 안 말한다. 아마 모를 거다. 한 번은 엄마가 물었다. "너 회사에서 중요한 일 해?" 뭐라고 대답해야 할까. 중요하다. 내가 놓친 버그가 배포되면 큰일 난다. 유저들한테 욕먹는다. 회사 이미지 망가진다. 매출 떨어진다. 근데 개발자가 안 만들면 내가 테스트할 것도 없다. 기획자가 스펙 안 주면 나는 뭘 확인해야 할지 모른다. 나는 중요한가? 필요한가? "응, 중요하지." 그렇게 대답했다. 엄마는 만족했다.실제로 하는 일 월요일 아침. 어제 올라온 빌드 확인한다. 로그인 플로우 테스트. 회원가입 플로우 테스트. 메인 화면 로딩 체크. 이미지 깨짐 확인. 버튼 동작 확인. 텍스트 오타 확인. 오전 11시. 버그 3개 발견. Jira에 등록한다.[Critical] 결제 완료 후 화면 멈춤 [Major] 프로필 이미지 업로드 실패 [Minor] 설정 화면 레이아웃 깨짐개발자한테 슬랙 보낸다. "민호님, 결제 버그 확인 부탁드려요. 재현 스텝 Jira에 올렸습니다." 30분 뒤. 답장 온다. "제 폰에서는 안 그러는데요?" 매번 듣는 소리다. 내 폰 들고 개발자 자리로 간다. 재현한다. 1, 2, 3번 스텝. 버그 터진다. "아... 이거 iOS 14.5에서만 그러네요." "네, 그래서 디바이스 정보 적어뒀어요." "아, 확인했습니다. 수정할게요." 돌아와서 다음 테스트한다. 이게 내 일이다. 자랑할 수 없는 순간들 개발자는 자랑한다. "이번에 신기능 개발했어요. 사용자 반응 좋아요." 기획자도 자랑한다. "이번 기획으로 전환율 20% 올랐습니다." 디자이너도 자랑한다. "리디자인 후 앱스토어 평점 올랐어요." 나는? "이번 배포에서 Critical 버그 없었습니다." 박수 없다. 버그 없는 게 당연하니까. 근데 버그 나오면 내 책임이다. "QA 뭐 했어요?" 불공평하다고 생각했다. 예전에는. 이제는 안 그렇다. 이게 내 일이니까. 버그 막는 게 성과다. 눈에 안 보여도. 엄마는 걱정한다 "야근 많이 해?" "아니, 괜찮아." 거짓말이다. 지난주 야근 4일. 이번 주도 배포 있으면 3일은 할 거다. "밥은 잘 먹고 다녀?" "응, 잘 먹어." 어제 편의점 도시락 먹었다. 배포 확인하면서. "여자친구는 잘 지내?" "응, 잘 지내." 지난주에 싸웠다. 주말에 만나기로 했는데 핫픽스 때문에 취소했다. 이해해 준다고 했는데 목소리가 차가웠다. 엄마한테 이런 얘기 못 한다. 걱정할까 봐. "그래, 건강 챙겨라." "응, 엄마도." 통화 끝난다. 15분 걸렸다. 핸드폰 내려놓는다. 뭔가 허전하다. 설명할 수 없는 것들 QA 일을 설명하기 어려운 이유. 눈에 보이는 결과물이 없다. 개발자는 코드를 보여준다. 디자이너는 디자인을 보여준다. 기획자는 기획서를 보여준다. 나는? 버그 리포트? Jira 티켓? 테스트 케이스? 엄마한테 보여줘도 이해 못 한다. "이게 뭐야?" "버그 재현 스텝이요." "...그래." 그냥 모른다. 내가 매일 뭐 하는지. 얼마나 중요한지. 얼마나 힘든지. 설명해도 소용없다. 경험 안 해본 사람은 몰라. 근데 섭섭하진 않다. 이상하게. 엄마가 이해 못 하는 게 오히려 편하다. 일 얘기 안 해도 되니까. 스트레스 얘기 안 해도 되니까. "잘 지내냐?" "응, 잘 지내." 그걸로 충분하다. 실은 말하고 싶은 것들 가끔 생각한다. 엄마한테 진짜 얘기하면 어떨까. "엄마, 나 요즘 힘들어." "왜?" "배포 전에 버그 못 찾을까 봐 무서워. 배포 후에 버그 나오면 내 잘못 같아. 개발자들은 내가 일 못 한다고 생각하는 것 같아." "자동화 공부해야 하는데 시간이 없어. 경력 쌓아도 어디까지 갈 수 있을지 모르겠어. QA는 아무나 하는 거 아니냐는 소리 들으면 화나." "연봉은 개발자보다 적어. 승진도 느려. 이 일 계속해도 되는 걸까?" 이렇게 말하고 싶다. 근데 말 안 한다. 엄마가 뭐라고 할지 뻔하니까. "그럼 다른 일 알아봐." "그 일이 그렇게 힘들면 그만둬." "건강이 최우선이야." 틀린 말 아니다. 근데 위로가 안 된다. 엄마는 내 일을 모른다. 내 고민을 이해 못 한다. 그래서 말 안 한다. 그래도 전화하는 이유 한 달에 한 번. 일요일 저녁. 엄마한테 전화한다. 일 얘기는 안 한다. 밥 먹었다고만 한다. 잘 지낸다고만 한다. 15분 통화. 별 내용 없다. 근데 이상하게 마음이 편해진다. 엄마 목소리 들으면. "밥은 먹었어?" "건강 챙겨라." "잘 지내고 있지?" 이 말들이 좋다. 내 일을 이해 못 해도. 내 스트레스를 몰라도. 나를 걱정한다는 게 느껴진다. 그걸로 충분하다. 월요일 아침. 출근한다. 어제 엄마랑 통화했다는 것만으로 기분이 조금 낫다. 버그 찾으러 간다. 오늘도. 이해받지 못해도 QA 커뮤니티에서 봤다. "부모님이 내 일 이해 못 하는 게 서러워요." 댓글 많았다. "저도요." "우리 엄마는 제가 컴퓨터 수리하는 줄 알아요." "아빠가 개발자 아니냐고 계속 물어봐요." 다들 비슷하다. QA는 설명하기 어려운 직업이다. 만드는 게 아니고. 고치는 것도 아니고. 확인하는 거다. 이게 얼마나 중요한지. 얼마나 전문적인지. 경험 안 해본 사람은 몰라. 부모님도. 친척들도. 친구들도. 가끔 외롭다. 근데 괜찮다. 회사에는 안다. 내가 뭐 하는지. 개발자는 안다. 내가 얼마나 꼼꼼한지. 기획자는 안다. 내가 얼마나 스펙을 파고드는지. 같은 팀 사람들은 안다. 배포 전날 내가 얼마나 긴장하는지. 그걸로 충분하다. 엄마가 이해 못 해도. 가족이 설명 못 들어도. 내 일은 의미 있다. 다음 통화까지 다음 달. 또 일요일 저녁에 전화할 거다. 엄마가 물어볼 거다. "일은 어때?" "괜찮아." 그렇게 대답할 거다. 여전히 일 얘기는 안 할 거다. 버그 얘기도. 야근 얘기도. 개발자랑 싸운 얘기도. 그냥 잘 지낸다고만 할 거다. 근데 이제 알겠다. 엄마가 내 일을 이해하는 게 중요한 게 아니다. 내가 내 일을 이해하는 게 중요하다. 나는 안다. 이 일이 왜 중요한지. 왜 필요한지. 왜 계속하는지. 그걸로 충분하다. "민수야, 거기서 행복해?" 엄마가 가끔 물어본다. "응." 거짓말 아니다. 힘들어도. 스트레스 받아도. 인정 못 받아도. 나는 이 일이 좋다. 버그 찾을 때. 재현 스텝 정리할 때. 배포 후 모니터링할 때. 이게 내 일이다.다음 일요일에도 전화한다. 15분이면 충분하다.

Known Issue vs 진짜 버그 - 그 미세한 경계선

Known Issue vs 진짜 버그 - 그 미세한 경계선

Known Issue vs 진짜 버그 - 그 미세한 경계선 오늘도 이 질문 "민수씨, 이거 버그예요?" 개발자 재훈이가 슬랙으로 물었다. 스크린샷 첨부. 나는 이미 안다. Known Issue다. 작년에 올라왔던 거. "PROJ-2847이요. Known Issue." "아 맞다. 고마워요." 하루에 세 번은 답하는 질문이다.오전 10시, 빌드 확인 새 빌드가 올라왔다. v2.3.45. 테스트 시작하자마자 발견했다. 결제 화면에서 카드사 로고 안 나온다. 첫 반응: "이거 버그네." 두 번째 생각: "아니 잠깐, 이거 전에도..." Jira 검색했다. "결제 카드 로고" 나왔다. PROJ-3201. Status: Known Issue. 작성일: 2024년 11월 12일. Comment 6개. 마지막 코멘트: "카드사 API 문제. 우리 쪽에서 못 고침." 휴. 새 버그 등록할 뻔했다. 진짜 새 버그였던 경우 근데 어제는 달랐다. 장바구니 아이템 삭제 안 됨. 버튼 눌러도 반응 없음. Jira 검색: "장바구니 삭제" 비슷한 이슈 3개 나왔다. 다 Closed. 재현 스텝 비교했다.PROJ-2156: iOS 14에서만 발생 → 나는 iOS 17 PROJ-2489: 특정 상품에서만 → 나는 모든 상품 PROJ-2801: 네트워크 끊겼을 때 → 내 와이파이 멀쩡다른 버그다. 새 이슈 등록했다. PROJ-3412: "[iOS 17] 장바구니 아이템 삭제 버튼 무응답" Priority: High 30분 뒤 재훈이가 픽업했다. "헐 이거 진짜네요." 그날 오후에 핫픽스 나왔다. 뿌듯했다. 제대로 구분해낸 거다.Known Issue 판단 기준 내 나름의 체크리스트가 생겼다. 1단계: 키워드 검색증상 위주로 검색: "삭제 안됨", "화면 멈춤" 기능명 검색: "장바구니", "결제" 에러 메시지 있으면 그대로 검색2단계: 재현 환경 비교OS 버전 같은가 디바이스 같은가 네트워크 상태 같은가 앱 버전 같은가3단계: 타이밍 확인이 빌드에서 처음 발견했나 이전 빌드에서도 있었나 배포 후 유저 리포트 있었나4단계: 개발 히스토리최근 관련 기능 수정 있었나 연관된 다른 이슈 있나 Dependency 변경 있었나이 과정 3분. 3분이면 구분 가능하다. 애매한 케이스 근데 정말 애매할 때가 있다. 지난주 금요일이었다. 프로필 사진 업로드가 느리다. 10초 걸린다. 작년부터 계속 느렸다. PROJ-1845에 기록돼 있다. 근데 이번엔 15초 걸렸다. 이게 Known Issue의 연장선인가, 아니면 새로운 성능 저하인가. 고민했다. 5분 동안. 결론: 새 이슈로 등록. "PROJ-3425: 프로필 사진 업로드 시간 증가 (10초→15초)" 링크 걸었다. "Related to PROJ-1845" PM 수진이가 코멘트 달았다. "이거 모니터링 필요할 듯." 맞다. 트렌드가 중요하다. 점점 느려지는 건 새 문제다.버그 트래킹 시스템 활용법 우리는 Jira 쓴다. 근데 Jira는 도구일 뿐. 중요한 건 어떻게 쓰느냐다. 필터 설정"내가 만든 이슈" 필터: 내 히스토리 확인용 "Known Issue" 필터: 라벨로 구분 "현재 버전 이슈" 필터: 배포 전 체크용매일 아침 이 세 개 필터 확인한다. 라벨 활용Known_Issue: 알려진 문제 Cannot_Fix: 외부 요인으로 못 고치는 것 Low_Priority: 알지만 안 고치는 것 Regression: 재발한 버그라벨만 봐도 대충 안다. 새 버그인지 아닌지. 코멘트 히스토리이슈마다 히스토리가 쌓인다 언제 발견됐고, 왜 안 고쳤고, 재발 여부 코멘트 읽으면 맥락이 보인다신입 때는 코멘트 안 읽었다. 지금은 필수로 읽는다. 링크 연결"Duplicates": 완전히 같은 버그 "Related to": 연관된 이슈 "Blocks": 이거 때문에 못 고치는 이슈링크 따라가다 보면 전체 그림이 보인다. 중복 리포트의 민망함 작년 여름이었다. 신나서 버그 리포트 작성했다. 재현 스텝 10단계. 스크린샷 5장. 동영상까지. 올리자마자 재훈이가 코멘트 달았다. "Duplicate of PROJ-2156" Status: Closed as Duplicate. 얼굴이 화끈거렸다. 검색을 제대로 안 한 거다. 그날 이후로 무조건 검색부터 한다. 3개 키워드로. 지금은 중복 리포트 거의 안 만든다. 한 달에 한 번? 그마저도 재현 환경이 달라서 의도적으로 올리는 경우다. "이건 스펙이에요" 가장 난감한 순간이다. 내가 버그라고 생각한 게 스펙일 때. 지난달에 있었다. 로그인 화면에서 비밀번호 틀리면 에러 메시지 2초 후 사라진다. "이거 너무 빨리 사라지는데요? 버그 아닌가요?" 수진이가 답했다. "스펙이에요. UX팀에서 그렇게 정했대요." "근데 유저가 못 읽을 수도..." "알아요. 근데 스펙이에요." Jira에 올렸다. Status: Known Issue (By Design). 찜찜하지만 어쩔 수 없다. 스펙은 스펙이다. 이것도 Known Issue의 일종이다. 고칠 수 없는. 버전별 Known Issue 앱 버전마다 Known Issue가 다르다. v2.2에서는 있었는데 v2.3에서 고쳐진 것. v2.3에서 새로 생긴 것. TestRail에 버전별로 정리해뒀다. "v2.3.0 Known Issues"프로필 사진 느림 (PROJ-1845) 카드사 로고 안 나옴 (PROJ-3201) iOS 15 이하 크래시 (PROJ-2901) - 지원 종료"v2.2.8 Known Issues (Fixed in v2.3)"장바구니 간헐적 오류 (PROJ-2734) 푸시 알림 중복 (PROJ-2889)배포 전에 이 리스트 확인한다. v2.3 배포하면서 v2.2 이슈들 다시 테스트한다. 정말 고쳐졌나. 안 고쳐진 게 있으면? 그게 Regression이다. Regression의 공포 제일 무서운 게 Regression이다. 고쳐졌던 버그가 다시 나타나는 것. 두 달 전에 경험했다. PROJ-2156. 장바구니 삭제 버그. v2.1.3에서 고쳐졌다. v2.3.12 빌드에서 다시 나타났다. 헐. Regression이다. "PROJ-3501: [Regression] 장바구니 삭제 버튼 무응답 - PROJ-2156 재발" Priority: Critical. 재훈이 멘붕했다. "분명히 고쳤는데..." 코드 확인했더니 다른 기능 수정하다가 그 부분 코드를 덮어쓴 거다. 그날 밤 11시까지 핫픽스 작업했다. Regression은 Known Issue가 아니다. 새 버그다. 심각한. 팀원들 교육하기 신입 QA 지영이가 들어왔다. 3개월 됐다. 처음엔 중복 리포트 많이 만들었다. 하루에 세 개씩. 앉혀서 알려줬다. "버그 발견하면 흥분하지 마. 일단 검색." "키워드 3개로 검색해. 증상, 기능명, 에러 메시지." "비슷한 이슈 나오면 재현 환경 비교." "완전히 같으면 코멘트 달아. 새 이슈 만들지 말고." "다르면 새 이슈 만들되 Related 링크 걸어." 지금은 지영이도 중복 거의 안 만든다. 팀 전체가 이렇게 움직이면 Jira가 깔끔해진다. Known Issue 리뷰 미팅 월요일 오전 10시. 고정 미팅이다. "Known Issue Review" QA팀 3명, PM 수진이, 개발 리드 재훈이. 지난주 쌓인 Known Issue 리스트 리뷰한다. "이거 아직도 못 고쳐요?" "이거 정말 스펙 맞아요?" "이거 우선순위 올려야 하는 거 아닌가요?" 한 시간 동안 20개 이슈 검토한다. 결정:5개: 다음 스프린트에 수정 3개: 우선순위 높임 7개: Known Issue 유지 5개: Close (더 이상 재현 안 됨)이 미팅 없으면 Known Issue가 무한정 쌓인다. 유저 리포트와 Known Issue 고객센터에서 문의 온다. "결제 화면에서 카드사 로고가 안 보여요." 내가 답한다. "PROJ-3201입니다. Known Issue예요. 카드사 API 문제." 고객센터: "유저한테 뭐라고 답해요?" 나: "일시적 현상이며 결제는 정상 진행된다고 안내해주세요." Known Issue를 알면 고객 대응도 빨라진다. 매주 금요일에 Known Issue 리스트를 고객센터에 공유한다. "이번 주 알려진 이슈 5건" FAQ 작성할 때도 쓴다. 통계로 보는 Known Issue 지난 분기 통계 뽑아봤다.전체 이슈: 247개 새 버그: 183개 (74%) Known Issue 재확인: 41개 (17%) 중복 리포트: 23개 (9%)중복을 9%로 줄였다. 작년엔 20%였다. 검색 습관 덕분이다. Known Issue 처리 시간:새 버그 리포트: 평균 15분 Known Issue 확인: 평균 3분시간 절약이 크다. 한 달에 5시간. 내 Known Issue 체크리스트 매일 쓰는 체크리스트다. 포스트잇에 붙여뒀다. [ ] 키워드 3개로 검색했나 [ ] 재현 환경 비교했나 [ ] 버전 히스토리 확인했나 [ ] 코멘트 읽었나 [ ] 링크된 이슈 확인했나5개 다 체크하고 나서 결정한다. 새 버그인지 Known Issue인지. 이 습관 들이는 데 6개월 걸렸다. 지금은 자동으로 한다. 생각 안 하고. 경계선을 지키는 일 QA는 경계를 지킨다. 새 버그와 Known Issue의 경계. 스펙과 버그의 경계. 수정 가능과 불가능의 경계. 이 경계를 명확히 하는 게 내 일이다. 애매하면 물어본다. PM한테, 개발자한테. "이거 Known Issue 맞죠?" "이거 새 버그로 봐야 하나요?" 확실하지 않으면 일단 올린다. 틀려도 괜찮다. 중요한 건 놓치지 않는 것. Known Issue라고 생각했는데 새 Critical 버그면? 그게 제일 무섭다. 그래서 매번 확인한다. 검색하고, 비교하고, 판단한다."PROJ-3412 Closed. 민수씨 덕분에 빠르게 잡았네요." 재훈이 코멘트를 보니 뿌듯하다. 이 판단, 틀리지 않았다.

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

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

오늘도 버그 하나 오전 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개 잡았다. 내일은 몇 개 나올까. 기대된다.

테스트 케이스 3000개를 쓰고 나서 깨달은 것

테스트 케이스 3000개를 쓰고 나서 깨달은 것

3000개 테스트 케이스 3000개를 썼다. 정확히는 3247개다. TestRail에 다 기록돼 있다. 4년 동안 쌓인 숫자다. 처음엔 뿌듯했다. 지금은 그냥 숫자다. 어제도 케이스 20개 추가했다. 결제 플로우 개편이래서. 오늘도 15개 더 써야 한다.반복의 늪 로그인 테스트 케이스만 80개다. 회원가입은 65개. 결제는 120개. 매번 비슷하다. 정상 케이스, 에러 케이스, 엣지 케이스. 이메일 형식 체크, 비밀번호 자릿수, 특수문자 입력. 복붙하고 수정한다. 또 복붙하고 수정한다. 이게 내 일의 70%다. 신규 기능 나올 때마다 똑같은 패턴. "이 필드는 필수인가요?" "최대 입력 길이는요?" "서버 에러 나면 어떻게 되나요?" 물어보고, 케이스 쓰고, 실행하고, 버그 등록. 다음 기능 나오면 또.자동화라는 단어 팀장이 말했다. "자동화 좀 해봐." 알고 있다. Selenium, Appium, Cypress. 이름은 다 안다. 유튜브에 강의도 봤다. "Hello World" 찍는 데까지 해봤다. 그다음이 문제다. 퇴근하면 9시다. 집 가면 10시. 씻고 밥 먹으면 11시. 공부 시작하면 12시. 한 시간 보면 1시. 내일 9시 출근이다. 주말? 토요일은 빨래하고 청소하고 여자친구 만난다. 일요일은 부모님 전화하고 밀린 드라마 본다. 그러다 월요일. 테스트 케이스 30개 써야 한다는 메시지. 자동화는 다음 주로.시간이 없다는 변명 동료 하나가 자동화로 넘어갔다. 6개월 공부했다고. 연봉 800만원 올랐다. 부럽다. 나도 할 수 있다고 생각한다. 근데 6개월이 없다. 배포 주기가 2주다. 2주마다 리그레션 테스트. 핵심 케이스만 500개. 하루 8시간 테스트해도 모자란다. 야근하면 끝낸다. 공부할 시간은 어디서 나오나. 팀장은 말한다. "업무 시간에 조금씩 해." 조금씩? 오전엔 버그 재현. 오후엔 개발자 미팅. 저녁엔 빌드 테스트. 점심시간에 하라는 건가. 딜레마 자동화 안 배우면 도태된다. 알고 있다. 채용 공고 보면 다 Selenium 우대다. 근데 지금 당장은 매뉴얼이 필요하다. 이번 주 배포 앞뒀다. 누가 테스트하나. 자동화 공부하면 당장 일이 밀린다. 일 하면 공부할 시간 없다. 뫼비우스의 띠다. 유튜브에 'QA 자동화 전환' 검색했다. 다들 말한다. "퇴근 후 3개월만 투자하세요." 3개월. 90일. 하루 2시간이면 180시간. 해봤다. 3일 하고 포기했다. 배포 주간이었다. 3000개의 무게 3247개 테스트 케이스. 내 4년이다. 무게가 느껴진다. 이거 다 의미 있나? 80% 통과. 10% 페일. 10% 블락. 매번 비슷한 비율. 매번 비슷한 버그. Null 체크 안 함, 엣지 케이스 미처리. 이걸 자동화하면? 3시간이면 끝날 걸 3일 한다. 근데 자동화 스크립트 짜는 데 일주일 걸린다. 그럼 언제 본전이냐. 계산해봤다. 10번 돌려야 본전. 우리 앱은 2주마다 배포. 5개월 후 본전. 그때까지 스크립트 유지보수는? 현실 어제 신입이 들어왔다. 25살. 컴공 출신. "Python 할 줄 아세요?" 물어봤다. "네, 학교에서 배웠어요." 부럽다. 나는 독학이다. 유튜브랑 구글이 선생님. 신입한테 테스트 케이스 작성법 알려줬다. "이렇게 스텝 쪼개고요." "예상 결과는 이렇게 쓰고요." 설명하면서 생각했다. 이거 언제까지 하나. 30살 넘어서도 이거 하나. 점심 먹으면서 신입이 물었다. "자동화는 언제 배워요?" "나도 배우는 중이야." 거짓말이다. 배우는 중이 아니다. 배워야지 하는 중이다. 깨달은 것 3000개 쓰고 나니 안다. 양으로는 안 된다는 걸. 테스트 케이스 1만 개 써도 자동화 모르면 그냥 매뉴얼 QA다. 연봉 협상할 때 팀장이 말했다. "올해는 7% 인상입니다." "자동화 역량 키우시면 내년엔 더 드릴게요." 당근이다. 근데 당근 먹을 시간이 없다. 퇴근길 지하철에서 생각한다. 내년에도 똑같을 거다. "내년엔 더 드릴게요." 악순환 매뉴얼 테스트가 많으니 바쁘다. 바쁘니 공부 못 한다. 공부 못 하니 자동화 못 한다. 자동화 못 하니 매뉴얼이 늘어난다. 빠져나갈 구멍이 안 보인다. 커뮤니티에 물어봤다. "다들 어떻게 시간 내세요?" 답변들. "새벽에 일어나서 2시간." "주말에 8시간." "회사 그만두고 부트캠프." 새벽? 나는 12시에 잔다. 6시에 일어난다. 이미 수면 부족이다. 주말 8시간? 여자친구가 화낸다. "또 공부해?" 회사 그만두고? 월급 없으면 월세 못 낸다. 타협 결론 냈다. 완벽하게 전환은 무리다. 조금씩 섞어가자. 이번 주부터 시작했다. 하루 30분. 점심 먹고 30분. Selenium 기초 강의 듣는다. 한 강의가 20분이다. 10분은 따라 쳐본다. 일주일에 2.5시간. 한 달이면 10시간. 6개월이면 60시간. 적다. 그래도 0보단 낫다. 어제 첫 스크립트 짰다. 로그인 자동화. ID 입력, PW 입력, 로그인 버튼 클릭. 10줄짜리 코드. 돌려봤다. 됐다. 신기했다. 내가 짠 코드가 앱을 조작한다. 4년 만에 처음 느끼는 감정. 3000개의 의미 3247개가 무의미한 건 아니다. 이게 있어서 앱이 돌아간다. 이게 있어서 버그를 잡는다. 근데 여기서 멈추면 안 된다. 3000개는 시작이다. 끝이 아니다. 이 케이스들을 자동화하는 게 다음 단계. 느려도 간다. 하루 30분씩. 동료가 물었다. "자동화 언제 마스터해?" "모르겠어. 1년? 2년?" 중요한 건 시작했다는 것. 어제보다 오늘 10줄 더 안다. 내일은 20줄 알 것이다. 솔직한 고백 겁난다. 따라잡을 수 있을까. 신입들은 이미 Python 안다. 나는 4년 차인데 이제 시작. 늦은 건 아닐까. 커뮤니티에서 봤다. "30살에 개발 시작해서 시니어 됐어요." 위로가 된다. 동시에 압박이다. 나도 해야 한다. 매일 밤 생각한다. 오늘도 공부 못 했다고. 내일은 꼭 하겠다고. 내일 되면 또 핑계. "오늘 배포라서." "내일부터 시작." 이제 그만하려고. 핑계 대지 말자. 하루 30분, 무조건.3247개 테스트 케이스. 이제 3248번째는 자동화 스크립트다. 느리지만 간다.

스펙이에요, 버그예요? - 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의 일상이다.내일도 누군가는 물을 거다. "이거 버그 맞죠?" 나는 대답할 거다. "회의 잡을게요."