누가 책임을 져야 할까? 게이트키핑을 없애고 품질을 높이는 방법

Jonny Steiner, 제품 마케팅 관리자

 

여러분도 이런 상황을 한 번쯤 겪어보셨을 겁니다. 공공장소를 걷다가 좋아하는 밴드 티셔츠를 입은 젊은 사람을 우연히 발견했을 때, 아마 첫인상은 "와, 너바나 티셔츠라니? 너바나 노래나 아는 사람 있을까?"와 같은 느낌이었을 겁니다. 혹시 들어보셨나요? 그렇다면 축하합니다! 게이트키핑 잠재력을 가진 겁니다! 잠재력이라고 말하는 이유는 어떤 경우에도 사람들에게 다가가 너바나 티셔츠를 입을 권리에 대해 따져 물어서는 안 되기 때문입니다. 이 블로그 게시물을 통해 삶의 교훈을 무료로 얻을 수 있습니다.

일반적인 내용은 이제 그만하고, QA 및 테스트 팀과 관련된 게이트키핑에 대해 이야기해 보겠습니다. 소프트웨어 개발 분야에서 게이트키퍼는 소프트웨어 또는 업데이트의 프로덕션 배포 시점을 제어하는 ​​사람을 말합니다. 즉, 이 시나리오에서 게이트키퍼는 소프트웨어 품질에 대한 모든 책임을 집니다. 이 역할은 종종 테스트 또는 QA 팀의 전담 구성원이 수행합니다.

우리 Release의 Releases?

사람들은 테스터들에게 출시 승인을 언제 하는지 자주 묻습니다. 테스터와 개발자는 QA가 출시의 핵심을 쥐고 있는 프로젝트를 진행했을 때 종종 좌절감을 표합니다. 한 팀에 그 정도의 책임을 맡기면 분쟁과 지연으로 이어질 수 있습니다.

어느 정도는 테스트 팀이 이러한 명칭을 자랑스러워하기도 합니다. 상당한 권한을 부여받는다는 점에서 말이죠. 하지만 QA나 테스트 팀이 왜 릴리스를 승인해야 하는지 의문이 듭니다. QA나 테스트 팀을 폄하하려는 것은 아닙니다. 어려운 상황에 놓였을 때, 테스트 팀은 선의와 침착함을 잃지 않고 최선을 다한다는 것을 우리 모두 알고 있습니다.

반면에 테스터를 릴리스에 대한 최종 결정권을 가진 사람으로 임명하는 것은 테스터에게 많은 압박을 가합니다.

QA를 게이트키퍼로 두는 경우 발생할 수 있는 부정적인 결과를 살펴보겠습니다.

• 모든 병목 현상 – 개발팀은 보통 5명으로 구성되며, 그중 한 명은 "테스터"로 지정됩니다. 테스트와 품질 관리를 담당하는 한 명을 정하는 것은 매우 간단한 계산입니다. 리드 병목 현상으로 인해.
• 책임의 대부분을 지고 – 한 사람에게 릴리스 책임을 맡기면 다른 팀원들은 모든 결함이 QA에서 발견될 것이라는 잘못된 생각에 사로잡히게 됩니다. 더 심각한 것은, 프로덕션 환경에 발생하는 버그에 대해 책임을 회피할 수 있는 기회를 제공하는 것인데, QA 탓만 할 수 있기 때문입니다.
• 완벽한 사람은 없습니다. 테스터도 마찬가지입니다. 전체 릴리스 프로세스를 한 사람의 발견에 기반하지 않는 것이 가장 좋습니다. 모든 벌레들. 벌레들도 사람이고 당신도 사람이고, 사람은 실수를 합니다.
• 피드백 루프 – 게이트키퍼 모델에서 개발자가 자신의 역할을 완료하면 방법, 테스터나 QA에게 전달한 후 다음 프로젝트로 넘어갑니다. 하지만 피할 수 없는 피드백이 오면 에서, 이전 기능으로 다시 컨텍스트 전환을 해야 합니다. 그러면 시작도 안 된 프로젝트와 중단된 프로젝트가 뒤섞이게 될 수 있습니다.

게이트키핑의 대안은 게이트브레이킹입니다

게이트키핑 없이도 고품질 애플리케이션을 출시할 수 있는 테스트를 실행하는 방법이 있습니다. QA 업무를 개발팀 전체에 맡기면 모두가 품질 관리를 담당하게 됩니다. QA는 여전히 테스트를 담당할 수 있지만, 더 많은 테스트를 해야 하며 다른 팀원들이 도움을 줄 수 있습니다.

• 개발자는 자신의 단위 테스트를 작성하여 자신이 수행한 작업을 커버할 수 있습니다.
• 제품 관리자는 스테이징 환경을 점검하여 새로운 기능이 실행된 대로 수행되는지 확인할 수 있습니다.
• DevOps 관리자는 CI 시스템을 사용하여 새로운 코드가 커밋될 때마다 테스트를 모니터링할 수 있습니다.

