[고민] 테스트를 잘 완료하기 위해 꼭! 준비해야 하는 것들!!

오프닝: QA의 역할과 책임에 대한 오해와 진실 풀어보기

테스트를 다시 한번 정의하면 '테스트 활동은 결함을 발견하기 위한 활동'입니다. 품질 보증이라는 우리의 포지션 명인 QA는 다양한 테스트 활동을 통해 품질을 보증할 수 있는 데이터를 상품의 출시나 서비스의 오픈을 판단할 수 있도록 데이터를 수집하고, 제공해야 하는 것이 QA라는 포지션의 사람들이 해야 하는 숙명이라 생각합니다. 😂(숙명까지는 아니더라도??)

 

누군가는 QA가 출시의 판단 여부를 결정해도 되지 않느냐 물어보는 경우도 있었습니다. 개인적으로는 회사에는 제품과 서비스를 책임지는 포지션은 회사마다 조금은 차이가 있겠지만 일반적으로 명확히 R&R(Role and Responsibilities)에 명시되어 있을 겁니다.

QA 역할과 책임에 대해서 한번쯤 고민하기

 

프로덕트 단위에는 PM(Project Manager)이 있을 것이고, 기능 단위에서는 PO(Project Owner)라는 포지션을 가진 사람들 최종 책임이 있는 사람이라 생각합니다. 물론 소규모의 회사일수록 C레벨 분들의 판단하에 출시나 배포가 진행되는 경우가 있긴 합니다. 출시나 배포 후 문제가 발생했을 때 책임을 묻는 사람은 다름 아닌 PM이나 PO일 것입니다.

 

그렇다면 QA에게는 무엇을 물을까요? 어떤 책임을 지고 업무를 수행해야 할까요? 업계에 좀 오래 계신 분들은 "테스트 안 하고 뭐 했어?"라는 말을 지나가면서 누군가에게 들어 보셨을 거로 생각합니다. 명확하게 QA에게는 테스트 관련된 책임과 품질에 대한 책임을 묻는 것이 일반적입니다. 이것은 프로덕트나 프로젝트와 관련은 있지만 출시나 배포의 책임이라 볼 수는 없는 부분입니다. 😁

 

이런 부분도 QA나 테스터의 포지션에 있는 사람들의 입지가 올라오지 않은 상황에서 최종적으로 인수 테스트 영역에서 테스트를 많이 했던 시절의 이야기라 생각합니다. 지난 일들을 생각해 보면 '마지막에 네가 테스트했으니까 네 책임이야'하는 매우 단순한 논리에서 발생한 오해이지 않을까 싶습니다.

 

지나간 OO 회사의 면접에서 있었던 일입니다. QA가 배포의 판단을 하면 안 된다고 작성한 과제의 한 부분에 관해서 토론 아닌 토론을 했던 경험이 있는데요. 물론 저의 자세는 위의 논리대로 말씀드렸지만, 그 회사는 배포의 판단을 QA의 권한이라고 생각하는 조직? 회사였던 것 같았습니다. (이런 식의 면접은 안 봐도 결과는 불합격이죠 😶‍🌫️)

면접은 항상 어려운 것

 

"출시나 배포의 판단을 QA가 한다?"가 잘못된 정의는 아닙니다. QA나 테스터 혹은 마지막으로 테스트했던 누군가의 책임을 회피하려는 것도 아닙니다. 여기서 중요한 것은 R&R이 명확히 해서 업무를 수행해야 한다는 것입니다. 그리고 출시나 배포 후 발생하는 문제는 개인적으로 프로젝트에 참여한 모든 사람이 책임을 나누어야 한다고 생각합니다. 또한, 책임을 운운하기보다는 발견된 문제를 빠르게 해결하려는 방법을 미리 계획해 두는 것이 바람직한 운영/유지 보수를 대비하는 자세가 아닐까 싶습니다. 👌

 

프로젝트의 테스트를 잘 수행하기 위한 방법은 아래 블로그를 참고해 주세요

[준비] 프로젝트 종료까지 관리되는 테스트 계획서 작성하는 방법 공유!!

 

테스트를 시작하기 위해서 꼭!! 준비해야 하는 항목들

테스트 분석을 통해 우리는 프로젝트에 어떤 테스트가 필요한지를 알게 되었을 겁니다. 이게 무슨 소리냐고요? 아래 블로그도 참고해 달라는 것이지요 🤣

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

 

테스트를 분석하고 설계하였다면 이제는 실제 테스트를 하기 위해 준비를 해야 합니다. 가장 중요한 것은 자신만의 기준을 만들어야 합니다. 물론 회사에서 해야만 하는 테스트 관련 기준이 있다면 매우 좋습니다. 하지만 대부분 테스트에 대한 기준 수립과 정립을 QA나 테스트 엔지니어에게 기대기 마련입니다. 저는 테스트에 대한 기준을 "QA나 테스트 엔지니어 자신의 테스트 만족도"라 생각합니다.

 

"내가 만족할 만큼 테스트했는가? 이정도 테스트했으면 문제없을 것 같다."라는 마음이 생길 때까지 테스트하려는 기준을 가슴속에 만드는 것입니다. 저는 개인적으로 '내가 테스트했으면 쪽 팔리면 안 된다.'라는 생각을 조금은 테스트가 익숙해지는 시점에 하기 시작했습니다. 이런 마음가짐은 자신을 좀 더 몰아치게 되고 스킬업 하는 동기부여가 되기도 합니다. 간혹 출시 후 이슈가 발생했다면 어디서 테스트가 부족해서 생긴 문제인지 다시금 생각하는 시간을 가질 수도 있습니다.

 

