[기획자의 스프린트 경험기 - QA와 테스트 과정]

개발기간이 끝나가고, 본격적으로 QA 할 때가 되었다! 

우리회사는 QA 팀이 따로 없어서, 제품을 개발한 팀 내에서 자체적으로 QA를 진행한다. 

그래서 전문성 있는 QA는 아니었고, 냅다 맨땅에 헤딩하는 기분으로 QA를 진행했다

 

기획자로써 QA를 리딩해본건 처음이었기에 더 쉽지 않았는데, QA기간에 배우고 느낀 것들을 기록해보겠다

---

1. [QA 전 - 테스트케이스를 잘 작성하자!] 

'테스트 케이스'에 대한 정의도 명확히 잡혀있지 않은 상태였고, 스터디 하면서 작성을 했다 

테스트케이스란? 
- "명세 기반 테스트의 설계 산출물로 설계된 입력값, 실행조건, 기대결과로 구성되어 있는 테스트항목의 명세서"
- "기획에 의해 구현된 기능은 실제 사용되기 전까지는 어디가 문제가 있을지 모르고, 따라서 그 기획이 의도대로 구현되었는지 검증하는 과정"
- "한 마디로, 테스트 시 확인해야 할 부분을 상황(케이스)별로 작성한 표 정도로 해석할 수 있겠다 

 

정리하면, 정상적인 동작이 무엇인지!!를 정의하는 것이다. 

기능이 정상적으로 동작하는지, 기획할 때 잡은 정책들이 제대로 반영되었는지를 쭈르륵 작성하고, 

이것들을 하나하나 체크해가면서 정상구현이 되었는지 점검을 하게된다. 

예시

 

테케 관련 스터하며 기억에 남는 것은, "정답은 없다"는 것이다. 

회사마다, 사람마다, 상황마다 테스트케이스의 형식와 정도가 달라지며,

따라서 정답을 찾으려고 하기보다는 우리의 상황에서 어느정도의 테스트가 필요한지 고민하고 빠르게 테스트를 하는게 좋은 것 같다. 

 

 

2. [QA 진행 - only 테스트케이스만 검증해서는 안된다] 

테스트케이스는 '정상동작'을 검증하는 것이다.

그런데 만약, '정상적으로' 활용 했을때만 서비스가 멀쩡하고, 

살짝만 비정상적으로 접근해도 서비스가 빵빵 터지고 서버오류가 난다면!? -> 이건 말이 안된다. 

 

내가 여기서 말한 '비정상'은, 특별한게 아니다.

입력란에 공백을 넣거나, 데이터가 0개 나오도록 필터링 하는 것과 같은

그냥 잘 모르는 사람이 초반에 익히려고 몇번 사용하면서 충분히 시도해볼만한 상황들이다. 

 

테스트케이스 작성을 위해 몇번 만지면서 위 사실을 깨달았엇고, 그래서 아래와 같은 멘트를 qa 안내서에 작성해뒀었다

 

즉, 테케만 타 통과한다고 해서 더이상 버그가 안난다, 완성도 있는 제품이다 -> 라고 생각해서는 안된다 ! 

테케는 필수 of 필수 요건정도이고, 

테케에 없는 시나리오들도 시도를 해봐야한다. 

 

참고로 나는, 개발자분들이 QA에 참여하시면서 진짜 별의별 시나리오를 다 시도해주셔서 

진짜 기상천외한 케이스들을 발견할 수 있었다 

 

 

3. [QA 진행 - 방어적이지 말자] 

보통, 서비스를 만들지 않은 사람도 QA에 참여한다. 

이번에도 서비스를 만들지 않은 시니어개발자분들이 QA에 참여하셨는데, 

일부 개발자분들은 

테케를 기반으로 정상동작하는지 검증하는지 보다 -> '이게 왜 정상동작이야? 이상한데?' 부터 얘기를 하시는 경우가 있다. 

 

예를 들어, 

정기수집을 등록하는 기능이 있을 경우 

- 기획(정상동작) : 일 1회 정기수집이 정책임, 정각에만 정기수집을 걸 수 있음. 

- "아니 이거 일 2회 못해 ?? 그리고 왜 정각에만 걸수있어 ? 30분 단위로 하고싶으면 어떡해? 나는 스케줄을 등록하는 서비스를 사용하면서, 이런 식으로 제공하는 서비스를 보지 못했어. 왜 기본적인 것들을 제공하지 않는것이야 ? "

