블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 받은 트랙백

글 보관함

calendar

      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    


Definitive Guide to Develop a Good Test Strategy Document with These 7 Simple Steps - part 2 -




Process to develop a good test strategy document:


여러분의 프로젝트에 어떤 것이 가장 잘 맞을지에 대해 고민해 보지 않고 무조건 template을 따르는 것은 자제하자. 고객들은 그들만의 요구 조건들이 있고 여러분은 그런 고객들의 특성을 잘 파악해서 이 문서가 여러분의 일에 제대로 적용될 수 있도록 만들어야 한다. 그냥 무조건 다른 문서를 복사해서 붙여넣기 하지 말자. 여러분이 만든 문서가 여러분의 프로젝트에 진정 도움이 되어야 하고 여러 프로세스를 만드는데 좋은 기초가 되어야 한다.

아래는 strategy template 샘플이다. 여기에는 어떤 내용들이 이 문서에서 커버되어야 하는지를 보여준다. 그리고 각 컴포넌트들을 커버하기 위해 어떻게 해야 하는지 감을 잡을 수 있도록 예제를 제공할 것이다.


Test Strategy in STLC:




Common sections of test strategy document:



Step #1 – Scope and Overview:


이 문서를 누가 사용할 것인지에 대한 정보와 함께 프로젝트 개요가 들어간다. 좀 더 자세하게 누가 이 문서를 검토하고 승인할 지에 대해서도 언급한다. testing activity들과 testing phases 등을 정의해서 test plan에 정의된 전체 프로젝트 타임라인에 맞춘 각 activity들과 phase 들의 타임라인을 정의한다.



Step #2 – Test Approach:


testing process와 level 을 정의하고 각 팀 멤버들의 역할 및 책임을 기술한다. 모든 test type에 대해서는 test plan에서 정의 돼 있다. (예: unit, integration, system, regression, installation/uninstallation, usability, load, performance, and security testing) 이러한 test type들은 언제 테스트를 시작하고 test owner가 누구이고 누가 책임을 지고 있고 testing approach는 어떻고 automation stragegy에 대한 자세한 내용 그리고 가능하면 tool들까지 자세한 내용들이 Tesst Stragegy 문서에 담기게 된다. 그리고 왜 이런 테스트 들을 해야 되는지도 언급하게 된다.

test execution에는 여러 activity들이 있는데, 예를 들어 defect 등록, defect 분류, defect assignments, re-testing, regression testing 그리고 최종 test sign-off 같은 것들이다. 각 activity 들에 대해 정확한 step들을 정의해 두어야 한다. 여러분이 이전에 사용했던 프로세스를 다시 사용해도 된다. 테스터 인원수와 누가 어떤 activity를 진행해야 하는지 등등 각 팀 멤버들의 role과 responsibility를 명시해 놓아야 한다.

예) defect management cycle - 새로운 defect를 등록하는 프로세스 명시. 어디에 등록하고 어떻게 등록하고 defect status는 어떠해야 하고 누가 defect triage (defect 등급 분류)를 해야 하고 이 등급 분류 후에 누구에게 이 defect를 할당해야 하는 지 등등에 대해 명시되어야 한다.

또한 management process 변화도 정의한다. 여기에는 change request submission과 사용될 template 그리고 해당 request를 다룰 프로세스들이 정의된다.



Step #3 – Test Environment:


테스트 환경 셋업에 대해 정의한다. environment 갯수와 각 environment 를 셋업하는 방법등을 설명한다.


예) functional test team을 위한 test environment 한개 그리고 UAT 팀을 위한 다른 한개.
각 environmet 에 허용되는 user 수와 각 유저에 요구되는 access role들 그리고 운영체제나 메모리, free disk space, 시스템 수 등등의 필요한 하드웨어에 대해서 설명한다.

test data requirement에 대해 정의하는 것도 아주 중요하다. 어떻게 test data를 생성하는지에 대해 분명한 방법을 제시한다. (either generate data or use production data by masking fields for privacy)

