제가 QA가 전혀 없는 팀에 들어갔을 때 실제로 하는 일

Source: Dev.to

QA 리드가 고용되는 이유

회사가 QA 리드를 고용할 때, 이는 팀이 품질을 다루는 방식에서 한 단계 성장했음을 의미합니다. 릴리즈가 더 예측 가능해져야 하며, 이를 실현할 준비가 된 것입니다.

일반적인 기대

많은 경우에 QA는 “마지막에 검토하는 사람”을 의미했습니다. 그래서 직함에 “리드”가 붙은 새로운 사람이 합류하면, 엔지니어들은 조용히 더 많은 프로세스가 자신들의 책상에 올려질지를 기다립니다. 대부분의 QA 리드는 눈에 보이는 무언가—전략 문서, 새로운 프레임워크, 테스트 템플릿—을 만들어 첫 주에 보여줍니다.

더 나은 시작점

저는 더 나은 시작점이 있다는 것을 배웠습니다. 저는 사람들과 대화하는 것부터 시작합니다. 아이디어가 어떻게 실제 작업으로 전환되고 릴리즈까지 이어지는지, 테스트는 어디서 어떻게 이루어지는지, 어디서 문제가 자주 발생하는지, 그리고 무엇이 더 명확했으면 좋겠는지를 묻습니다.

그 이해 없이 프레임워크를 도입하면 영향력을 보여줄 필요는 충족시킬 수 있지만, 실제 문제를 해결하는 경우는 드뭅니다. 온보딩과 초기 대화에서 나온 같은 우려가 곧 다시 떠오릅니다: 예상보다 오래 걸리는 작업, 예측하기 어려운 릴리즈. 그때는 놀라지 않게 됩니다. 이미 그 패턴을 보았고, 단지 점들을 연결할 뿐입니다.

먼저 듣기

제가 처음 도입하는 실천은 보통 팀이 이미 이야기했지만 습관으로 만들지 못했던 것입니다.

아이디어를 습관으로 전환하기

그것이 제가 실제로 하는 일입니다. 팀이 이미 바뀌어야 한다고 알고 있는 부분을 듣고, 함께 구축할 수 있는 무언가로 전환하도록 돕습니다.

다음은

다음 글에서는 반대 상황을 살펴봅니다: 팀에 이미 프로세스가 마련되어 있는데도 여전히 작동하지 않을 때는 어떤 일이 일어나는지.