Keywords
risk, risk mitigation, risk assessment, product risk
4.1 Selection of Test Automation Approach and Planning of Deployment/Rollout
TAS를 구현하고 롤아웃하는데에는 두 가지 활동이 포함된다: 파일럿과 배포이다. 이 스텝을 구성하는 활동은 TAS 유형과 특정 상황에 따라 달라질 수 있다.
파일럿 pilot 단계에서는 아래의 단계를 고려해야한다.
- 적절한 프로젝트 식별 : TAS 파일럿 테스트를 수행하기에 적절한 프로젝트를 식별한다
- 파일럿 계획
- 파일럿 수행
- 파일럿 평가
배포 deployment 단계에서는 아래의 단계를 고려해야한다.
- 초기 대상 프로젝트 식별
- 선택된 프로젝트에 TAS 배포
- 일정 기간 후 프로젝트에서 TAS의 성능과 효과를 모니터링 및 평가
- 나머지 조직/프로젝트로의 롤아웃(확산)
4.1.1 Pilot Project
도구의 구현은 일반적으로 파일럿 프로젝트로 시작한다. 파일럿 프로젝트의 목표는 TAS가 계획된 성과를 달성할 수 있는지 확인하는 것이다. 파일럿 프로젝트의 목표는 다음과 같다.
- TAS에 대한 자세한 정보 학습
- TAS가 기존 프로세스, 절차 및 도구와 어떻게 어울리는지 보고 필요하다면 변경해야할 사항을 식별한다.
- 일반적으로 TAS를 기존 프로세스/절차에 맞추는 것이 선호되며 만약 이것을 조정해야한다면 이것은 프로세스 자체의 개선으로 이어저야한다.
- 테스터의 요구에 적합한 자동화 인터페이스를 설계한다.
- 구성 관리 및 변경 관리와의 통합을 포함하여, TAS와 테스트 자산을 사용, 관리, 저장 및 유지보수하는 표준을 결정한다.
- 파일/테스트에 대한 명명 규칙, 라이브러리 생성 및 테스트 스위트의 모듈화 정의
- 사용성, 유지보수성 및 확장성을 포함하여 테스트 자동화를 모니터링하기 위한 지표와 측정 방법을 식별.
- 합리적인 비용으로 목표를 달성할 수 있는지 평가한다. 이는 TAS를 사용한 후 기대치를 재설정할 수 있는 기회가 될 수 있다.
- 필요한 기술을 결정하고 사용 가능한 기술과 부족한 기술을 식별한다.
적절한 프로젝트 식별
파일럿 프로젝트는 다음 가이드라인을 사용하여 신중하게 결정되어야한다.
- 중요한 프로젝트를 선택하지 마라.
- TAS 배포로 인해 지연이 발생하면, 중요한 프로젝트에 큰 영향을 미치게 된다. TAS 배포는 초기 단계에서 시간이 소요된다. 프로젝트 팀은 이것을 인지하고 있어야한다.
- 사소한 프로젝트를 선택하지 마라.
- 사소한 프로젝트는 배포 성공이 곧 사소하지 않은 프로젝트의 성공을 의미하진 않으므로 필요한 정보를 얻기에는 좋은 후보는 아니다.
- 필요한 이해관계자를 선택 과정에 포함시켜라
- 파일럿 프로젝트의 SUT는 조직의 다른 프로젝트에 대한 좋은 참족사 되어야한다.
- SUT는 자동화 해야하는 대표적인 GUI 구성 요소를 포함해야 한다.
파일럿 계획
파일럿은 계획 수립, 예산과 리소스 확보, 진행 보고, 마일스톤 설정 등, 정규 개발 프로젝트 처럼 다루어져야한다. 파일럿을 수행하는 사람들이 다른 프로젝트의 활동으로 인해 리소스를 분배해야할 때도 배포에 충분한 노력을 기울일 수 있도록 하는 것이 중요하다. 관리를 하는 것이 중요하며 특히 공유자원에 대해서는 더욱 그렇다. 그렇지않으면 해당 작업자들은 배포작업에 전념할 수 없을 것이다.
TAS가 벤더에 의해 제공되지 않고, 인하우스 개발자들에 의해 갭라된 경우, 해당 개발자들이 배포 활동에 참여해야한다.
파일럿 수행
파일럿의 배포를 수행하면서 아래 사항에 주의해야한다.
- TAS가 예상한대로 (혹은 벤더가 약속한대로) 기능을 제공하는지 확인한다. 그렇지 않은 경우 가능한 빨리 문제를 해결해야한다. TAS가 인하우스 개발자에 의해 개발된 경우라면, 누락된 기능을 제공하도록 해야한다.
- TAS와 기존 프로세스가 상호호환되는지 확인한다. 그렇지 않으면 조정해야한다.
파일럿 평가
평가를 위해 스테이크홀더들과 함께 수행한다.
4.1.2 Deployment
파일럿 프로젝트가 성공적으로 평가가 된다면, TAS는 나머지 부서/조직 전체에 배포되어야 한다. 배포는 점진적으로 잘 관리되어야한다. 배포의 성공 요소는 다음과 같다.
- 점진적 배포
- 조직의 나머지 부분에 대해 단계별로 배포를 수행한다. 이를 통해 새로운 유저에 대한 지원이 한꺼번에 이루어지지않고, 파도처럼 이루어진다. 이것은 TAS의 사용량이 단계적으로 증가한다는 것을 의미한다. 발생 가능성이 있는 병목 현상을 식별하고, 실제 문제가 되기 전에 해결할 수 있다. 필요한 경우 라이센스를 추가할 수 있다.
- 프로세스의 적용 및 개선
- 여러 사용자가 TAS를 이용할 떄, 다양한 프로세스가 TAS와 맞닿게되며, 이것들을 TAS에 맞게 조정하거나, TAS를 해당 프로세스에 맞게 조정을 할 필요가 있다.
- 새로운 유저에 대한 교육 및 코칭/멘토링 제공
- 신규 유저에게 TAS 사용에 대한 교육과 코칭을 제공해야한다. 유저가 실제로 TAS를 사용하기 전에 교육/워크샵을 제공해야한다.
- 가이드라인 정의 :
- TAS 사용 가이드라인, 체크리스트 및 FAQ를 작성할 수 있다. 광범위한 지원 질문을 사전에 대응할 수 있다.
- 실제 사용 정보 수집 방법 구현
- TAS의 실제 사용 정보를 자동으로 수집할 수 있어야 한다. 이상적으로는 사용량뿐만 아니라 TAS의 특정 기능 사용 여부도 포함된다. 이것을 통해 TAS 사용을 쉽게 모니터링할 수 있다.
- TAS 사용, 혜택 및 비용 모니터링
- 일정 기간 동안 TAS 사용을 모니터링 하면 TAS가 실제로 얼마나 사용되고 있는지 여부를 확인할 수 있다. 이 정보는 비즈니스 케이스를 재계산 하는데 사용할 수 있다.
- 테스트 및 개발 팀에 대한 지원 제공:
- 특정 TAS에 대해 테스트 및 개발팀에 대한 지원을 제공해야한다.
- 모든 팀으로부터 교훈 수집:
- TAS를 사용하는 다양한 팀과 함께 평가/회고 회의를 수행한다. 이를 통해 학습된 교훈을 식별해낼 수 있다. 팀은 자신의 인풋이 TAS 사용 개선을 위해 필요하다고 원한다는 느낌을 받게 한다.
- 개선 사항 식별 및 구현 :
- 팀의 피드백과 TAS 모니터링을 기반으로 개선 단계를 식별하고 구현한다. 또한 이것을 이해관계자들에게 명확히 전달한다.
4.1.3 소프트웨어 라이프사이클 내에서의 TAS 배포
TAS의 배포는 해당 TAS를 통해 테스트될 소프트웨어 프로젝트의 개발단계에 크게 의존한다.
보통 신규 TAS나 TAS의 신규 버전은 프로젝트 시작 시점 혹은 코드 프리징, 스프린트 종료 시점과 같이 어떠한 마일스톤을 달성했을 때 배포된다. 이것은 테스트 및 수정 작업이 시간이 걸리고 노력이 필요하기 때문이다. 또한 TAS가 제대로 동작하지 않아 테스트 자동화 과정에 혼란을 초래하는 위험을 줄이기 위한 좋은 방법이기도 하다. 그러나, TAS에 대한 치명적인 문제가 발생하거나, TAS가 실행되는 환경의 구성요소를 교체해야하는 경우, TAS 배포는 SUT의 개발단계와 관계 없이 독립적으로 이루어져야한다.
4.2 Risk Assessment and Mitigation Strategies
기술적 문제는 제품이나 프로젝트에 리스크를 초래할 수 있다. 일반적인 기술문제는 아래와 같다.
- 지나치게 추상화되어 무슨일이 일어나고 있는지 이해하기 어려움 (키워드/축약어를 사용한다던지)
- 데이터 주도: 데이터 테이블이 너무 크거다 복잡하거나 번거로울 수 있음
- TAS가 특정 운영체제 라이브러리나 다른 컴포넌트를 사용해야하는데, 이것이 모든 SUT 대상 환경에서 사용가능한 것은 아닐 수 있음
일반적인 배포 프로젝트 리스크에는 아래가 포함된다.
- 인력 문제 : 코드를 유지보수하는데에 적합한 인력을 모으는 것이 어려울 수 있음
- 새로운 SUT가 TAS의 오작동을 초래할 수 있음
- 자동화 도입 지연
- SUT 변경 사항에 따른 TAS 업데이트 지연
- TAS가 의도한 객체를 제대로 포착하지 못함
TAS 프로젝트에서 잠재적인 오류는 아래와 같다.
- 다른 환경으로의 마이그레이션 수행 시
- 대상 환경으로의 배포 시도 시
- 개발 시 새로운 기능 업데이트 시도 시
리스크 영역을 핸들링하기 위해 여러가지 리스크 완화 전략을 사용할 수 있다. TAS는 인하우스에서 개발된 것이던 외부 솔루션을 구매한 것이던 간에 자체 소프트웨어 생명주기를 가지고 있다. 때문에 TAS도 다른 소프트웨어처럼 버전 관리 및 기능의 문서화가 필요하다. 그렇지 않으면 서로 다른 모듈들을 배포하고 같이 동작시키거나 특정 환경에서 동작시키기가 매우 어려워질 수 있다.
또한 배포 절차에 대해 명확하고 쉽게 따를 수 있는 문서가 존재해야한다. 이 절차는 TAS버전에 의존적이므로 이 절차 또한 버저닝에 포함되어야 한다.
TAS의 경우 2가지 배포가 있을 수 있다.
- 최초 배포
- 유지보수 배포 - TAS가 이미 존재하고 유지보수 해야하는 경우
TAS의 첫 번째 배포를 하기 전에, TAS가 자체 환경에서 실행 가능하고, 어떠한 임의의 변경으로부터 격리될 수 있어야하고, 테스트케이스를 업데이트하고 관리될 수 있는지 확인할 수 있는 것이 중요하다. TAS와 인프라 모두 유지보수가 필요하다.
첫 번째 배포를 하는 경우 아래 절차들이 필요하다.
- TAS가 실행될 인프라의 정의
- TAS를 위한 인프라 구축
- TAS와 인프라를 유지보수할 절차 정의
- TAS가 실행할 테스트 스위트를 유지보수하는 절차 정의 및 생성
첫 번째 배포시 발생할 수 있는 리스크는 아래와 같다.
- 테스트 스위트의 총 실행 시간이 최초 계획된 실행시간보다 길 수 있다.
- 이 경우에는 테스트 스위트가 다음 예정된 테스트 주기 시작 전에 완전히 실행될 수 있도록 충분한 시간을 확보해야한다.
- 테스트 환경 설치 및 구성 문제 (데이터 베이스 설치 및 최초 로드, 서비스 시작/중단 등)
- 일반적으로 TAS는 테스트 환경 내에서 자동화된 테스트 케이스를 위해 필요한 전제조건을 설정하는 효과적인 방법이 필요하다.
유지보수 배포의 경우, 추가적으로 고려해야할 사항이 있다. TAS 자체는 계속적으로 발전해야하며 이에 대한 대응 업데이트가 프로덕션으로 배포되어야 한다. TAS의 업데이트 버전이 프로덕션으로 배포되기 전에, 다른 소프트웨어와 마찬가지로 테스트되어야한다. 새로운 기능을 확인하고 기존의 테스트 스위트가 업데이트된 TAS에서 실행될 수 있는지 확인하며, 보고서는 제대로 생성되는지, 퍼포먼스 이슈나 기타 기능에서 회귀문제는 발생하지 않는지 검증해야한다. 경우에 따라서는 전체 테스트 스위트를 신규 TAS버전에 맞게 수정해야할 수도 있다.
유지보수 배포 시에 다음 단계가 필요하다.
- 새로운 TAS 버전과 기존 버전의 변경 사항 평가
- 새로운 기능 및 회귀에 대한 TAS 테스트
- 테스트 스위트가 신규 버전의 TAS에 맞게 수정되어야 하는지 확인
유지보수 및 업데이트는 다음과 같은 리스크와 리스크 완화 조치가 필요할 수도 있다.
- 테스트 스위트가 업데이트된 TAS에서 실행될 수 있도록 변경되어야할 수 있음
- TAS를 배포하기 전에 테스트 스위트에 필요한 수정을 진행하고, 테스트되어야 한다.
- 테스트에 사용되는 스터브, 드라이버 및 인터페이스가 업데이트된 TAS에 맞게 변경되어야한다.
- 테스트 하니스(테스트 스위트를 실행하는 데 필요한 스텁 및 드라이버 모음)를 수정하고 TAS가 배포되기 전에 테스트되어야 한다.
- 업데이트된 TAS에 맞추어 인프라의 수정이 필요할 수 있다.
- 변경이 필요한 인프라 구성 요소에 대해 평가를 하고, 변경을 수행 후 업데이트 된 TAS로 테스트한다.
- 업데이트된 TAS에 추가적인 결함 혹은 퍼포먼스 문제가 있을 수 있다.
- 리스크와 이익을 비교분석을 진행한다. 발견된 문제가 TAS의 업데이트를 불가능하게 한다면 업데이트를 진행하지 않거나 다음 TAS 버전을 기다린다. 문제가 이익과 비교하여 사소한 수준이라면, TAS를 업데이트할 수 있다. 테스트 자동화 엔지니어와 기타 이해관계자에게 해당 문제를 알리고 문제 해결 예상 시기를 추정하여 릴리즈 노트를 작성한다.
4.3 Test Automation Maintenance
테스트 자동화 솔루션을 개발하는 것은 간단한 일은 아니다. 자동화 솔루션은 모듈화되고, 확장가능하며, 이해하기 쉽고 신뢰할 수 있으며 테스트가 가능해야한다. 여기에 추가로 다른 소프트웨어와 마찬가지로 테스트 자동화 솔루션도 계속해서 발전할 수 있어야한다. 즉, 내부 변경 사항이든 운영 환경의 변경 사항이든, 유지보수는 TAS 아키텍처에서 매우 중요한 내용이다. 새로운 유형의 시스템이 테스트될 수 있도록 TAS를 변경하고, 새로운 소프트웨어 환경을 지원하며, 새로운 법률을 준수하도록 유지보수하는 것은, TAS의 신뢰성과 안전한 운영을 보장하는데에 도움이 된다. 또한 TAS의 수명과 성능을 최적화한다.
4.3.1 Types of Maintenance
기존의 운영중인 TAS에 대한 유지보수는 시스템의 수정, 마이그레이션 또는 시스템 폐기로 인해 발생한다. 이것은 아래와 같은 카테고리들로 구조화해볼 수 있다.
예방 유지보수 Preventive maintenance
TAS가 더 많은 테스트 타입을 지원하고, 여러 인터페이스에서 테스트를 실행하며, SUT의 여러 버전을 테스트하거나 새로운 SUT에 대한 테스트 자동화를 지원하도록 변경한다.
교정 유지보수 Corrective maintenance
TAS의 결함을 수정하기 위해 유지보수한다. TAS를 운영 중에 유지보수하고 사용함에 있어서 리스크를 줄이기 위한 최선의 방법으로는 주기적인 유지보수를 수행하는 것이다.
개선 유지보수 Perfective maintenance
TAS를 최적화하고 비기능적 이슈를 해결한다. TAS의 성능, 사용성, 견고성, 또는 신뢰성을 개선하는 데에 초점을 맞춘다.
적응 유지보수 Adaptive maintenance
새로운 소프트웨어가 시장에 출시됨에 따라 (운영 체제, 데이터베이스, 웹 브라우저 등) TAS가 이것에 대해 대응해야할 필요가 있을 수 있다. 또한 TAS가 새로운 법률, 규정 또는 산업별 요구사항을 준수해야할 수도 있다. 이 경우 TAS를 적절하게 대응시키기 위한 변경이 필요하다. 여기서 주의할 점으로는 일반적으로 법률 준수는 특정 규칙, 요구 사항 및 때로는 감사 요구 사항이 있는 필수 유지보수 사항을 발생시킨다. 또한 통합 도구가 업데이트되고 새로운 버전이 생성됨에 따라 도구의 통합 엔드포인트를 유지하고 기능을 유지해야한다.
4.3.2 Scope and Approach
유지보수는 TAS의 모든 계층과 컴포넌트에 영향을 미칠 수 있는 프로세스이다. 유지보수의 범위는 다음에 따라 달라질 수 있다.
- TAS의 크기와 복잡도
- 변경 사항의 크기
- 변경 사항의 리스크
운영중인 TAS를 유지보수하는 경우에, 시스템이 변경으로 인해 어떠한 영향을 받을지 확인하기 위해 영향 분석이 필요하다. 영향에 따라서는 변경사항은 점진적으로 도입되어야 하며 TAS의 지속적인 기능을 보장하기 위해 각 단계 이후에 테스트를 수행해야한다. 이 때, TAS의 스펙과 문서가 최신 상태가 아니라면 유지보수가 힘들 수도 있다.
시간을 효율적으로 사용하는 것이 테스트 자동화의 주된 성공 요인이므로, TAS를 유지보수하기 위한 좋은 방법이 필요하다. 아래의 내용이 포함될 수 있다.
- TAS의 배포절차와 사용 방법은 명확해야하고 문서화되어야 한다.
- 서드파티 의존성에 대해 단점과 Known-issue와 함께 문서화되어야 한다.
- TAS는 모듈식이어야하며, 일부분에 대해 쉽게 교체될 수 있어야 한다.
- TAS는 교체 가능하거나 교체 가능한 구성 요소로 구성된 환경에서 실행되어야 한다.
- TAS는 테스트 스크립트와 프레임 워크 자체를 분리해야한다.
- TAS는 개발 환경과 분리되어 실행되어하므로 TAS의 변경이 테스트 환경에 부정적인 영향을 끼치지 않아야 한다.
- TAS의 환경, 테스트 스위트 및 테스트웨어 아티팩트는 구성 관리되어야 한다.
서드파티 구성요소 및 그 외 라이브러리의 유지보수를 위한 고려사항에는 다음을 포함할 수 있다.
- TAS가 테스트를 실행하기 위해 타사 컴포넌트를 사용할 가능성이 높다. 또한 TAS가 타사 라이브러리에 의존할 수도 있다. 모든 타사 컴포넌트는 문서화되고 구성 관리되어야 한다.
- 이러한 외부 컴포넌트에 수정이 발생하거나 그런 가능성이 있는 경우를 대비한 계획이 필요하다. TAS 유지보수 담당자는 외부 컴포넌트에 대해 연락할 연락처나 이슈를 제출할 창구를 알아놓아야 한다.
- 타사 컴포넌트에 대한 라이센스에 관한 문서가 존재해야한다. 수정 가능 여부, 수정 정도 및 수정 권한에 대한 정보를 제공해야한다.
- 타사 컴포넌트와 라이브러리에 대한 업데이트와 신규 버전에 대한 정보를 얻을 수 있어야 한다. 타사 컴포넌트와 라이브러리를 최신 상태로 유지하는 것은 장기적으로는 유지보수에 투자한 것에 대해 보상받을 수 있을 것이다.
네이밍 컨벤션 및 기타 규칙에 대한 고려사항은 아래와 같다.
- 컨벤션과 네이밍 컨벤션에 대한 아이디어는 단순히 테스트 스위트와 TAS 그 자체에 대해서 읽기 쉽고 변경 및 유지보수가 용이해야하기 때문이다. 이것은 유지보수 과정에서 시간을 절약하고 회귀 문제나 잘못된 수정을 최소화한다.
- 표준 네이밍 컨벤션을 적용한다면 신규 인원에게 테스트 자동화 프로젝트에 대해 소개하기 쉬워진다.
- 네이밍 컨벤션은 변수 및 파일, 테스트 시나리오, 키워드 및 키워드 파라미터에 적용할 수 있다. 다른 규칙들은 테스트 실행 전제 조건 및 테스트 실행을 위한 후속 작업, 테스트 데이터, 테스트 환경, 테스트 실행 상태, 실행 로그 및 리포트에 적용할 수 있다.
- 모둔 표준과 규약은 테스트 자동화 프로젝트를 시작할 때에 합의되고 문서화되어야한다.
문서화를 할 떄에는 아래 내용이 고려되어야한다.
- 테스트 시나리오와 TAS에 대해 좋은 최신 문서가 필요하지만, 이것을 작성하고 유지보수할 리소스가 필요하다는 문제가 생긴다.
- 테스트 도구의 코드는 자동 또는 반자동으로 문서화될 수 있지만, 모든 설계 및 컴포넌트, 외부와의 통합, 종속성 및 배포절차는 사람에 의해 문서화되어야한다.
- 문서 작성이 개발 과정의 일부로 도입되는 것이 좋은 관습이다. 작업이 완료된 것으로 판단하기 위해서는 문서가 작성되었거나 업데이트되어있어야 한다.
교육 자료에 대해서는 아래 내용들이 고려되어야한다.
- TAS에 대한 문서가 잘 작성되어있다면, TAS의 교육 자료의 기초로 사용할 수 있다.
- 교육 자료란, TAS의 기능 스펙, TAS의 설계 및 구조, 배포 및 유지보수, 사용법, 실제 예제 및 연습, 팁과 요령의 조합이다.
- 교육 자료의 유지보수는 처음에 작성하고 주기적으로 검토하는 것으로 구성된다. 이것은 TAS의 멘토로 지정된 팀 구성원에 의해 실행되며, 일반적으로는 SUT의 생애주기 반복이 끝날 때(스프린트가 종료될 때)에 이루어져야한다.
ref
- ISQTB AL TAE Syllabus