마음가짐이 생겼다면 이제 실제적인 테스트 준비를 해야 합니다. 😘

제가 생각하는 테스트 수행 전 꼭 준비해야 하는 항목은 세 가지입니다.

테스트를 잘 하기 위해 중요한 것 세 가지

 

👍 첫 번째, 테스트 환경을 준비해야 합니다. 테스트 케이스를 수행할 수 있는 환경이 잘 준비되어 있는지 최대한 명확하게 확인하는 것이 좋습니다. 확인을 최대한 하더라도 막상 테스트를 시작하게 되면 환경이 도와주지 않아 테스트 케이스 결과에 N/A(Not Available) 많아질겁니다. 테스트 환경은 인프라적 요소일 수도 있고, 임베디드 환경이나 테스트 기기가 없는 등의 환경을 이야기합니다. 예를 들면, 이번 안드로이드 최소 버전을 10으로 올렸다면 10 버전이 설치된 기기가 미리 준비되어 있어야 하는 것이 대표적인 사례일 것 같습니다.

 

크게 보면 개발 서버와 운영 서버만 분리되어 테스트하는 동안 코드 프리징되지 않고, 테스트를 수행하는 중에도 배포가 됩니다. 그러면 매우 불안정한 상황에서 테스트를 수행하게 되고 이런 부분도 환경적인 요소의 부재라 할 수 있습니다. 꼭! 코드 프리징된 상태에서 변경 점을 파악하면서 테스트를 수행해야 '이전 버전에서는 잘됐는데 이번 버전에서 왜 안되?' 상황을 줄일 수 있습니다. 저는 이런 상황을 '리그레이션이 무너졌다'라는 표현을 쓰기도 하는데요. 변경 관리가 안 되면 충분히 발생할 수 있는 부분이니 꼭 명심하시길 바랍니다.

 

제일 좋다고 생각하는 개발 환경 구성은 개발/스테이징/운영으로 환경이 분리된 상태에서 테스트를 수행하는 것이 가장 바람직한 환경 세팅이라 생각합니다. 스테이징 기준으로 테스트가 완료되면 변경 없이 바로 운영으로 배포될 수 있도록 환경이 구성되어 있어야 합니다.

테스트 환경의 중요성

 

N/A라는 용어가 나와서 좀 더 첨언을 하자면 N/A 항목도 하나의 테스트 Fail로 봐야 합니다. 테스트 케이스에 대한 이야기는 다음 섹션에 자세히 다루겠지만 요구사항에 대해 확인하지 못한 부분이기 때문에 N/A 항목을 Fail로 생각하고 테스트 결과 리포트에 별도의 목록으로 제공해야 합니다.

 

저도 미처 생각하지 못했던 부분이었는데 교원에 재직 당시 프로젝트를 수행하면서 품질률을 측정할 때 N/A 항목이 매우 중요하다는 깨달은 부분입니다. 가장 명확한 것은 N/A 항목도 이슈로 등록하는 것이 좋겠지만 한두 개가 아니라면 목록화해서 공유하는 것도 괜찮습니다. 다만 N/A 사유가 명확해야 합니다.

 

👍 두 번째, 테스트 데이터를 준비해야 합니다. 테스트 데이터도 환경과 마찬가지로 테스트 수행 시점에 발견되는 경우가 많습니다. 이 부분은 환경과는 조금 다르게 테스트 케이스를 작성하면서 보완할 수 있고, 준비할 수 있는 부분입니다. 더미 데이터를 미리 생성해 둔다던가 테스트 케이스의 조건에 맞는 데이터를 생성해 둘 수 있습니다. 데이터가 없다면 백엔드 개발자에게 요청해서 미리 데이터를 준비할 수 있도록 해야 합니다. 이것도 데이터 부재로 테스트 케이스를 수행할 수 없다면 N/A로 결과를 입력하게 됩니다.

 

👍 세 번째, 커뮤니케이션을 맞춰야 합니다. 이건 정말 조직마다 케바케일 수 있고, 도메인에 따라 사용하는 용어가 다르기 때문에 사소한 용어라도 서로 의미를 다르게 사용하고 있다면 최대한 커뮤니케이션에 문제가 없도록 사용하는 용어를 맞춰야 합니다. 예를 들면, 저는 N/A로 테스트 못 한 결과를 입력하지만, 어떤 분들은 N/T(Not Test)로 용어를 사용하기도 합니다. 프로젝트를 수행하는 데 있어서 혹은 더 넓게 소속되어 있는 회사에서 사용하는 용어는 꼭 맞춰서 커뮤니케이션할 수 있도록 준비하시기를 바랍니다.

커뮤니케이션이 일치하지 않으면 요구사항은 산으로 간다

 

위 세 가지만 미리 잘 확인하고 챙기신다면 테스트 수행하는 시점에 N/A 항목을 최소화할 수 있을 거로 생각합니다. N/A가 적다는 것은 요구사항에 대해서 최대한 검증을 해놓은 상태이기 때문에 기능적으로는 문제가 없다는 것을 자신 있게 얘기할 수 있는 상황일 것으로 믿어 의심치 않습니다. 😊

 

"소프트웨어 테스트의 완료는 곧 나의 자신감이다."

 

긴 글 읽어 주셔서 감사합니다. 😍

 

관련 참고 자료

[테스팅] QA, 테스트 엔지니어와 개발자 하는 테스트는 왜 다른가?

테스트케이스 작성 및 요구 검증 수행해 드립니다. - 크몽

요약 : 투잡, n잡, N잡, 크몽부업, 부업, 부수익, kmong부업, 전자책, vod, 유튜브