QA엔지니어가 테스트 담당자들과 같이 협업할 때 고려해야할 점들에 대해 몇가지 기재해봅니다.
들어가기에 앞서, 여기서 말하는 테스트 담당자
들이란, 꼭 테스터
라는 직무를 지칭하는 것은 아닙니다.
조직 구조는 여러가지 형태가 있겠지만, 테스트를 혼자서 하는 것이 아니라면, 누군가는 리더역할을 하는 사람이 있을 것입니다.
등등...
테스트 팀의 형태에는 여러가지 형태가 있을 수 있습니다.
또한 다른 프로젝트를 수행하다가, 뒤늦게 합류하는 팀원들이 있을 수도 있습니다. 이럴 때 안건의 품질에 대해 주도적으로 이끌어나가는 사람이 협업할 때 고려해야할 점들로는 무엇이 있을까요?
같이 수행하는 팀원들이 아무리 능력이 뛰어나고, 연차가 많고, 경험이 많다고 하여도 안건에 대해 아무런 설명도 없이, 아무런 배경지식도 없이 테스트를 진행하기란 쉬운 일은 아닐 것입니다.
주 담당자와 다른 팀원들이 꾸려진다면, 안건의 Kick-off부터 같이 참여하지 않은 이상, 아무래도 주 담당자가 정보를 많이 알고 있을 것 입니다. 이미 어느정도 테스트계획을 작성했을 수도 있고, 더 나아가면 혼자서 테스트케이스를 작성중인 상태에서 같이 테스트를 수행할 팀원들이 꾸려질 수도 있습니다.
안건을 담당하는 QA담당자는 같이 테스트를 수행할 팀원들 (이하 테스트 담당자)에게 안건에 대한 설명을 해줘야합니다.
좀 더 구체적으로는
등등이 있을 것입니다.
위와 같은 정보를 전달함으로 인해 안건에 대한 이해도를 올리도록 합니다. 혹자는 오히려 아예 기능에 대한 정보가 아예 없는 상태에서, 테스트케이스도 없는 상태에서 오로지 테스터의 호기심과 경험에 의존하는 탐색적 테스팅을 진행해야 효과가 더 좋다는 말도 하지만, 이것은 UI/UX를 확인할 때에는 효과적일지도 모르겠으나, 더 나아가 기능의 뼈대가 되는 어떠한 정책들, 데이터 노출 조건 등을 모른다면 제대로 된 테스트가 되지 않을 수도 있다고 생각합니다.
안건에 대해 설명을 하지만, 주 업무 담당자가 자세히 설명하기가 힘들때는 프로덕트 오너, 디자이너에게 Spec review를 진행해줄 것을 요청할 수도 있을 것 입니다.
이미 테스트 계획이 정해져있다면, 같이 테스트업무를 진행하는 팀원들에게 테스트 계획에 대해 설명합니다.
테스트 계획을 설명할때, 팀원들에게 어떠한 수행환경을 커버해야하는지 역할을 분담하고, 미리 생성해야할 데이터가 있다면, 각자 역할을 나누어서 준비를 진행할 수도 있을 것입니다.
더 나아가 테스트케이스가 어느정도 작성되어있다면 테스트일정과 테스트 수행인원에 따라 1명당 몇 개의 테스트케이스를 수행해야하는지도 의논해도 좋을 것입니다.
안건과 테스트 계획을 설명해줌으로 인해서 생기는 궁금증에서, 안건의 정책 누락이나 개선점을 도출해낼 수도 있을 것입니다. 이러한 점들을 다시 정리하여 이해관계자들과 커뮤니케이션을 하고, 안건의 방향 혹은 기능에 대해 추가 수정을 진행할 수도 있을 것 입니다.
테스트가 시작되면 이슈들을 찾아내고, 이해관계자들에게 공유하고, 이슈는 수정될 것 입니다.
이슈의 수정방향과 해결방법 들에 대해, 결정되는 사항들이 있다면, 팀원들에게 이러한 상황을 공유하여 안건의 진행상태에 대해 동일한 인식을 가질 수 있도록 합니다.
간혹, 테스트를 같이 수행하는 수행인원들에 대해 정보공유가 제대로 되지 않은 채로 당장 들이닥치는 이슈들에 대해 테스트를 맡길때가 많이 있습니다 (특히나 외주 테스터와 같이 업무를 하는 경우)
위와 같이 테스트 수행에 필요한 정보들을 공유하고 같이 진행한다면, 단순히 테스트에 필요한 정보를 부여함에 따라 능률이 올라가는 것은 물론이거니와, 테스트 수행인원의 소속감 및 오너십 또한 상승하여, 발생하는 이슈들에 대해 다양한 수정방향을 제시할 수 있게 될 것이며, 거기서 발생하는 의사소통으로 하여금 프로덕트의 품질 상승으로 이어지게 될 수 있을 것 입니다.