이 연습은 간단하게 시작할 수 있습니다.

새로운 기능 개발 작업을 시작하기 전에 세션을 시작하세요. 이렇게 하면 개발자와 테스터가 스프린트에 참여하여 작업이 승인 기준에 따라 완료되었음을 증명하기 위해 무엇을 해야 하는지 파악할 수 있습니다. 사전에 작업에 대해 논의함으로써 팀원들 간에 업무량을 균등하게 분배할 수 있고, 개발자가 API 테스트를 작성하면 QA는 UI 및 기능 테스트를 진행할 수 있습니다.

프로젝트가 진행되면서 팀에서 해결해야 할 문제가 발견되면, 팀원들끼리 또는 팀끼리 논의할 수 있습니다. 예를 들어, QA팀에서 결함을 발견하면 제품 개발팀에 보고하여 즉각적인 조치가 필요한지 아니면 기다려도 되는지 확인할 수 있습니다.

더 좋은 점은, 더 많은 사람들이 프로젝트에 참여하고 테스트에 참여할수록, 가능한 한 프로세스 초기에 테스트를 진행하는 Shift-Left(좌측으로 전환) 사고방식이 자리 잡는다는 것입니다. 테스트를 시작하기 위해 특정 시점을 기다릴 필요가 없으며, 그저 사람들의 일상의 일부가 됩니다. 장기적으로 이는 개발 주기 후반부로 갈수록 위험을 최소화하는 데 도움이 될 것입니다.

궁극적으로 더 많은 테스트가 이루어지고, 이는 더 나은 커버리지로 이어집니다. 여러 분야를 아우르는 팀들이 각자의 고립된 팀에 머무르는 대신 서로 소통할 수 있기 때문입니다. 만약 고립된 팀들이 조직 내에서 문제가 된다면, 제품 책임자와 이해관계자들에게 이 문제를 제기할 수도 있습니다. 게이트키핑 상황을 처리할 때 소통과 협업을 촉진하는 것은 매우 중요합니다.

그러면 결과는 다음과 같습니다.

• 공동 책임 – 책임을 지는 사람이 한 명도 없기 때문에 팀 전체가 고품질 소프트웨어를 제공할 책임을 맡습니다.
• 안녕 병목 현상 – 더 이상 한 사람이 전 세계를 상대로 테스트하는 것은 아닙니다. 모두가 테스트하면 새로운 버전과 앱이 더 빨리 출시될 것입니다.
• 피드백 루프 강화 – 결함이 발견되어도 더 이상 컨텍스트 전환이 필요하지 않습니다. 결함은 프로세스 초기에 발견되어 완화되므로 프로덕션 지연이 발생하지 않습니다.

QA의 게이트키핑은 유물이다

일부 조직에서는 여전히 이런 일이 발생합니다. QA는 프로젝트 출시를 책임지고 출시의 열쇠를 쥐고 있습니다. 이러한 해로운 관행은 테스터에게 부담을 주고, 서로 협력하지 않는 목표를 향해 개별적으로 작업하는 팀 간의 관계 악화로 이어집니다.

QA 게이트키핑을 실행할 때 두 가지 주요 부정적인 시나리오가 있습니다.

1. 지연된 프로젝트 – QA는 출시 전에 특정한 사소한 문제를 차단합니다.
2. 생산상의 결함 – 버그가 간과될 때마다 QA가 희생양이 되는데, QA가 전반적인 품질에 대한 책임을 져야 하기 때문입니다.

이러한 구식이고 솔직히 말해 협업에 어긋나는 개발 및 테스트 방식을 탈피하려면, QA가 모든 것을 책임지는 대신, 개발하는 동안 모든 프로젝트 참여자가 테스트에 참여하도록 해야 합니다. 또한, 개발 초기부터 자주 테스트를 진행해야 합니다. 이러한 기본적인 이해를 바탕으로 모든 사람이 자신의 역할을 다할 수 있는 시스템을 구축하고, 전반적인 릴리스 품질도 향상될 것입니다.

품질이라는 목표와 개념은 팀 워크플로우의 기본 요소 중 하나가 되어야 합니다. 또한 프로젝트에 참여하는 모든 사람이 참여해야 합니다. 회사 내에서 팀 간의 고립이나 협력 부족이 발생하기 시작하면 이를 개선할 수 있는 위치에 있는 사람들에게 알려야 합니다. QA 팀이 게이트키핑에만 집중하면 전반적인 앱 품질이 저하될 수 있는데, 이는 매우 안타까운 일입니다. 직함에 '게이트키핑'이라는 단어가 들어 있기 때문입니다.