Testmap 으로 테스트하기 (feat. FigJam)

Hardin Park·2022년 9월 12일
0
post-thumbnail

안녕하세요, QA 엔지니어 Hardin 입니다.

더 효율적으로 QA 할 수 없을까?

저는 얼마 전부터 짧은 주기로 진행되는 스프린트에서 QA 엔지니어가 어떻게 하면, 빠르고 효과적으로 QA 활동을 할 수 있을까? 에 대한 고민에 빠졌습니다. Agile 개발 환경에서 QA 활동을 하면서 서로 다른 산출물을 만들어내고 거쳐야 할 단계가 많아서, 스프린트 기간이 다소 촉박하게만 느껴졌기 때문입니다. 더군다나 완벽한 QA 활동을 하기 위해 스프린트에서 해낼 수 있는 생산성을 저하시키고 싶지 않았습니다.

참고로, 스프린트 내 진행하고 있는 주요 QA 활동은 다음과 같습니다.

  1. 기획서, 디자인 리뷰 > Notion
  2. QA & 배포 일정 확인 > Notion
  3. 테스트 환경 확인 > Xmind
  4. Mind-mapping 으로 테스트 커버리지 파악 > Xmind
  5. Testcase 작성 & 리뷰 > Zephyr Scale
  6. 테스트 환경별로 Testcase 할당 > Zephyr Scale
  7. 테스트 실행 & 대시보드 모니터링 > Zephyr Scale & Jira Dashboad
  8. 종료조건 확인 후 테스트 종료 > Jira Dashboard

FigJam 으로 QA 활동을 할 수 있다고?!

그러던 중 FigJam 이라는 도구를 알게 되었고, QA 엔지니어의 작업 시간을 꽤 줄여볼 수 있겠다고 생각했습니다. 위에 작성한 8개 활동을 하나의 도구 안에서 해결이 가능할 것 같았기 때문입니다. 이외에도 다음과 같은 장점이 있었습니다.

FigJam 의 장점

  • 원하는 포맷으로 작성 가능한 whiteboard(화이트보드) 형태
  • 여러 구성원이 동시에 수정 가능
  • 원하는 위치에 comment 를 추가하여 상호 리뷰 가능
  • 다양한 Widget, Template, Plugin 이 있어 원하는 기능 사용 가능

여기부터는 FigJam 을 이용하여 실제 QA 를 진행해본 경험을 공유하고자 합니다. QA 활동을 상세하게 분류해보면 조금 더 많겠지만, 저는 간단하게 설명하기 위해 계획 - 설계 - 실행 으로 3개 단계로 나누어 보았습니다. 절대 ! 정답은 아니기 때문에 이렇게도 해볼 수 있겠네 라고 또 다른 방법 정도로만 봐주시면 감사하겠습니다 :)

Step 1. 테스트 계획

  • QA & 배포 일정 스케줄링
    : 배포 단계별 QA 기간과 운영 환경에 배포일을 스케줄링 합니다.
  • 테스트 환경
    : 테스트를 진행할 환경을 명시합니다.
  • 기획서 / 디자인 / 서버 설계 문서(DB & API 명세)
    : 테스트 중 참고할만 한 문서 링크를 추가합니다.

Step 2. 테스트 설계

2-1. Testmap 작성

  • ‘테스트’ 가 가볍게 느껴지게끔 최대한 쉽게 작성합니다.

  • 보통 하나의 Userstroy, Task (Jira 기준) 는 하나의 Testmap 으로 구성합니다.

  • 최근 새로 만들어지는 기능은 Mobile Web 과 App(iOS, Android) 의 화면이 동일하게 디자인되는 경우가 대부분이기 때문에 PC Web 화면에 대한 분기처리만 별도로 고려합니다. 기존 기능의 경우, 플랫폼 별로 화면이 상이한 경우가 있어서 플랫폼마다 분기처리하여 케이스를 나눕니다.

  • 최초 Depth 에서 변경 예정인 화면으로의 진입 경로와 사전조건을 작성합니다.

  • 각 화면의 이름을 명시하고 같은 Depth 에 있는 화면은 같은 라인(세로)에 위치시킵니다.

  • 다음 Depth 부터는 각 화면에서 UI동작 을 확인하는 case 를 추가합니다.
    • (UI) default 값, 화면 레이아웃 및 문구 확인하는 케이스를 추가하여 UI 를 먼저 확인합니다.
    • (Text) KR 과 Non KR 국가 도메인을 모두 포함하는 기능의 경우, 국가 변경 시에도 주요 해상도별로 번역문구가 의도치 않게 줄바꿈되거나 잘리는 부분은 없는지 여부를 확인하는 케이스를 추가합니다.
    • (client) 버튼 클릭/탭, 텍스트 입력 등 client 의 제스처를 통한 interaction 을 확인 하는 케이스를 추가합니다. 예를 들면 특정 조건에서 팝업을 발생시키거나, 유효성 체크 후 에러 메시지를 노출시키고 버튼을 비활성화 시키는 경우에 대해서도 자세하게 작성합니다.
    • (Server) 반대로 조건 별로 server 에서 전달해주는 데이터에 따라 콘텐츠 업데이트가 다르게 일어나는 경우에도 분기처리하여 작성합니다.
  • 이외에도 추가 고려해볼 수 있는 조건은 다음과 같습니다.
    • 로그인/미로그인
    • 프로필 레벨
    • 프로필 설정
    • 뒤로가기
    • 새로고침 (+ 앱의 경우, pull to refresh)
    • 모바일 UI 제스처
    • 인풋박스 유효성 체크
    • 가변 텍스트 최대길이 제한
    • 화면 내 콘텐츠 업데이트 (+ 앱의 경우, 화면 스택)
    • 에러 핸들링
    • 앱 하위버전 호환
    • DB 마이그레이션

