QArchive

QA는문제를 가장 먼저 본다.그렇다고가장 먼저 말해야 하는 건 아니다.이 지점을 이해하지 못하면QA는항상 옳지만항상 피곤한 사람이 된다.QA 커뮤니케이션에서타이밍은내용만큼 중요하다.같은 말을 해도언제 하느냐에 따라전혀 다른 결과를 만든다.설계 단계구현 중테스트 막바지릴리즈 직전이 타이밍은각각받아들일 수 있는 말의 범위가 다르다.설계 단계에서QA가 말해야 할 것은버그가 아니다.리스크다.이 구조는나중에 꼬일 수 있다이 설계는테스트 비용이 높다이 흐름은유저 이탈을 부를 수 있다이 시점에서구체적인 버그를 말하면QA는 무시된다.왜냐하면아직 만들어지지 않았기 때문이다.구현 단계에서QA가 말해야 할 것은방향 이탈이다.설계와 다르게 가고 있다예외 처리가 빠졌다상태 관리가 위험하다이때 QA가전체를 뒤집는 말을 하면조직은..

QA 리포트를 떠올리면대부분 이런 이미지를 생각한다.버그 목록재현 절차스크린샷로그물론 필요하다.하지만 이건리포트의 절반이다.QA 리포트의 진짜 목적은정보 전달이 아니다.결정을 끌어내는 것이다.조직에서리포트가 소비되는 방식은 단순하다.다 읽지 않는다핵심만 본다결국 “그래서?”를 묻는다QA 리포트가이 질문에 답하지 못하면그 리포트는읽혔어도 작동하지 않는다.QA가 자주 빠지는 함정이 있다.“팩트는 다 적어놨습니다.”팩트는 중요하다.하지만 팩트는결정을 대신 내려주지 않는다.조직은팩트 다음을 원한다.이걸 지금 고쳐야 하나넘겨도 되는가나중에 하면 안 되는 이유는 무엇인가QA 리포트는이 질문에 답하는 문서여야 한다.그래서QA 리포트는구조부터 달라야 한다.❌ 현상 중심 리포트어떤 오류가 발생한다이런 조건에서 재현된다⭕..

QA를 하다 보면한 번쯤은 이런 경험을 한다.문제를 분명히 말했는데근거도 설명했는데결국 반영되지 않는다그리고 나중에그 문제가 그대로 터진다.이때 QA는이렇게 생각한다.“내가 말했잖아.”하지만 조직은이렇게 기억한다.“그때는 그렇게까지 심각해 보이지 않았어.”QA의 말이 무시당하는 이유는QA가 틀려서가 아니다.QA의 말이조직의 언어로 전달되지 않았기 때문이다.QA는문제를 본다.조직은결정을 한다.이 둘의 언어는같지 않다.QA는이렇게 말한다.여기서 오류가 발생합니다이 조건에서 재현됩니다이 상태가 꼬입니다하지만 이 말은결정을 끌어내지 못한다.왜냐하면조직이 듣고 싶은 질문에답하지 않았기 때문이다.조직은이걸 묻는다.그래서 지금 뭘 해야 하지?안 하면 뭐가 문제지?이걸 고치면 무엇을 얻지?QA가 이 질문에 답하지 못하..

유저 이탈을 이야기할 때사람들은 보통 이렇게 말한다.콘텐츠가 부족해서밸런스가 안 맞아서운영이 별로라서이 말들은어느 정도 맞다.하지만 이 말들이 등장하기 전에이미 끝나버린 유저들이 있다.아예 들어오지 못한 유저들이다.진입 장벽은불편함의 문제가 아니다.진입 장벽은차단의 문제다.실행하기 전에플레이를 이해하기 전에재미를 느끼기도 전에유저는판단을 끝낸다.QA가 이 지점을 보지 못하면게임은존재하지 않는 것과 다르지 않다.진입 장벽 QA가항상 늦어지는 이유는 단순하다.기능은 정상이고,버그는 없고,시스템은 돌아간다.그래서 이렇게 결론 난다.“문제 없어 보입니다.”이 문장은QA 내부에서는 통과지만,유저에게는거절 통보다.진입 장벽의 대부분은기능 문제가 아니다.첫 로딩이 길고설명은 많은데 맥락이 없고선택을 강요하고실패하면 ..