test data 백업과 restore strategy 에 대해 정의한다. 아마도 프로그래밍 code에서 제대로 처리하지 않는 문제 때문에 Test environment database 운영에 어떤 문제가 발생할 수도 있을 것이다. 어떤 프로젝트에서 내가 경험했던 문제는 database backup strategy 가 정의 되지 않아서 일어났다. 언제 백업을 하고 그 백업에는 어떠한 것들이 있어야 하고 언제 이 데이터베이스를 restore 하고 누가 restore 하고 데이타베이스가 restore 된 후 따라야 할 data masking step 등등이 명시되어 있어야 한다.





Step #4 – Testing Tools:


test execution에 필요한 test management와 automation tool들에 대해 정의한다. 퍼포먼스를 위해 load와 security 테스팅에서 test approach와 필요한 tool들을 명시한다. 그것이 오픈소스인지 유료 툴인지도 언급하고 얼마나 많은 user 가 사용할 수 있는지를 알아보고 이에 맞게 계획을 세운다.



Step #5 – Release Control:


이전 UAT article에서 언급했듯이, release cycle에 대한 계획이 없으면 test와 UAT 환경에서 서로 다른 software version에 대한 result를 얻게 된다. release management 계획은 확실한 version history 를 확보할 수 있는 상태에서 수립하게 된다. 그렇게 되면 해당 release 의 모든 modification들에 대한 test execution을 보장할 수 있게 된다.

예) build management 프로세스를 수립하면 - 현재 release가 가능한 build를 파악할 수 있고 그 build들이 어디에 deploy 되는지를 명확하게 공유할 수 있다. 즉 production build 들을 어디에서 구하고 누가 해당 production release 에 대해 go or no-go를 할 것인지도 명시하게 된다.


Step #6 – Risk Analysis:



가능한 모든 risk들을 정리한다. 이런 리스크들을 완화하기 위한 clear 한 계획을 제공한다. 그리고 실제 이러한 risk가 발생했을 때를 대비한 contingency plan을 명시한다.


Step #7 – Review and Approvals:

이러한 모든 activity들이 test strategy plan에 정의 되면 이 문서는 sign-off를 위해 검토 되어야 한다. 검토할 당사자들은 project management, business team, development team 그리고 system administration (혹은 environment management) team 등이 해당 될 것이다. review change 에 대한 이력은 approver 의 이름과 날짜 그리고 comment들을 문서 시작 부분에 명시할 수 있도록 작성돼 있어야 한다.
그리고 이 문서는 현재 진행형의 문서이다. 즉 이 문서는 testing process enhancement를 위해 지속적으로 review 되고 update 되어야 한다.




마무리:


Test Strategy는 그냥 종이조각이 아니다. 이 문서는 소프트웨어 테스팅 life cycle의 전체 QA activity에 대해 설명한 문서이다. 이 문서를 test execution process 마다 수시로 참고하고 software release 까지 해당 내용들을 따라야 한다. 프로젝트가 release date에 가까와 오면 올 수록 이 test strategy 문서에 정의된 내용들을 간과함으로서 초래되는 부정적인 결과들이 점점 더 많이 발생하게 될 것이다.

agile 팀에서 일을 간소화 하려고 하는 부분은 strategy 문서 작성이 아니라 test execution 부분이어야 한다. 이러한 기본적인 strategy plan을 가지고 있으면 프로젝트에 내재해 있는 리스크 피해를 줄이거나 이에 대해 분명한 계획을 세울 수 있다. Agile 팀은 모든 high level activity들을 파악하고 이를 문서화 해서 어떠한 문제도 없이 test execution이 제 때에 완료 될 수 있도록 해야 한다.

좋은 test strategy plan을 만들고 이를 제대로 따르면 분명히 testing process 가 충분히 개선되고 소프트웨어의 품질이 향상될 것이라고 확신한다. 이 글이 당신이 당신의 프로젝트에 대한 test strategy plan을 작성할 필요를 느끼게 해 주었다면 그 자체로서 나는 보람을 느낄 수 있을 것이다.



저작자 표시 비영리 동일 조건 변경 허락
신고