라는 ,, 질문과 피드백이 온다 

 

당시 나는, 

- "굳이 일 n회 정기수집 하는 것이 고객의 니즈가 아니다. (인터뷰 내용 기반)" 

- "정기수집 시간의 자유도 또한, 고객과 인터뷰했을 때 핵심니즈가 아니었다." 

- "초기 구축이고 짧은 기간에 개발해야 했기 때문에 must have인 핵심 기능에만 집중해왔고, 해당 영역은 비즈니스 임팩트에도 영향이 없고/무엇보다 추후에 개선할 수 있는 영역이기에 문제되지 않는다고 생각한다 "라는 식으로 얘기했지만, 

그래도 계속 '이건 기본이다', '그냥 일반적인 서비스들의 제공방식을 따라가면 되는데 그걸 왜 안하냐' 라는 식의 답변이 돌아와서, 

나도 짜증나서 분위기가 싸해진 적이 있다.

 

이 이후로 해당개발자의 모든질문에 점점 방어적으로 대응하고 있는 나를 발견했다. 

위 질문이 이외에 다른 질문/피드백 중에서 유용하고 필요한 사항들이 분명 많았는데, 점점 회피하고 안듣고 있던 것이다.  

 

기획자는 어떤 질문/피드백이 와도 대응할 수 있어야 한다. 

감정적이지 않아야 하고, 때로는 공격적인 피드백에도 차분히 대응할 수 있어야 한다 !!!!!! 

차분히 논리적으로 대응했는데도 동일한 얘기를 계속한다? -> 이러한 상황 또한 잘 넘기는 것도 능력이다. 

 

 

4. [QA 진행 후 - 이슈 우선순위 정리를 잘하자] 

QA 진행후에 이슈가 와라라라 많이 나올것이다. 

이 중에서는 정말 크리티컬한 이슈도 있고, 덮어두고 추후에 개선해도 되는 영역도 있다. 

이러한 이슈들을 그냥 통째로 넘기면, 개발자들이 업무 우선순위를 잡지 못한다. 

따라서, QA 진행후에 기획자가 빠르게 모든 이슈를 파악하고 우선순위를 정리하는 것이 필요하다

 

기준이 정확할 필요 없다. 

최대한 QA 진행한 날에 우선순위 정리가 될 수 있도록, 

빠르고 러프하게 우선순위를 팍팍 지정해야한다. 

 

그래야 이슈해결을 시작해나갈 수 있다 

 

 

5. [QA 진행 후 - 구현검증 vs 사용성검증 가름마 잘 타자]

우리는 '사내 베타오픈'을 진행한다. 

별의 별 이슈들이 다 나왔는데, '이걸 사내 베타오픈  전에 다 잡고갈거냐' vs '일부는 베타오픈 하고 잡아갈거냐'의 갈림길에 있었다. 

그래서 다른분께 물어봤는데, 

목적이 '구현검증' 인지 '사용성 검증' 인지를 명확히 하고, 목적에 맞는 정도까지 진행을 하라는 답변을 받았다

그래서 우리는 '구현검증' 목적의 QA라고 정의를 했고, 

크리티컬하지 않은 사용성이슈들은 사내 베타오픈하고 차차 잡아가는걸로 정리를 할 수 있었다. 

 

 

6. [QA 기간동안 중요한건, 집요함이다!]  

가장 중요한 영역이다

QA를 하면, 생각보다 많이 지치고 스트레스 받는다. 

아직 고객에게 내보내기 전인데 "이거 왜 이렇게 만들었어?", "완성도가 너무 떨어진다", "버그투성이다" 라는 부정적 피드백을 와라라ㅏㅏ 받게된다

 

나도 이러한 피드백을 듣고 스트레스를 받았었고, 잡고 잡고 잡아도 또 나오는 이슈들때문애 지치기도 했었다.

 

그래서 그만하고 싶었는데, 어쩔 도리가 없어서 그냥 했다 ! 

부정적 피드백 있어도 귀 닫고 이슈 잡고, 저번에 해결된 이슈가 다시 등장해도 다시 지라티켓 만들고,

다른 생각하지 않고 그냥 일을 했다.

 

돌이켜보면, 이런 감정은 QA하다 보면 어쩔 수 없이 겪게 되는 것 같다. 

따라서, 집요하고 끈질기게 퀄리티를 올리려고 스탠스가 필요한 것 같다