테스트 분야 공부를 하게 되면 반드시 만나는 V-Model 에 대한 생각이다.
ISTQB 공부를 하면서 실라버스에 나온 내용과 테스트 실무 등.. 프로세스 및 정책은 언제나 웅장한 느낌을 받는다.
그럼 실무에서는 어떻게 적용해야 할 것인가?
여태 다녀본 회사에 품질, 테스트 조직이 있다한들 테스트 정책을 명문화하여 지키는 것을 본 적이 없었다.
그리고 앞으로도 없을 것 같다. 그만큼 실무와 거리가 생기는 내용이라 생각한다.
개발 프로세스를 개선하면서 늘 품질 파트를 어떻게 접목해야 하는가라는 고민이 생겼다.
일전에 스크럼을 공유하면서 고민했던 내용을 끄적여 본다.
Scrum 프레임워크를 통해 개발자들은 어떻게 개발을 해야되는지 알게 된다.
하지만 품질 담당자에 대한 언급은 없었던 것 같다. 개발을 잘하면 되니깐!!
우선 품질팀이 참여할 단계를 모색한다. 접목해 본다.
위 프로세스에서 각 단계에 대입해본다.
- Grooming
다음 진행할 프로젝트의 백로그 및 기술에 대한 검토가 진행된다.
이때 테스트 관리자에게 선정되는 항목 기준으로 테스트 계획을 작성하도록 한다.
늘 그렇듯 테스트 계획은 이전 문서에 항목만 바꾸는 형태로 진행되고 있다.
여기서 센스있게 개발할 기술에 대한 검증 방법이나 백로그에서 다루는 스토리의 사용성 부분을 추가하면 어떻까 생각해본다.
물론 Test Basis 가 부족하기 때문에 대략적으로라도 언급하면 나중에 놓치지 않을까? 이런 생각이 있다.
- Sprint Planning Meet
유저 스토리가 구체화되는 단계로 언제든지 스프린트로 옮겨서 개발을 진행할 수 있는 수준의 요구사항이 작성된다.
여기서 테스트 담당자는 해당 스토리의 완료 조건을 작성하여 유저스토리와 함께 진행될 수 있도록 한다.
작성은 서술형 문장으로 작성하길 바라며,
- OO 화면에서 누가 OO 행위를 하면 OO 결과가 나와야 한다.
- OO 상황에서 OO 조건이 맞으면 OO 결과가 나와야 한다.
행위나 상황에 따른 결과를 명시하여 기능별, 예외 케이스별 하나의 문장으로 여러 개가 나오면 좋을 것 같다.
- Daily Meet
업무 시작 전 진행하는 업무와 이슈를 간단히 공유하고 진도를 체크한다.
분명 유저 스토리에 적힌 완료 조건에 대한 이슈가 입장 차이(개발자, 테스터, PO)가 발생하고 조율이 진행되며
완료 조건을 다듬거나 삭제, 추가하는 행위들이 취해야 져야 한다.
- Development
개발을 하고 있다.
선임 테스터나 개발 선임자는 코드나 아키텍처에 대한 구조적 테스팅을 할 수 있으면 좋겠다.
욕심이 과했다. 아무도 못하더라...
다행히 코드 리뷰를 진행하여 개발 파트 내에서 간단한 리뷰는 이루어진다.
- Validation (Review)
리뷰를 하고 완료 조건을 만족하는지 검증을 진행한다.
한 번에 통과하는 경우는 없었던 것 같다.
완료 조건이 명확하면 명확할수록 한 번에 통과는 꿈도 못 꾼다. 왜일까...
하지만 이 단계를 거쳐야 통합 후 시스템 테스트의 이슈를 최소화할 수 있었다.
프로세스에 녹여보기는 대충 된다.
여기서 과연 성공할 수 있을까라는 물음을 가졌다. 이유는 QA 가 무엇인가를 개발팀이 대부분 모르고 있었기 때문이다.
내가 만난 개발팀의 구성원 대다수는 QA 와 QC 그리고 테스터에 대한 개념이 없었다.
그래서 QA 활동을 하면 개발팀에서는 먼데 나대?? 이런 반응의 느낌이었다.
(이거 시간나면 하나의 주제가 되겠군)
하여튼 품질팀을 스크럼에 녹인결과 아래의 V-Model 을 만들었다.
상류 활동부터 최종 인수까지 기존 V-Model 에 상세 활동을 약간 변형한?? 어찌 보면 똑같은...
터무니없거나.. 그럴싸하거나...
댓글