빠르게 품질 보증을 제공하는 방법

품질 보증을 품질 지원으로 변경

Laura Daly Laura Daly
주제 찾아보기

기존의 테스트 방법을 애자일 문화에 맞추는 것은 어려우며, 팀에서는 제품 품질과 출시 속도를 맞바꾸도록 강요받는 느낌을 받습니다.

이러한 문제를 방지하기 위해 Atlassian의 팀에서는 애자일 테스트에 품질 지원이라는 다른 접근 방식을 선구적으로 도입했습니다. 품질에 대한 책임을 지는 테스트 팀을 별도로 만드는 대신, 소규모의 품질 지원 엔지니어가 개발 팀 전반에 지속 가능한 테스트 방법을 전파하고 코칭합니다. 이 변화에 관한 정보와 다음 방법을 자세히 알아보세요.

  • 품질 중시 문화 조성
  • 테스트의 책임을 개발자에게 다시 넘기기
  • 버그 감지가 아닌 버그 예방

질문 및 답변

이 프레젠테이션의 질문 및 답변을 읽고 65명의 엔지니어로 구성된 팀에서 QA 엔지니어 단 6명으로 고품질 제품을 만들어 신속하게 출시한 방법을 자세히 알아보세요.  

질문 1: 개발자가 이러한 사고 유형을 적용하는 데 얼마나 걸리나요?

답변 1: 개인을 변화시키는 것보다 전체 팀의 문화를 바꾸는 것이 더 어렵습니다. Jira Software 팀의 현재의 품질에 대한 사고방식에 도달하는 데 5년이 걸렸지만, 각 신규 개발자의 경우에는 그렇게 오랜 시간이 걸리지는 않습니다. 신규 개발자는 기존 동료 개발자에게서 사고방식을 빠르게 습득하며, 빠르게 공동 작업 및 워크숍을 통해 테스트 기술을 갖추게 됩니다. 가장 어려운 부분은 위험 및 제품에 관한 지식을 모두 습득하는 것입니다. 이는 몇 년이 걸릴 수도 있는 과정이지만, Atlassian에서는 QA 개시 및 QA 데모에서 지식 공유를 통해 이 기간을 줄입니다.

질문 2: 아직 테스트 사례가 필요한가요? 그리고 테스트 사례는 재발 테트 및 자동화 테스트에만 해당하나요?

답변 2: 스크립트를 사용하는 수동 테스트 사례는 전략에 포함하지 않습니다. 테스트가 단순한 '확인', 즉 사전 정의된 단계와 정의된 어설션의 모음이라면 사람 대신에 컴퓨터가 실행하는 것이 더 효율적이고 오류 발생이 적다는 것을 발견했습니다. 순수하게 비판적 사고, 조사의 자유 및 위험 평가가 필요한 테스트라면 그러한 자유 및 지능을 테스트에 포함하도록 예비 테스트의 일부로서 수행하는 것이 더 좋습니다.

질문 3: 보통 개발자는 테스터보다 인건비가 많이 듭니다. 개발자를 테스터로 투입하면 예산/인력을 비효율적으로 사용하는 것이 아닌가요?

답변 3: 그렇습니다. 테스트 단계를 별도로 실행하기 위해 개발자를 테스터로 투입하면 비용이 많이 들고 개발자의 시간을 낭비하게 됩니다. 하지만 별도의 테스트 단계를 거치는 것 자체는 이 단계를 테스터가 실행하는 경우에도 비용이 높으며 개발자의 시간이 낭비됩니다. 테스터가 개발자에게 스토리 또는 버그를 넘길 때마다 테스트 비용뿐만 아니라 개발자 비용도 발생합니다. 거부율을 100%에서 4%까지 낮춤으로써, 릴리스 전에 스토리를 다시 작업하고 발생하지 않아야 할 버그를 수정하는 데 낭비하는 개발 시간을 대폭 절약했습니다. 내부에서 발견한 버그를 조사, 보고, 분류, 평가, 재현 및 수정하는 데 걸리는 시간을 단축했습니다. 또한 개발자가 직접 테스트를 해야 한다는 점을 알고 있으므로 처음부터 코드를 테스트하기 쉽게 설계합니다. DoTing(개발자 주도 테스트) 단계는 품질을 높이는 과정의 중간 단계로, 별도의 테스트 단계를 전부 생략할 수 있게 되었습니다. 일시적 투자로 더 큰 성과를 거두었습니다.

질문 4: 개발자와 QA 테스터는 서로 시간대가 다른 지역에 있습니다. 이 모델은 시간대가 같은 경우에만 효과가 있나요? 멀리 떨어진 팀과는 어떻게 작업하나요?

답변 4: 오스트레일리아에 있는 QA 엔지니어가 폴란드 및 베트남 팀과 함께 원격 품질 지원을 수행했습니다. 좋은 품질 지원 엔지니어가 되려면 개발자와 유대 관계를 다지는 것이 큰 비중을 차지하므로, 숙련된 QA 팀이 현장에 있는 것만큼 효과가 있지는 않습니다. 멀리 떨어진 QA 엔지니어는 정보를 받지 못하기가 쉬우며, 팀의 전반적인 문화를 알아내기란 더 어렵습니다. 하지만 영상 통화를 통해 개발자의 컴퓨터에서 QA의 컴퓨터로 직접 통화하고 화면을 공유하여 원격 QA 데모, QA 개시 및 공동 작업 세션을 성공적으로 실행할 수 있었습니다.

질문 5: QA 메모는 스토리별로 만드나요? 아니면 QA 메모의 기술 자료를 만드나요? 반복해서 발생하는 위험에는 어떻게 대처하나요?

답변 5: QA 메모는 스토리별로 만들어서 일반적으로 QA 엔지니어가 반복 위험의 패턴을 발견합니다. 각 QA 엔지니어가 다른 엔지니어가 무엇을 알고 있는지 알 수 있어 시간이 지나면서 Jira Software QA 팀이 성장함에 따라 더 어려워졌습니다. 지금까지는 매주 지식 공유를 위한 회의를 열어 흔한 위험이나 예상치 못한 위험을 추적하는 위키 페이지를 통해 이 문제를 줄였습니다. 저희는 이 방식이 더 이상 확장하지 못하는 지점까지 도달했습니다. 현재 커밋마다 실행하는 규칙의 데이터베이스를 포함한 더 구조화된 기술 자료를 제작하고 있습니다. 예를 들어 Jira Software 코드에서 사용자 개체를 사용하는 것이 확인되면 이슈에 "현재 사용자가 익명인 경우 사용자 개체는 null일 수 있습니다. 올바르게 처리했는지 확인하십시오."라는 설명이 추가됩니다. 이는 QA 리더가 지식을 공유하는 데 도움이 되며, 최고의 시나리오에서는 QA 데모 및 개시를 대체할 수도 있어 유용합니다!