2-2. Testmap 리뷰

  • 기획자, 디자이너, 개발자, 타팀 QA 엔지니어에게 작성한 Testmap 을 공유하고 리뷰를 요청합니다.
  • 각 구성원은 Testcase 누락 여부, QA & 배포 일정을 주로 확인합니다.
  • Testmap 리뷰를 통해 각 구성원들은 기능에 대한 공통적인 이해도를 갖게 되고, 개발자는 스프린트 기간 중 기능 구현 여부를 체크해볼 수 있는 checklist 로 활용해볼 수 있습니다.
  • Figjam 에서 (특정 구성원을 멘션하여) comment 를 남기면 Slack 알림이 수신되어 실시간으로 의견을 주고 받을 수 있습니다.

2-3. Testcase 구성 (기존 Testcase Sheet 형식 대체)

  • 작성한 Testmap 을 활용하여 Testcase 를 구성합니다.
  • Testmap 이 너무 클 경우, section 을 분리합니다.
  • 할당된 테스트 환경에 대한 테스트 완료 여부를 확인하기 위해 section 안에 To-do list Widget 을 추가합니다. 또, Jira Widget 을 추가하여 해당 section 에서 발생한 이슈를 다른 구성원에게 공유할 수 있습니다.
  • 테스트 종료 시점에 잔여 이슈 현황 확인을 위해 Jira 에서 Bug Filter 를 생성합니다.

2-4. Testdata 생성

  • 원활한 테스트를 위해 사전조건을 충족하는 테스트 데이터를 미리 생성합니다.
  • 테스트 계정 생성, DB 수정 등을 통해 주로 사용자 플로우에서 쉽게 생성할 수 없는 사전조건에 대한 테스트 데이터를 만듭니다.

Step 3. 테스트 실행

3-1. 이슈 등록

  • Jira Widget 에서 sticky 를 통해 이슈를 생성하거나, 이미 생성한 이슈를 Figjam 보드에 import 시킬 수 있습니다.
  • 보드 위에 위치한 이슈들은 Widget 기능을 이용하여 현재 상태를 sync 할 수 있고, Timestamp 를 통해 업데이트 시간을 표시할 수 있습니다.

3-2. 테스트 진행 상태 표시

  • 미리 생성한 To-do list, Jira Widget 을 통해 테스트 진행상황을 수시로 체크하면서 QA 종료 조건 충족 여부를 확인합니다.

마무리

결론은, FigJam 을 통해서 빠르고 효과적인 QA 활동이 가능할수도 있겠다는 생각이 들기 시작했습니다. 하나의 도구 안에서 모든 QA 활동이 가능해졌습니다. 변동 사항이 생길 때마다 서로 다른 산출물을 업데이트할 필요가 없어졌습니다. 또 Testmap 이 (기존 Testcase 형식에 비해) 비교적 가독성이 좋기 때문에 각 구성원들의 리뷰가 쉬워졌습니다.

  1. 기획서, 디자인 리뷰 > FigJam
  2. QA & 배포 일정 확인 > FigJam
  3. 테스트 환경 확인 > FigJam
  4. Mind-mapping 으로 테스트 커버리지 파악 > FigJam
  5. Testcase 작성 & 리뷰 > FigJam
  6. 테스트 환경별로 Testcase 할당 > FigJam
  7. 테스트 실행 & 대시보드 모니터링 > FigJam
  8. 종료조건 확인 후 테스트 종료 > FigJam

물론 새로운 도구에 대한 적응이 필요합니다. 기존에 측정하던 metric 을 포기해야 하는 상황도 발생하였습니다. 하지만 (완벽한 QA 활동이 아니더라도) 짧은 주기의 스프린트로 돌아가는 Agile 개발 환경에서 QA 엔지니어는 꼭 필요한 QA 활동을 진행하는 동시에 테스트의 고도화를 고민해볼 수 있는 시간적 여유를 갖는 것이 더 나은 선택과 집중이라는 생각이 들었습니다.

아래 이미지는 FigJam 을 활용하여 Testmap 작성하여 직접 QA 활동을 진행한 내용입니다.

profile
안녕하세요, QA 엔지니어 Hardin 입니다.

0개의 댓글