[실무적용편 - 테스트 요청] 필요한 정보만 요약해서 요청서 작성하기(feat.Confluence)

필요한 정보만 모아 놓은 테스트 요청서 알아보기(feat.Confluence/JIRA)

테스트 요청서는 테스트를 수행하기 위해 꼭 필요한 문서입니다.

테스트 요청서는 테스트에 필요한 정보를 모아놓은 문서이며, 테스트의 범위를 결정하기도 하는 중요한 문서입니다.

 

또한, 테스트가 완료되었을 때 필요한 정보를 통해 이후 작업을 수행할 수도 있습니다.

 

오늘은 테스트에 꼭 필요한 테스트 요청서에 대해서 간단하게 알아보려 합니다.

그리고 테스트 요청서에 필요한 정보를 Confluence에서 JIRA 데이터를 어떻게 가져오는지도 간략하게 설명드리도록 하겠습니다.

 

Confluence에 테스트 요청 양식 만들기

테스트 요청서 양식

 

No.	구분	옵션 여부	상세 설명
1	프로젝트명	필	프로젝트의 이름을 작성.
2	담당 개발 부서	필	담당 개발 부서명을 작성
3	담당 개발 파트	옵	담당 개발 파트를 작성
4	담당 개발장	옵	담당 개발장 이름을 작성
5	개발 담당자	필	개발 담당자 이름을 작성
6	배포 마켓	필	타겟 배포를 선택(Check : On)
7	배포 예정일	필	배포 예정일을 작성(예시: 2021.05.20)
8	배포 시간	필	배포 시간을 작성(예시: 오전(후) 09시 00분)
9	요청 차수 구분	필	요청 차수를 작성(예시: 1차, 2차, 3차 ...
10	테스트 버전	필	테스트 버전을 작성(예시: 1.0.0.b1)
11	테스트 요청일	필	테스트 요청일을 작성(예시: 2021.05.20)
12	심상등록 희망일	옵	심사 등록 희망일을 작성(테스트 데드라인)
13	테스트 정보	옵	테스트 정보를 작성 - 계정, 환경, 영향 범위 / 체크리스트 등
14	테스트 차수	필	테스트 차수를 작성(예시: TEST_1차, TEST_2차 ...)
15	테스트 파일	필	테스트 해야할 파일 첨부 함
16	릴리즈 노트	필	테스트 대상 목록을 JIRA에서 불러옴

 

프로젝트명은 어떤 프로젝트에서 테스트 요청을 했는지를 구분하기 위해 사용합니다.

향후 해당 프로젝트명 내에 테스트 요청과 결과를 매핑시켜야 하고, 상위 페이지에는 업데이트 이력 등이 작성되어야 합니다. 그렇게 작성이 되면, 해당 프로젝트 내에서 어떤 버전에 어떤 항목이 업데이트되었는지 확인할 수 있게 됩니다.

 

담당 개발 부서 / 담당 개발 파트 / 담당 개발장 / 개발 담당자는 개발에 책임이 있는 정보를 입력합니다. 이때, 이야기하는 책임은 문제 발생 시 최대한 빨리 대응할 수 있는 부서나 담당자를 알기 위함입니다. "네가 개발 잘 못 했으니 알아서 책임져"의 목적이 아니라는 것을 명심하시기 바랍니다.

 

배포 마켓의 경우 테스트가 완료되었을 때 제품이나 상품이 배포되는 타깃을 간편하게 Confluence에서 체크박스를 이용하여 사용합니다. 

 

배포 예정일 / 배포 시간은 앱이나 서비스가 배포될 날짜와 시간을 작성하되 유관부서가 모두 협의되거나 공유된 시간을 작성합니다. 저 같은 경우 배포 스케줄을 관리하기 위해서 JIRA에 배포 TASK를 등록하여 배포 날짜는 End Date로 사용하고, 커스텀 필드를 만들어서 배포 시간을 입력하여 배포 날짜와 시간을 관리하고 있습니다. 또한, 대시보드에 가젯을 통해 배포 스케줄을 한눈에 알아볼 수 있도록 구성하여 관리하고 있습니다.

 

배포 관리를 위한 대시보드

 

요청 차수 / 테스트 버전 / 테스트 요청일은 전체 테스트를 몇 번 수행하였으며, 테스트 버전과 요청을 개발 팀에서 몇 번을 하였는지 확인하기 위함입니다. 이것은 "왜 이리 많이 요청했어?"의 의미가 아닌 향후 테스트 결과서를 작성할 때 모수의 기준 범위를 잡기 위함입니다.

 

예를 들어, 1차 테스트 케이스 100개를 수행해서 5개가 실패하였고, 2차에서는 실패한 5개의 범위 내에 테스트 케이스 20개를 수행했다고 합시다. 그리고 사이드 결함이 5개 나왔다고 가정하였을 때, 1차에서 테스트 케이스의 모수는 100개지만 2차에서 테스트 케이스의 모수는 105개가 됩니다.(결함은 테스트 케이스화 하여 모수에 포함해야 함)

 

심사 등록 희망일의 경우 오픈마켓(구글 플레이 스토어 or 애플 앱 스토어)에 출시하는 경우 작성하며, 해당 심사등록 희망일은 보통 테스트 완료 데드라인으로 잡습니다. 가끔 출시일이 임박하여 테스트와 심사를 동시에 진행하는 경우도 있지만 지양하는 방식이므로 정석대로 진행해 주시는 게 좋습니다.

 

테스트 정보에는 테스트에 필요한 가능한 꼭 필요한 정보를 입력합니다. 저는 현재 계정 정보나 테스트 환경 정보, 혹은 개발팀에서 필수로 확인해야 하는 체크리스트를 작성하여 확인 후 요청하게 양식을 만들어서 사용 중입니다.

 

테스트 차수와 테스트 파일은 요청과 매핑되도록 작성하며, 테스트 차수는 TEST_1차 와 같이 작성하시길 권장드립니다. 이유는 릴리즈 노트에서 사용될 제이쿼리 때문인데요. 보통 JIRA의 이슈 목록이 릴리즈 노트가 되며, JIRA의 목록을 불러오기 위한 키값으로 사용을 하게 됩니다. 

 

Confluence의 매크로(Jira 이슈 필터)를 통해 아래 제이쿼리로 목록을 불러옵니다.

사전 작업으로 해당 이슈에 출시 버전(커스텀 필드)과 label이 입력되어 있어야 합니다.

 

📌 출시 버전은 사용자의 목적에 따라 커스텀으로 만들어서 사용해 주시면 됩니다. 꼭 출시 버전이 아니어도 상관 없습니다. JIRA에서는 Fixed Version과 Affect Version을 기본적으로 제공하고 있습니다.

 

• 제이쿼리 예시 : project = OOO and "출시 버전" = 1.0.0 and labels = TEST_1차

 

제이쿼리 키값으로 세 가지를 필수로 사용 중인데 해당 쿼리의 의미는 "출시 버전 내에 몇 번의 테스트가 수행되었으며, 해당 차 수내에 어떤 항목들이 테스트되었다"를 알 수 있게 됩니다. 또한, 이 정보는 향후 테스트 결과서를 작성할 때 아주 중요한 정보로 활용된다는 점 꼭 기억하시길 바랍니다.

 

그리고 배포된 후에는 테스트 버전을 병합하게 되는데 이때, 기존 테스트한 버전이 사라짐으로 labels을 꼭 사용하시거나 QA 고유의 컴포넌트라던가 커스텀 필드를 통해 꼭 구분자를 사용하셔야 합니다.

 

테스트 요청서는 이렇게 활용해야 한다.

우선 Confluence 최상위 페이지에는 업데이트 히스토리 페이지를 작성합니다.

어플리케이션 혹은 서비스의 업데이트 히스토리

 

기본적으로 담당 부서 및 개발자가 표시되어야 하고, 업데이트 일자 / 버전 / 릴리즈 노트 목록 / 테스트 케이스 / 테스트 수행 중 발견된 전체 결함 등을 테이블에 표시될 수 있도록 정리해야 합니다.

 

바로 하위 페이지에는 해당 버전 내에 히스토리를 정리합니다.

해당 버전 별 업데이트 히스토리

JIRA 이슈 링크를 통해 릴리즈 노트 확인이 가능하며, 출시 버전 기준 몇 번의 테스트가 수행되고, 몇 개의 이슈가 발견되었는지 알 수 있게 됩니다.

 

그리고 바로 아래에 테스트 요청서와 결과서를 하위 페이지에 두시면 아래와 같이 페이지 목록으로 표시될 것입니다.

 

페이지 구성 예시

 

앞서도 말씀드렸듯이 테스트 요청서는 개발에서 테스트 팀 혹은 QA로 테스트 요청을 위해 사용되기도 하지만 테스트가 완료된 이후에 행위를 하기 위한 정보의 문서로도 활용할 수 있다는 점을 알아 두시면 좋을 것 같습니다.

 

다음 글에서는 테스트 결과서에 대해서 설명드리도록 하겠습니다. 😎

 

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스, qa 테스트, 소프트웨어 테스트