기획자의 작업대

테스트 케이스, QA 요청 받은 기획자가 처음 작성하는 법 테스트 케이스, QA 요청 받은 기획자가 처음 작성하는 법 기획자의 작업대 · 실무 가이드 📌 목차 테스트 케이스란? 기획서와 무엇이 다른가 화면이 아니라 기획서에서 출발해야 하는 이유 테스트 케이스 한 줄의 구성 기획서에서 케이스 뽑는 순서 실무 팁 3가지 마무리 FAQ 프로젝트 마무리 단계에서 QA 요청을 받은 적이 있습니다. 개발된 화면을 점검하는 게 아니라, 기획한 내용이 빠짐없이 반영됐는지 확인해 달라는 요청이었습니다. 막상 시작하려니 화면을 따라가야 할지, 기획서를 따라가야 할지부터 헷갈렸습니다. 빈 엑셀 시트를 열어 두고 첫 행에 무엇을 적어야 할지 한참 고민했던 기억이 납니다. 이번 글에서는 테스트 케이스를 처음 쓰는 기획자가 어디서 출발해야 하는지, 그리고 기획서를 케이스 목록으로 바꾸는 순서를 정리해 보겠습니다. 1. 테스트 케이스란? 기획서와 무엇이 다른가 테스트 케이스(Test Case, TC)는 "이 조건에서 이렇게 하면 이런 결과가 나와야 한다"를 한 줄씩 적은 확인 목록입니다. 기획서와 다루는 대상은 같지만 질문이 다릅니다. 기획서는 "어떻게 동작해야 하는가" 를 적고, 테스트 케이스는 "그렇게 동작하는지 어떻게 확인하는가" 를 적습니다. 요리로 비유하면 기획서는 레시피이고, 테스트 케이스는 시식 체크리스트입니다. 레시피에 "소금 한 꼬집"이 있다면, 체크리스트에는 "간이 짜지 않은가"가 들어갑니다. 같은 요리를 보지만 쓰는 사람의 역할이 다릅니다. 2. 화면이 아니라 기획서에서 출발해야 하는 이유 처음 TC를 쓸 때 가장 쉽게 빠지는 함정이 있습니다. 개발된 화면을 켜 놓고, 보이는 버튼과 입...

경험 많은 기획자들이 말하는 ‘신입 시절 최악의 실수’ 7가지 "그때 그 실수만 안 했어도 밤새 기획서 수정은 안 했을 텐데…" 누구나 신입 시절엔 아찔한 순간이 있습니다. 기획자는 한 번의 판단 실수로 프로젝트 전체 흐름을 바꿀 수도 있습니다. 오늘은 경험 많은 기획자들이 직접 겪었던 ‘최악의 실수 7가지’ 를 공유합니다. 이 글을 다 읽고 나면, 여러분은 최소한 그 실수만큼은 하지 않을 거예요. 📚 목차 회의에서 ‘아는 척’ 하려다 무너진 신뢰 기획서에 스펙만 잔뜩 넣고 사용자 경험은 빠진 경우 요구사항을 확인하지 않고 ‘추측’으로 기획 피드백을 ‘비판’으로 받아들이는 태도 일정 관리 실패로 팀 전체 일정이 꼬인 사례 리스크 예측 없이 진행하다 터진 문제 커뮤니케이션 부재로 발생한 불필요한 오해 1. 회의에서 ‘아는 척’ 하려다 무너진 신뢰 신입일수록 ‘모른다’고 솔직히 말하는 용기 가 필요합니다. 모르는 걸 숨기려다 더 큰 문제를 만든 경우가 많죠. 실제 현업에서는 정확한 정보보다 명확한 커뮤니케이션 이 더 중요합니다. 2. 기획서에 스펙만 잔뜩 넣고 사용자 경험은 빠진 경우 “이 기능도, 저 기능도 넣으면 좋겠죠?” 하지만 기획은 욕심이 아니라 우선순위의 예술 입니다. 화려한 기능보다 사용자가 실제로 겪는 문제를 해결하는 설계 가 훨씬 가치 있습니다. 3. 요구사항을 확인하지 않고 ‘추측’으로 기획 프로젝트 초반, 가장 많이 발생하는 실수입니다. 클라이언트나 팀의 요구를 완전히 파악하지 않고 “아마 이런 걸 원하겠지”라고 추측하며 진행하면 결과물 수정만 세 번 이상 하게 됩니다. 4. 피드백을 ‘비판’으로 받아들이는 태도 피드백은 나를 성장시키는 거울이에요. 신입 때는 지적을 들으면 ‘내가 틀렸나?’라고 위축되지만, 실제 선배들은 ‘이 친구는 수정할 의지가 있네’라는 부분을 봅...