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

오프닝: 테스트를 분석한다고? 무엇을 설계한다는 거야?

😉 잡썰

제가 가장 잘하는 영역인 테스트에 대한 이야기를 해보려 합니다. 블로글 외에도 전자책도 준비하고 있습니다. 물론 블로그에 모두 담지 못하는 내용들로 가득 채워서 작성하고 있습니다.🤣 2024년부터 조금씩 준비하고 있었는데 올해는 어떻게든 완성을 해보려 합니다.

QA는 단순히 테스트만을 얘기하는 것은 아니다

🤔 본론의 시작

처음 시작은 가볍게 테스트에 대한 분석과 설계에 대한 이야기를 해보려 합니다. 테스트를 분석하고 설계 한다는 것은 앞으로 우리가 어떤 테스트 방법을 통해 어떻게 이슈를 발견할지를 결정하는 매우 중요한 부분입니다. 대부분의 QA나 테스트 엔지니어는 이 부분을 생략하고, 기획서나 화면 설계서, 스토리보드, 최근에는 피그마 문서 작성이 완료된 시점에 바로 테스트 케이스를 작성하고 있으실 겁니다.

 

잘못된 방법이라기보다는 좀 더 올바른 방법, 혹은 목적을 명확히 하는 테스트를 위해서는 반드시 테스트를 분석하고 설계 과정을 거치는 것을 추천합니다.

 

그래서 테스트 분석은 무엇이냐? 제가 생각하는 테스트 분석은 요구사항을 보고 어떤 테스트를 수행해야 커버 가능한... 그러니까 보통 QA가 말하는 커버리지인 그물망을 좀 더 촘촘히 할 수 있는 방법을 찾아내야 합니다. 이것과 동시에 이뤄지는 것이 바로 테스트 설계인 것입니다. 

 

참고로 품질 보증과 테스트는 다릅니다. 캠패인과 같이 얘기하고 있는데 간단하게 설명하면 우리는 최종적으로 품질 보증을 위해 다양한 테스트 활동을 하는 것으로 정의할 수 있습니다. 여기서 테스트 활동은 ISTQB에서 정의하는 모든 테스트 설계 기법이 해당합니다.

 

ISTQB 실라버스의 테스트 설계 기법의 분류표

 

그렇다면 위의 모든 설계 기법을 알아야 실무에 적용할 수 있는가는 아닙니다. 우리는 무의식적에 테스트 설계 기법을 테스트케이스에 녹여서 작성하고 있기 때문인데요. 역으로 작성된 테스트케이스를 보면 동등 분할이나 경계값 분석 등 관련 케이스가 있다는 것을 알 수 있습니다. 

 

다만, 여기서 중요한 것은 동등 분할이든 경계값 분석이 꼭 필요한 케이스에 활용할 수 있도록 분석 활동이 필요하다는 점입니다. 

 

테스트 분석과 설계를 꼭 해야 하나?

테스트 분석을 하려면 두 가지 조건이 필요하다고 생각합니다.

 

첫 번째, 어느 정도의 테스트 설계 기법에 대해서 알고 있어야 합니다. 위에서도 잠깐 이야기했지만, 모든 방법을 다 알아야 하는 것은 아닙니다. 도메인이나 플랫폼 등 특성에 맞는 테스트 설계 기법이나 활용도가 높은 기법을 어느 정도는 알고 있어야 합니다. 혹은 내 노하우를 가장 잘 활용할 수 있는 테스트 설계 기법(필살기?)을 알고 있으면 좋습니다.

 

두 번째, 도메인 지식입니다. 도메인 지식이 없는 신입이나 이직 했는데 전혀 다른 분야라면 꼭 도메인 지식을 습득할 수 있도록 내부 교육을 받거나 관련 문서를 읽어야 합니다. 하지만 이것도 우리는 자연스럽게 너무도 익숙하게 알고 있습니다.

 

왜냐하면 신입은 신입이기 때문에 어느 정도 커리큘럼이 있거나 온보딩이 잘 되어 있을 것이기 때문인데요. 문제는 경력이 이직했을 때인데 이것도 이직하는 회사의 조사를 어느 정도 하고 면접을 봤을 것이기 때문에 큰 문제가 없습니다. 혹은 관련 도메인에 재잭 중인 지인 한 명쯤은 있을 거라 수습 기간 내에는 도메인 지식을 습득하는 데 큰 문제는 없을 거로 생각합니다. 

 

