[SW프로세스 III]협업 프로세스 내 테스트 활동
폭포수모델의 SW 프로세스 글에서 간략히 다루었던 협업 프로세스에서의 테스트 활동에 대해 좀 더 자세히 살펴보겠습니다.
테스트 프로세스
테스트 프로세스는, 개발된 소프트웨어의 품질 기준을 만족하기 위한 테스트 수행 절차로 소프트웨어 테스트를 효율적으로 실행하기 위한 테스트 계획과 설계, 조직의 역할과 책임, 필요한 작업 및 절차, 산출물 등 테스트 단계별 활동을 정의한 것입니다.
테스트 프로세스를 통해 소프트웨어의 품질 기준과 테스트 범위를 측정하고 개발 구현된 소프트웨어와 요구 사항과의 차이를 판별하며 테스트 진행과정을 관리하기 위해 각 테스트 단계의 활동을 정의하는 것이 목적입니다.
폭포수 개발 생명주기에 기반한 테스트 프로세스 생명주기테스트 프로세스는 테스트 계획에 따라 테스트를 수행하기 위한 세부 활동과 테스트 조직의 품질 목표와 기준을 바탕으로 테스트 수행을 모니터링하고 제어하며 테스트 종료 활동을 포함합니다.
테스트 수행을 위한 세부 활동은 테스트 설계 및 구현, 테스트 환경 구축, 테스트 실행, 검출된 결함 등록 및 관리, 테스트 산출물(설계서, 테스트 케이스, 준비·진행·완료 보고서 등) 작성 및 관리, 종료 활동으로 구성됩니다.
테스트 프로세스: 세부 단계별 활동의 정의와 수행방법
테스트 계획
테스트 계획은 소프트웨어의 품질 목표를 달성하기 위해 검증에 필요한 활동을 정의하는 단계로 전체 테스트 범위를 포함한 종합적인 계획과 폭포수 모델 단계별 테스트 수행 계획 및 테스트 유형별(기능성, 유지보수성, 사용성 등) 수행 계획으로 설계합니다.
①테스트 수행 계획은 테스트 대상 시스템 및 비즈니스 리스크를 식별하고 테스트 주요 요소를 분류하여 테스트 전략을 수립합니다. 수행 계획과 전략 설계 시 프로젝트 계획서와 요구사항을 분석하여 테스트 범위, 테스트 목적, 리스크 분석, 담당자, 일정, 투입 비용, 제약 사항 등을 고려합니다.
② 프로젝트 계획서/요구사항을 분석하여 테스트 목적 및 테스트 범위 설정, 테스트 일정을 계획합니다.
테스트 단계별 범위 선정 예시③ 개발 생명주기 각 단계에 적합한 테스트 유형을 선정하고 테스트 단계별 수행방법을 정의합니다.
▶ 개발 생명주기 : waterfall, agile에 따라 테스트 유형과 방법 정의 및 선정
▶ 테스트 유형 : 기능 테스트, 성능 테스트, API 테스트, 네트워크 테스트 등 선정
▶ 테스트 방법 선택시 고려사항 : 시스템 복잡도, 중요도, 조직/개발 성숙도, 요구사항, 일정 등 고려
④ 테스트 단계별 품질 목표 기준을 선정하고 품질 지표 관리 방안을 정의합니다.
테스트 시작기준 예시▶ 테스트 시작 기준
Fail 시 테스트 중단. 수정 후 다음 시작 가능 시기 조율.
▶ 테스트 완료 기준
제품 출시를 위한 오픈 가능한 품질 목표 기준을 설정하여 Fail시 출시 일정을 지연하거나 추가 테스트 일정을 조율합니다.
품질 목표를 달성하여 제품 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 QA 판단 결과 오픈 가능 여부를 전달합니다.
[테스트 완료 기준 예시]
1. 계획된 품질 보증 활동을 모두 완료
2. 위험도가 “중” 이상인 리스크가 없거나 대응 방안이 마련되어야 함
3. Major 이상 잔존 결함 없음
4. 잔존하는 이슈 / 리스크가 있을 경우 대응 방안이 준비되지 않았다면 테스트 종료 불가함
5. 보안 검수 및 성능 검수 결과 권고된 시정 사항이 조치 완료되거나 대응 방안 마련
6. 테스트 종료가 불가한 경우 프로젝트 담당자가 모두 참여하여 제품의 품질 상태 확인 및 테스트 종료가 불가한 원인을 확인하여 제품 출시 여부를 결정하도록 함 & 해결되어야 하는 문제에 대한 해결방안 마련 및 추가 일정 협의
⑤ 테스트 수행 환경 구성 및 구현
테스트를 수행하기 위한 기본 데이터들을 정리하고 어떤 환경에서 테스트를 수행할 지 미리 준비하여 각 프로젝트 목적에 맞는 환경과 자원을 준비하고 문서화합니다. 테스트를 위한 데이터의 예로는 테스트 계정, 계정에 따른 권한, 네트워크, 제품 출시 타겟 국가에 따른 조건, 테스트 서버(API, 클라이언트, DB 등) 설정 등이 있습니다.
[테스트 환경 예시]
▶ Dev : 개발 환경
▶ QA : QA 테스트 환경
▶ Staging : 실 환경을 복제한 운영 테스트용 환경 (라이브와 동일한 서버/DB 백업)
▶ 각각의 환경과 연동된 테스트 빌드
⑥ 테스트 수행 역할 선정
⑦ 테스트 단계별 산출물 정의
⑧ 계획된 테스트 전략을 바탕으로 QA Plan 작성
QA Plan은 테스트를 하기위해 필요한 자원들을 요약한 것으로 정해진 프로세스대로 업무를 수행하기 위한 청사진 역할을 하며 계획된 방향으로 테스트가 진행될 수 있도록 가이드 역할을 합니다.
테스트 설계
테스트 목표와 목적을 테스트 케이스로 변환하는 단계입니다. 테스트 설계는 고객 요구사항 명세서, 기획 문서, 개발 설계서와 시스템 아키텍처 등의 산출물과 리스크 분석 결과를 기반으로 테스트 대상을 식별하고 테스트 범위를 정의하며 테스트 절차에 따른 수행 명세서(테스트 케이스 또는 테스트 시나리오)를 작성하는 활동입니다.
테스트 케이스를 작성하기 위해 먼저 ①테스트 대상을 분석하고 범위를 선정합니다. 테스트 베이시스를 분석하여 테스트 대상 기능을 선정하고 리스크 분석을 통해 테스트 우선순위를 선정하며 테스트 전략과 총괄 테스트 수행 계획서를 바탕으로 테스트 범위를 결정합니다. 이를 바탕으로 자동화, API, 보안, 성능 등 기술 검증이 필요한 범위를 도출합니다.
프로덕트 품질 특성별 테스트 종류 및 수행 목적테스트 대상 분석 및 테스트 범위가 식별되면 테스트 베이시스를 기반으로 ②테스트 케이스 또는 테스트 시나리오를 작성합니다. 테스트 케이스 작성 시 명세서와 요구사항에 맞춰 테스트 성공과 실패 기준을 정의하고 테스트 설계 기법을 적용하여 테스트 케이스를 작성합니다. 효율적이고 효과적인 테스트 실행을 위하여 기능 연관성과 유저 흐름을 고려하여 테스트 케이스의 순서를 구성하도록 합니다. 또한 기술 검증에 필요한 테스트 스크립트 작성을 위해 테스트 케이스를 선별합니다. 테스트 케이스 작성이 완료되면 테스트 조직 내부 또는 프로젝트 관련자와 함께 리뷰를 진행하여 작성된 내용을 검토합니다.
테스트 케이스 작성이 완료되면 테스트 수행을 위한 ③테스트 데이터 및 테스트 도구를 준비합니다. 기능 및 기술 검증용 테스트 케이스를 실행하기 위한 데이터와 테스트 대상을 설정하는 데 필요한 데이터, 테스트 케이스에서 요구하는 조건과 상태를 충족하게 만드는 데이터를 준비하고 기술 검증 테스트를 위한 도구(예: Appium, Postman, Jmeter 등)와 결함 보고용 관리 도구(예: JIRA, Redmine 등)를 준비합니다.
테스트 구현과 실행
①테스트 구현은 선별한 테스트 케이스에 맞게 자동화, 성능, API 등 기술 검증용 테스트 코드를 작성하고 코드를 실행하여 성공·실패 검증 포인트를 설정하고 무결성을 검증하는 활동입니다.
②테스트 실행은 작성한 테스트 케이스를 바탕으로 테스트 활동을 수행하는 단계입니다. 테스트 케이스를 수행하기 전 프로젝트 정책에 따라 수행해야 하는 테스트 환경을 확인합니다. 설정된 환경에서 테스트 케이스에 기술된 단계와 테스트 데이터를 확인하고 해당 기능이 수행 절차에 따라 기대 결과를 만족하는지 실행 결과를 기록하며 테스트를 수행합니다.
테스트 실행 중 기대 결과에 만족하지 못해 실패 처리된 결과는 분석을 통해 테스터의 단순 실수인지 시스템 결함인지 판단하여 수정이 필요한 결함으로 판명되거나 테스트 케이스에 기술되어 있지 않지만 유효한 버그를 발견한 경우 버그 관리 시스템에 ③결함을 기록하고 프로젝트 관계자들에게 이슈를 보고합니다.
등록된 버그에 해당되는 테스트 케이스에는 버그의 ID(식별자)를 기록하여 버그 진행 상태를 체크하고 업데이트합니다.
테스트 케이스 수행시 결과 판단 기준테스트 수행이 완료되면 ④테스트 결과를 기록하고 검토합니다. 테스트 케이스 실행 결과 및 보고된 결함의 조치 내역을 취합하여 품질 상태에 대한 기록을 작성합니다. 작성된 기록을 확인하여 테스트 진행 상황, 제품 품질 상태, 테스트 활동 품질, 프로젝트 진행 중 논의가 필요한 주제, 주요 결함 내용을 파악하고 테스트 수행에 걸림돌이 되는 부분을 제거하고 계획한 품질 검증 활동을 일정에 맞춰 완료할 수 있도록 필요한 조치를 지원합니다.
테스트 완료 및 평가
계획한 품질 보증 활동을 완료하면 테스트 완료 조건과 최종 테스트 수행 결과를 비교하여 출시가 가능한 상태인지 판단하여 ①테스트 최종 결과 보고서를 작성합니다. 제품의 출시 가능 여부는 테스트 종료 보고서QA Sign-off로 전달됩니다. 이 보고서를 통해 품질 목표를 달성했는지, 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 테스트 담당자의 판단 결과를 전달합니다.
산출물 구성은 테스트 수행 단계별 품질 현황 결과 보고서와 유사하나 내용상 두가지 차이가 있습니다. 첫째, 테스트 담당자의 테스트 완료 평가와 제품의 출시 가능 여부에 대한 최종 의견을 전달합니다. 출시 불가한 상황일 경우 원인을 공유하고 문제 해결 방안과 출시 여부 결정을 위한 관련자 협의 미팅(오픈 적합성 회의)을 요청합니다. 둘째, 전체 테스트 기간에 수행된 테스트의 최종 상태를 공유합니다. 총 테스트 케이스 수행 결과, 계획 대비 차이점, 잔존 결함과 리스크, 합의된 논 이슈known-issue를 공유하고 전체 품질 검증 활동 진행 결과를 작성합니다.
테스트를 종료하고 제품의 출시가 결정되면 오픈 예정일에 제품이 고객에게 공개됩니다. 출시 후 테스터는 라이브 환경에서 제품의 주요 기능과 작동에 문제가 발생하지 않는지, 고객의 불편사항과 결함에 대한 피드백이 전달되지 않는지 ②모니터링을 수행합니다. 모니터링 후 특별한 이슈나 특이사항이 발생하지 않으면 모니터링 보고서를 공유하고 프로젝트를 최종 마무리합니다. 이후 유지보수 담당자에게 제품 및 품질 기록을 이관함으로 테스트 프로세스가 종료됩니다.
마지막으로 ③완료된 품질 검증 활동과 프로세스를 평가하고 개선사항을 제안하는 미팅을 진행합니다. 테스트 활동에 대한 평가는 완료된 프로젝트에서 수행한 테스트 활동 데이터를 수집하고 각 테스트 단계와 테스트 종류별로 결과를 분석하여 테스트 활동에 대한 객관적인 평가를 기록합니다. 해당 미팅의 참여 대상은 프로젝트에 참여한 테스트 담당자(QA, TL, SET, TE) 및 테스트 조직 전체이며 미팅의 주요 의제는 테스트 수행 시 발생한 문제점(휴먼 이슈, 테스트 산출물 이슈 등), 수행 절차상 개선사항, 특이 결함 케이스, 프로세스 개선 사항을 공유하여 테스트 지식과 경험을 축적하고 문제점을 개선하는 활동을 수행합니다.
테스트 평가가 완료되면 각 프로젝트 관련자들과 모여 ④프로젝트 회고Post-mortem 활동을 진행합니다. 회고를 진행하는 목적은 각 직무 담당자의 잘잘못을 가리고 찾아내는 것에 집중하는 것보다 모두가 서로에게 안전하게 이야기할 수 있는 환경을 만들고 회고라는 마침표를 찍음으로 새로운 일을 준비할 수 있도록 하기 위함입니다. 회고의 참여 대상은 기획, 개발, 테스터, 마케팅 등 프로젝트 전체 인원이며 미팅의 주요 회고 내용은 프로젝트에서 발생한 잘한 일(Keep), 잘못한 일(Problem), 개선 활동(Try)을 복기하는 것입니다. 잘한 일은 앞으로 더 잘할 수 있도록 프로세스로 정립하고 잘못된 일은 재발을 방지하기 위한 대책을 수립하거나 시스템 또는 프로세스의 개선 방안을 도출하여 이전보다 나은 다음을 준비합니다.
