TL;DR

  • 미니 테스트 계획(Mini Test Plan)은 범위가 작거나 중간 규모인 변경 사항에 간결한 계획을 적용해 QA 속도를 늦추지 않으면서 테스트 누락을 줄이는 방식임.
  • Jira 티켓 안에서 위험, 테스트 유형, 영향 범위, 플랫폼·기기·운영체제, 비기능 요건을 점검함.
  • 별도 문서나 추가 절차 없이 티켓에 구조화된 계획을 남겨 테스트 범위와 부작용을 고려함.
  • 티켓 복잡도와 완성도에 따라 작성 시간은 10~30분이며, 테스트를 의도적으로 수행하도록 돕는 방식임.
  • Jira의 필수 댓글 형식이나 티켓 워크플로에 포함하면 책임성과 테스트 명확성을 높일 수 있음.

미니 테스트 계획을 사용할 때와 QA가 이를 자주 건너뛰는 이유

  • 모든 기능에 정식 테스트 계획이 필요한 것은 아니지만, 계획 자체는 항상 필요함. 미니 테스트 계획은 무계획과 과도한 절차 사이의 절충안임.
  • 다음과 같은 경우에 적합함.
  • 기능 범위가 작거나 중간 규모임.
  • 정식 QA 테스트 계획을 요청받지 않음.
  • 티켓을 담당하는 QA가 한 명뿐임.
  • 변경 사항이 단순해 보이지만 부작용이 숨어 있을 수 있음.
  • QA는 이런 상황에서 테스트 계획이 불필요하다고 느껴 생략하는 경우가 많지만, 바로 이때 실수가 생길 수 있음.
  • 변경 사항을 테스트하는 데 무엇이 필요한지 충분히 생각하지 않은 채 자신의 이해를 전제로 삼으면 테스트 범위를 놓칠 위험이 큼.
  • 미니 계획은 테스트 전에 잠시 구조를 세워 모든 측면을 고려하고 다루도록 하며, 진행 속도는 늦추지 않음.

미니 테스트 계획이 중요한 이유

  • 테스트는 실행뿐 아니라 생각하는 과정이기도 함.
  • 미니 테스트 계획은 빠르게 진행되는 테스트에도 다음 요소를 포함함.
  • 위험 인식
  • 명확한 범위
  • 테스트 범위에 대한 합의
  • 부작용 인식
  • 다음 날 자리를 비울 때를 고려한 인수인계 또는 가시성 개선

미니 테스트 계획 템플릿

  • 다음 항목을 Jira 티켓의 댓글이나 사용자 지정 ‘Test Plan’ 필드에 직접 두는 방식을 권장함.
  • 이번 변경 사항의 위험은 무엇인가?
  • 어떤 테스트 유형을 다룰 것인가? 예: UI, API, 회귀, 스모크, 탐색적 테스트
  • 범위 밖에서 테스트해야 할 종속 요소나 영향 범위는 무엇인가?
  • 어떤 플랫폼·기기·운영체제 버전을 다뤄야 하는가?
  • 어떤 비기능 측면을 테스트해야 하는가? 예: 성능, 접근성, 분석 이벤트, 로그
  • 작성에는 티켓의 복잡도와 완성도·품질에 따라 10~30분이 걸리며, 사고방식을 “그냥 테스트하기”에서 “의도적으로 테스트하기”로 바꾸는 데 도움이 됨.

실제 사례

  • iOS 앱의 체크아웃 버튼 동작을 소규모로 변경하는 경우 미니 계획은 다음과 같은 형태임.
  • 위험
  • 새 로직이 Apple Pay 흐름을 깨뜨릴 가능성
  • 작은 화면에서 UI가 이동할 가능성
  • 테스트 유형
  • UI 검증
  • 결제 흐름 회귀 테스트
  • 엣지 기기에서 탐색적 테스트
  • 영향 범위
  • Apple Pay
  • 게스트 체크아웃
  • 장바구니 API 호출
  • 플랫폼
  • 작은 화면의 iPhone SE에서 iOS 17
  • iPhone 13에서 iOS 17
  • iPad 호환성은 영향받지 않으므로 제외
  • 비기능 항목
  • 새 이벤트의 로그가 올바르게 발생하는지 확인
  • 로드 시간에 대한 간단한 성능 점검

핵심 요점

  • 계획을 잘 세우기 위해 방대한 템플릿이 필요한 것은 아님. 미니 테스트 계획은 품질을 희생하지 않으면서 유연성을 제공하고, 테스트 범위 누락을 빠르게 방지하는 방식임.
  • 빠르게 움직이는 팀에서도 이 습관은 ‘테스트 실행’을 신중한 작업으로 바꿈.
  • QA 워크플로에 이를 포함하는 방식을 권장함. QA 리더라면 Jira의 필수 댓글 형식으로 추가하거나 티켓 워크플로에 포함하는 방안을 고려할 수 있음. 이를 통해 책임성과 테스트 명확성이 즉시 향상됨.