그렇다면 테스트 설계를 어떻게 해야 할까요? 간단하면서도 쉽지는 않은 것 같습니다. 꼭 해야 하나? 라는 의문부터 생길 테니까요. 만약 지금 이 글을 읽고 있는 분이 사회 초년생이라면 요구사항을 읽어보고, 혹은 화면 설계서나 스토리보드를 보고 마인드맵이나 다이어그램을 그려보시길 추천해 드립니다. 특히 도메인 지식이나 플랫폼에 대한 특성 정보가 부족하다면 더더욱 해봐야 합니다.

 

처음에는 연습이 필요합니다. 나중에 테스트케이스를 작성하는 것도 마찬가지인데요. 익숙해질 때까지 도구를 통해 테스트를 분석과 설계하는 방법을 습득해야 하는 것입니다. 요구사항을 확인하기 위해서 어떤 테스트 방법이 커버리지를 최대한 끌어 올릴 수 있다고 분석이 되었다면 마인드맵 등을 이용해 설계를 해봅니다. 

마이드맵 도구를 이용한 테스트 설계 예시

 

설계하면서 꼭 필요한 부분은 기능의 연관성입니다. 물론, 최근에 피그마를 통해 작성하는 디자인 문서에는 기능에 연관성을 한눈에 볼 수 있도록 작성하는 기획자나 디자이너가 있긴 합니다. 하지만, 우린 가장 좋은 상황은 배제하자고요. QA는 항상 최악의 상황에서 최고의 상황을 만들어야 본전을 하는 거니까요. 😭

 

연관성을 찾다 보면 어떤 테스트가 필요할지 보이게 됩니다. 예를 들어 A 페이지에서 B 페이지가 넘어가는 순간 페이지 로딩이 필요한 부분이라면 성능 기준이 명시되어 있어야 하고, 성능 테스트는 어떻게 해야 할지를 고민해 보는 것입니다. 또 다른 경우로는 A라는 기능이 a, b, c 플랫폼에서 네이티브로 개발된 부분이라고 한다면 a, b, c에 대한 테스트케이스는 어디에 작성해야 테스트 흐름을 망치지 않고, 테스트를 수행할 수 있을지 고민하는 것입니다.

 

이러한 고민들을 할 수 있도록 테스트를 설계해야 합니다. 위 이미지에서도 볼 수 있듯이 노란색으로 되어 있는 부분은 테스트 환경 부재 혹은 테스트 데이터 부재로 인해 테스트할 수 없는 영역인 것을 설계 단계에서 미리 알 수 있었습니다. 그러면 해당 케이스가 작성되기 전에 테스트할 방법을 개발팀에 공유하고 최대한 배포 전 테스트가 될 수 있도록 상황을 만들어야 하는 것입니다.

 

물론 사회 초년생은 잠깐 언급했듯이 이러한 상황들이 익숙해질 때까지 연습해야 합니다. 그러면 경력이 꽉 찬 저와 같은 사람들은 어떻게 해야 하나요?라고 물어보실 수 있겠죠? 물론 필요하다면 문서를 정리해야 합니다. 다만, 선택이 될 뿐인 거죠. 😎

익숙해질 때까지 해보는 거야

 

제가 생각하는 설계 단계의 스킵은... 우선 분석은 필수입니다. 분석해야 설계 단계를 스킵할 수 있을지 판단할 수 있기 때문입니다. 그래서 설계 단계의 스킵을 하는 조건은 도메인 지식이 많이 알고 있거나 해당 신규 개발이나 수정 개발되는 영역의 영향 범위를 명확하게 알고 있다면 생략이 가능합니다.

 

또 하나는 관리자로 계신 분들도 후배님들을 위해 분석과 설계에 대한 방법을 알려주고, 리뷰를 통해 좀 더 그물망이 촘촘해질 수 있는 테스트 설계가 될 수 있도록 가이드를 해주는 것도 하나의 역할이 되지 않을까 생각합니다. 나만 알면 자료이고 모두가 알면 지식이 되니까요. 😁

 

간단하게 테스트를 분석과 설계하는 방법에 대해서 알아보았습니다. 상세 테스트 설계 기법은 개인적으로 공부해 보시길 바랍니다. 'ISTQB 테스트 설계 기법'으로 구글링만 해도 많이 나오고, GPT한테 물어봐도 잘 설명해 줍니다.

 

앞으로 조금씩 하나하나 5분 이내에 읽을 수 있는 테스트 지식에 대해서 제가 알고 있는 정보를 공유해 드리도록 하겠습니다. 읽어 주셔서 감사합니다. 😍

---

관련 참고 자료 및 서비스

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

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

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