아래의 내용은 ISTQB CTFL v.2018 실러버스를 강의시간에 정독하며 강사님의 설명을 함께 정리한 것이다.
1.4.3 테스트 작업 산출물
1.4.3 테스트 작업 산출물 (Test Work Products)
테스트 작업 산출물은 테스트 프로세스의 일부로 생성된다. 조직마다 테스트 프로세스를 구현하는 방법이 다르듯이, 테스트 프로세스 중 생성되는 작업 산출물의 유형, 이 작업 산출물을 정리하고 관리하는 방법과 부르는 명칭 또한 다양하다. 이 실러버스는 위에서 설명한 테스트 프로세스와 이 실러버스 및 ISTQB
용어사전(glossary)의 작업 산출물을 기준으로 설명하고 있다. 작업 산출물에 대한 설명은 ISO 표준 (ISO/IEC/IEEE 29119-3)에서도 찾을 수 있다.
이 절에서 설명하고 있는 테스트 작업 산출물 중 다수는 테스트 관리 도구와 결함 관리 도구를 활용해서 작성 및 관리할 수 있다 (6 장 참조).
테스트 관리 도구 = TMS, test management system
test management system : 테스트 플랜, 스케쥴 관리, 테스트 계획(리스크분석,전략수립)등을 데이터로 관리하게끔 구조화한 시스템
테스트 케이스, suite, testlog(test p/f 기록), 실제결과등을 데이터로 관리할수 있게끔 한다.
메트릭 관리 - 이미 저장해둔 데이터를 메트릭화한다.
테스트 케이스와 요구사항간의 추적성 관리를 도와준다.
(테스트 케이스를 열어보면 어떤 요구사항으로 만들어져있는지 알수 있게끔 도와준다)
테스터관리도 도와줌
tms에 dms가 포함된 경우도 많다
▶︎ 테스트플랜, 테스트케이스, 로그, 테스트 결과보고서등이 테스트 관리 도구에서 관리되는 산출물이다.
결함관리도구(DMS, BTS, IMS) ex) REDMINE, JIRA
❖incident: 내가 예상했던 결과가 아님
결함 관리 도구 : 버그 트래킹 시스템
결함관리도구는 결함보고서.결함관련지표,결함조치율, 결함발견추이등등을 관리한다,
❖s- curve : 결함발견추이 그래프에서 선호되는 라인(개발도 잘하고 테스팅도 잘하고 있구나)도 보여줌.
dms는 결함을 통계적으로 분석해서 그래프로 보여주는 게 가능하다.
tms가 비싸서 tms는 엑셀로 작성하고 dms부분만 시스템을 도입하는 회사들이 많다.
결함보고서를 잘써야한다(개발자와 의사소통이 잘 되어야 하기때문)
📖 테스트 계획 작업 산출물
각종 산출물이 dms나 tms에 있을 수 있다.(실라버스에 있다)
테스트 계획은 테스트
베이시스에 대한 정보를 포함한다
어떤 베이시스를 쓸건지 알려주는 것이다.
📖 테스트 모니터링과 제어 작업 산출물
❖마일스톤: 단계말
: 테스트 진행 현황 보고서 ,단계말(마일스톤)에 생성되는 요약 보고서 (테스트 단계가 끝나면 나오는 보고서를 요약해서 만듦)
테스트 보고서는 작성일 기준 테스트 진행 상황 관련 필요한 정보를 독자에게 제공해야 한다
→ 독자 : 이해 관계자, 개발 pm, 개발자, 프로젝트 pm
우리는 테스트보고서를 잘 작성해야 한다.
테스트 모니터링과 제어 작업 산출물은 작업 완료, 리소스 할당과 사용, 공수 등과 같이 프로젝트 관리에서
관심을 가지는 사항에 대해서도 다루어야 한다.
테스트 현황보고서에 위 관련내용을 작성해주어야 한다.
📖 테스트 분석 작업 산출물
분석작업 산출물: 분석을 통해 식별되고 우선순위가 선정된 테스트 컨디션
📖 테스트 설계 작업 산출물
테스트 설계 작업 산출물 :
테스트 설계결과로 테스트 분석에서 정의한 테스트 컨디션을 실행할 수 있는 테스트 케이스와 테스트 케이스 세트가 설계 작업 산출물
테스트 설계 작업 산출물
테스트 설계는 또한 다음과 같은 결과를 가져온다:
• 필요한 테스트 데이터의 설계나 식별,
• 테스트 환경 설계,
• 인프라와 도구의 식별
★ 설계작업때는 이러한 것들을 식별하거나 설계하는 것이지 구축하지 않는다.
📖 테스트 구현 작업 산출물
테스트 구현 작업 산출물 :
- 테스트 프로시저와 이 프로시저의 배열
- 테스트 스위트
- 테스트 실행 일정
테스트 케이스와 테스트 컨디션을 통해 테스트 프로시저, 테스트베이시스 개별 요소간의 양방향 추적성을 확인함으로써 테스트 계획에서 정의한 커버리지 조건 달성 여부 확인 가능.
❖각각의 tc가 수행되는 순서 : 테스트 프로시저
프로시저를 작성하는 목적 : 더 효율적으로 테스트할 방법이 있을때 프로시저를 작성한다.
❖테스트 스윗 :
설계단계때 케이스를 만들어서 이런 케이스를 의미있는 단위로 묶어 만듬
테스트 실행 일정은 구현단계때 실제 일정을 세팅한다.
테스트 구현: 테스트를 실행할 모든 준비가 완료되었다.
상위 수준 테스트 케이스 : 로지컬
로지컬 테스트 케이스만 구축하는 회사도 많음, 테스터들의 성숙도가 이미 높은 회사, 미리 하위를 구현할 시간을 투자하는 것보다 이게 나음.살충제 패러독스를 덜 받는 편(하위테스트케이스가 구체적으로 정해져있지 않기 때문에) 다만 테스터들이 신입,제품,데이터에 대한 이해도가 높지 않다면 리스크가 크다, 혹은 자동화로 테스트할때는 구체적인 데이터가 주어져야 하기 때문에 어렵다. (컴퓨터는 바보야)
하위 수준 : 피지컬 (실행하기 편함)
❖ 테스트 오라클 : 테스트 기대결과값이 무엇이다라는 것을 알려주는 것 (ex: 요구사항 명세서)
테스트 케이스의 기대결과값을 잘 쓰는 것은 아주 중요하다.
꼼꼼하게 써줘야 함, 자세히 써줄 수 있는 부분은 자세히 써줘야 함.
탐색적 테스트는 테스트하기전에 차터는 만들어놓지만 테스트 중에 만든 산출물은 사실 노트형식의 프리포맷이다.
조직마다 테스트문서가 달라질 수 있다 이말.
테스트 분석에서 정의한 테스트 컨디션은 테스트 구현 중 추가로 개선할 수 있다.
매뉴를 보고 테스트 컨디션 도출, 그렇지만 휴리스틱이 점점 높아지면서 아이디어가 생기면 추가적으로 테스트하다가도 테스트 컨디션을 도출할 수 있다.
테스트 실행 작업 산출물 (Test execution work products)
테스트 실행 작업 산출물에는 다음과 같은 것들이 있다:
● 개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서 (예: 실행 준비 완료, 합격, 불합격,
실행하지 못함, 의도적으로 실행하지 않음 등)
● 결함 보고서 (5.6 절 참조)
● 테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등에 대한 문서
테스트 프로시저의 상태 : 로그
->테스트를 했던 아이템에 대한 버전, 테스트 도구등을 문서화
요구사항통과율, tc통과율은 차이가 있다.
테스트 완료 작업 산출물 (Test completion work products)
테스트 완료 작업 산출물로는 테스트 요약 보고서, 차후 프로젝트나 반복주기의 개선을 위한 액션 아이템, 수정
요청서 혹은 제품 백로그 항목, 완성된 테스트웨어 등이 있다.
테스트완료시점에서 백로그(해야할일을 리스트업) :
테스트 완료시점에서 아직 조치되지 않는 결함들
1.4.4 테스트 베이시스와 테스트 작업 산출물 간의 추적성 (Traceability between the Test Basis and
Test Work Products)
추적성을 확립하고 유지하는게 지표를 관리하는 것이다.(ex 요구사항 추적 메트릭스)
리그레션 테스트 (영향 평가)
요구사항 메트릭스가 있으면 영향평가가 아주 쉬워 리그레션테스트가 용이하다.
감사는 제3자가 하는 것
수치데이터가 있다면 정확하게 표현할 수 있다.
테스트를 충분히하고 있다(요구사항에 대한 커버리지를 보는 것),테스트를 잘하고 있다(t/f율 따져보는 것)
-> 메트릭이 있으면 확인이 쉽다.