비기능 QA를 하다 보면이런 말이 종종 나온다.“문제 없었습니다.”“재현되지 않았습니다.”“테스트 환경에서는 괜찮았습니다.”이 말들은사실일 수 있다.그리고 동시에가장 위험한 말이기도 하다.비기능 QA에서문제가 없었다는 말은문제가 없다는 증거가 아니다.그건그 테스트가운이 좋았다는 뜻일 뿐이다.운이 좋은 테스트에는공통점이 있다.테스트 환경이 너무 안정적이고조건이 단순하며시간도 짧고변수가 적다이 환경에서는대부분의 비기능 문제는잠들어 있다.QA가 테스트를 끝냈다고 느끼는 순간에도문제는아직 모습을 드러내지 않았을 뿐이다.비기능 문제는스스로 나타나지 않는다.조건이 겹치고시간이 쌓이고환경이 흔들릴 때그제서야고개를 든다.그래서비기능 QA는항상 이렇게 오해받는다.“왜 그때는 못 잡았죠?”정답은 간단하다.그때는 운이 좋았..

네트워크 QA를 이야기하면가장 먼저 떠올리는 장면이 있다.연결이 끊긴다에러 메시지가 뜬다재접속이 필요하다그래서 많은 테스트가이 지점에서 끝난다.“끊겼을 때 어떻게 되는지 확인했습니다.”하지만 이 테스트는네트워크 QA의 절반에도 미치지 못한다.네트워크 문제의 대부분은끊어지지 않은 상태에서 발생한다.연결은 유지되는데반응이 늦고결과가 어긋난다이 상태가가장 위험하다.왜냐하면시스템은 정상이라고 판단하고,유저는 이상하다고 느끼기 때문이다.네트워크 QA에서가장 먼저 버려야 할 생각은 이것이다.“연결만 유지되면 된다.”연결은조건일 뿐이다.QA가 봐야 할 것은연결 상태에서무엇이 보장되는가다.요청은 반드시 처리되는가응답은 순서대로 오는가실패했을 때 복구 경로가 있는가이 질문을 하지 않으면네트워크 QA는단순 체크가 된다.네..

업데이트 QA를 이야기하면이런 이야기가 들려온다.“기존 기능만 다시 보면 되죠.”“변경된 부분 위주로 확인하면 되잖아요.”이 말들은효율적으로 들린다.그리고 대부분의 사고는이 말에서 시작된다.업데이트는기능을 조금 바꾸는 일이 아니다.업데이트는이미 쌓여 있던 모든 상태 위에새로운 조건을 얹는 일이다.업데이트 QA가 어려운 이유는 단순하다.기존 데이터가 있고기존 상태가 있고기존 유저 행동 패턴이 있다이 위에새 코드와 새 규칙이 올라간다.문제는이 조합이테스트 환경에서는절대 그대로 재현되지 않는다는 점이다.업데이트 QA에서가장 흔한 착각은 이것이다.“신규 기능은 정상입니다.”신규 기능이 정상이어도문제는 발생한다.왜냐하면대부분의 업데이트 이슈는신규 기능이 아니라기존 것과의 충돌에서 발생하기 때문이다.예를 들어 보자..

장시간 플레이 QA라고 하면대부분 이런 그림을 떠올린다.게임을 켜 둔다몇 시간 돌려본다크래시가 나지 않으면 OK그리고 이렇게 말한다.“3시간 돌려봤는데 문제 없었습니다.”이 문장은안심을 주는 말처럼 보이지만,QA 입장에서는가장 불안한 말 중 하나다.장시간 플레이 QA는시간을 많이 쓰는 테스트가 아니다.장시간 플레이 QA는시간이 문제를 어떻게 만들어내는지관찰하는 테스트다.이 차이를 이해하지 못하면아무리 오래 돌려도아무것도 잡지 못한다.시간은새로운 문제를 만들지 않는다.시간은이미 존재하던 구조적 문제를드러낼 뿐이다.누적되는 연산정리되지 않는 데이터해제되지 않는 리소스복구되지 않는 상태이 요소들은짧은 테스트에서는절대 모습을 드러내지 않는다.그래서 장시간 플레이 QA의 출발점은“몇 시간을 돌릴 것인가”가 아니다..