QA 업무 방식에 대한 피드백

Photo by Austin Distel on Unsplash

 

23 Jan - hotfix 건 발생과 그에 대한 회고와 평가

“이 이슈 TC 케이스에 있어요?”

QA 업무 중인 회사 앱에서 공지와 같은 알림 모달이 추가되었는데, iOS에서 백그라운드 알림 진입 시, 알림 딥링크로 화면이 전환되지 않는 이슈로 핫픽스가 발생되었다. 근무 중인 회사의 업무 방식은 인센티브를 매기기 어려운 상태로 보였다. 왜냐하면 리더 포함 6명의 테스터는 다 함께 동일한 부분을 테스트 진행하기 때문에 이슈가 발생하거나 발생하지 않았을 때 개인의 책임을 묻기 어려운 상태이다

• 리더의 팀원으로서는 검증 후 문제가 발생되는게 실질적으로 영향이 가지 않는다. 오히려 리더가 책임을 지기 때문에 리더에 대한 신뢰가 떨어지고 개인의 책임에 대한 영향이 감소된다.
• 테스터는 리더의 TC를 받아서 진행한다. 테스터는 TC를 진행함과 동일에 TC에 없는 예외케이스에 대한 테스팅이 필요하고 중요하지만, 실제 업무에서는 예외 케이스를 테스트하거나 TC에 추가하는 업무는 소홀히 여겨지고 TC 진행에 걸림돌처럼 여겨지기도 하며 모르는 것을 많이 묻는 부족한 직원의 이미지가 씌워질 수 도 있기 때문에 개인으로서는 TC를 빨리 검증해서 이슈를 많이 올리는 직원이 고평가되는 경향이 있다. 그 원인으로서 이슈를 지라에 보고하는 건의 갯수는 쉽게 알 수 있지만, 예외 및 누락 케이스를 테스팅하고 추가하는 부분에 대한 수치는 없다. 그렇기 때문에 팀원들이 예외케이스를 추가 및 공유하는 업무에 대한 수치를 매겨 중요성을 인지하고 역량에 대한 평가에 대한 결과를 인지시켜야하고, 리더에게 소통하였을 때 어떤 내용이 소통되었는지 팀원 모두가 공유되고 인지되어야한다.
• 테스트의 영역은 검증기간만 있는 것이 아니다. 준비기간이 존재하고 이러한 업무 영역에 대한 시간 배분은 무척 중요한 부분이다. 예를들어 OS별 중요한 테스트가 다르고 어떤 부분에서 집중해야하는지 전달하는 것이 중요한데, 그에 따른 커뮤니케이션이 부족한 상태로 보이고 좋은 피드백을 전달하였을 때 그에 따른 보상과 수치가 없는 상태이다.
• QA검증 기간은 늘 공백이 존재한다. 검증 기간의  검증을 준비하는 시간으로 사용되는데, 이곳의 QA 준비 기간은 리더가 다음 차수의 TC를 작성하는 것에 집중하는 시간으로 사용되고 팀원들은 버전 검증이 완료된 풀 TC를 작성하는 시간으로 집중되어 사용된다. 물론 TC는 QA에 있어서 중요한 부분인건 명백한 사실이다. 하지만 TC를 아무리 공들이고 꼼꼼하게 쓴다고 한들 모든 케이스를 확인 할 수는 없다. 그렇기 때문에 진행한 검증을 통해 이슈가 많이 재현되는 부분과 각 팀원의 역할에 대한 피드백을 통해 중요한 부분과 문제가 되기 쉬운 부분에 대한 인지를 강화할 필요가 있다. 하지만 회사의 QA 준비 기간에는 종료된 검증에 대한 피드백이나 QA 교육에 대한 업무는 거의 이뤄지지 않고 있다. TC를 꼼꼼히 작성하고 예외를 최대한 많이 넣는 업무만 집중하고 있으며, TC 작성 업무는 리더 개인으로서 작성이되고 일정에 대한 압박을 받게된다. 이러한 환경에서 작성된 TC는 검증 기간이 시작되면 팀원에게 전달된다. 팀원과의 소통이 부재된 TC는 팀원들이 이해하기에 많은 시간이 소요되고 다각면으로 고려한 TC가 만들어지기 어렵다. 검증 외 기간에 리더가 TC를 다쓴다는 현재의 방향이 아닌 각각의 팀원이 TC를 작성하고 팀원 모두가 소통하는 팀단위의 효율적인 업무로 수정될 필요가 있어보인다.

Summery: QA를 통한 신뢰성 보장 업무에 대한 개인의 책임과 역할이 필요하고, 그에 따른 보상과 소통을 진행하여 실제 중요한 업무와 개인의 경제성을 연결해야한다.