Showing Posts From

Qa의

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