안녕하세요!  시스템 QA 역할을 구현하여 릴리스 흐름을 20% 향상할 수 있었던 방법을 공유하게 되어 기쁩니다.  제가 다니는 회사는 전형적인 제품회사이다보니 제품별로 팀이 나누어져 있지 않고 부품별로 팀이 나누어져 있습니다. 덕분에 우리는 지식의 "보유자"로 강력한 팀을 구성할 수 있었습니다. 그러나 반면에 단위 내 역할은 상대적으로 고립되어 있으며 다양한 하드 스킬과 전문 지식으로 인해 한계가 있습니다. 예를 들어 테스터를 백엔드 팀에서 프런트엔드로 또는 그 반대로 이동해야 하는 경우가 있습니다.  이로 인해 QA 팀 내 효과적인 조율과 팀 간 상호 작용 관리에 대한 문제가 발생했습니다. 물론 이는 궁극적으로 릴리스 흐름에 영향을 미쳤습니다.   변경 전 흐름 공개  변경 전의 릴리스 흐름은 다음과 같았습니다.     비즈니스 내의 특정 기능, 시스템, 제품 또는 프로젝트에 대한 자세한 요구 사항, 기대치 및 사양을 설명하는 문서입니다. 이는 비즈니스 이해관계자와 개발 또는 구현 팀 사이의 가교 역할을 하여 달성할 내용과 이것이 전체 비즈니스   와 어떻게 일치하는지에 대한 명확한 이해를 보장합니다. 여기에는 사용자가 기능과 상호 작용하는 방법을 설명하는 자세한 시나리오가 포함되어야 합니다. 기능 소유자(FO)는 비즈니스 요구 사항을 공식화하는 임무를 맡습니다. BRS(비즈니스 요구 사항 사양)는 목표    소프트웨어 시스템이 달성할 것으로 예상되는 내용에 대한 자세한 설명을 설명하는 포괄적인 문서입니다. 예를 들어, 어떤 명령이 상호 작용하는지, 어떤 프로토콜을 사용하는지, 어떤 데이터가 전송될 것인지 등이 있습니다. 기능을 작업하는 팀이 그래픽 인터페이스를 활용하는 경우 SRS에는 개발 중인 기능의 레이아웃이 포함되어야 합니다. 기능 설계자는 SRS 작성을 담당합니다. SRS(소프트웨어 요구 사항 사양)는    – 기능 소유자가 기능을 승인하기 전에 확인하는 일련의 사례입니다. 문서에 대한 설명이 끝나면 기능 구현을 진행합니다. 첫 번째 팀이 해당 기능의 일부를 개발하고 테스트하면 두 번째 팀으로 이전됩니다. 두 번째 팀에서는 통합/개발/테스트를 수행하고 이를 다음 부서로 전달합니다. 기능 개발에 참여하는 모든 구성 요소 팀이 이 흐름을 통과할 때까지 계속됩니다. FO는 기능의 유효성을 검사하고 릴리스로 전송됩니다. QAP(품질 실행 계획)   릴리스 흐름 문제  그래서 서류, 지원서, 합격 사례 등 모든 것이 괜찮은 것 같습니다. 그러나 이 과정에서 우리는 다음과 같은 어려움을 겪었습니다.   QA 측의 문제:  요구사항 테스트는 개발 후에만 시작됩니다. 개발자가 이미 구현한 작업은 요구 사항과 함께 QA 팀에 전달됩니다. 그러나 우리가 알고 있듯이 요구 사항에 오류가 있을 수 있습니다.  버그에 책임이 있는 팀을 찾는 데는 상당한 시간이 걸립니다. 어떤 사례가 다른 팀에서 이미 테스트되었는지 항상 명확하지 않기 때문입니다.  테스트 아티팩트를 재사용하지 않습니다. 하나의 기능을 테스트하는 과정에서 QA 팀은 유사한 테스트 데이터 세트를 준비합니다. 그러나 팀의 고립과 좁은 전문화로 인해 이 데이터를 서로 전송할 수 없었습니다.   FO 측의 문제:  기능이 많기 때문에 QAP를 작성하는 데 시간이 많이 걸립니다.  기능 검증은 모든 팀에서 개발 후에 이루어집니다. 우리의 경우 많은 통합 문제로 인해 릴리스 흐름이 상당히 길어졌습니다.  제품의 복잡성과 팀 간의 통합 규모로 인해 테스트 환경 준비도 정확합니다. 여러 팀이 동시에 구성 요소를 테스트하므로 데이터를 섞거나 변경하거나 삭제하는 위험이 증가합니다.   업데이트된 출시 흐름의 시스템 QA  QA 팀 간의 효과적인 팀 간 상호 작용을 촉진하고 릴리스 흐름을 줄이기 위해 시스템 QA의 역할을 도입했습니다.  이를 통해 FO로 승인 사례 작성 형태로 작업 부하를 완화하고 테스트 시나리오 작성 속도를 높이고, 기능 구성 요소를 다음 팀에 전달하기 전에 중간 테스트를 도입하고, 시간이 많이 소요되는 테스트 준비 작업을 전환하는 데 도움이 되었습니다. 통합 및 테스트 데이터에 대한 팀의 모든 뉘앙스와 요구 사항을 고려하여 환경을 시스템 QA에 적용합니다.  시스템 QA는 각 기능과 제품 전체에 대한 기술 및 비즈니스 요구 사항 간의 연결 고리가 되었습니다.  시스템 QA 온보딩  전체 릴리스 주기를 이해하려면 시스템 QA는 각 팀에서 특정 릴리스 주기가 어떻게 작동하는지 이해해야 합니다. 시스템 QA가 각 팀에서 2~3주를 보내 특정 릴리스 주기를 이해하므로 온보딩은 일반적으로 약 3개월 동안 지속됩니다.  새로운 프로세스의 결과  현재 기능 소유자 및 설계자의 BRS/SRS 요구 사항을 테스트하고 있습니다. 조기 버그 감지로 인해 비즈니스 비용이 절감됩니다.  우리는 비즈니스 요구 사항, 기술 요구 사항, 승인 사례, 다른 팀의 사례, 테스트 데이터 등 각 기능에 테스트 아티팩트가 첨부되는 팀 간 QA 공간을 구축했습니다. 이는 모든 QA 팀이 단일 컨텍스트에 있고 데이터를 효과적으로 재사용하는 데 큰 도움이 되었습니다.  시스템 QA에는 모든 팀의 테스트 사례 세트가 있으므로 버그 현지화 프로세스가 가속화되었습니다.  시스템 QA가 각 팀의 승인 사례를 작성하고 있으므로 이는 테스트 속도를 높이고 품질을 향상시키는 데 훌륭한 힌트가 됩니다.  각 명령 후 승인 사례를 통해 기능이 검증되므로 통합 프로세스가 쉬워졌습니다.  FO에서 로드의 상당 부분을 제거함으로써 기능 수용 및 테스트 데이터가 포함된 통합 스탠드 준비가 가속화되었습니다.  전반적으로 릴리스 흐름을 15~20% 가속화하고 통합 버그 수를 거의 절반으로 줄였습니다. 이제 BRS 및 SRS 요구 사항 작성 단계와 기능 개발 프레임워크 내 팀 통합 중에 버그를 포착하기 때문입니다.  행복하고 생산적인 테스트를 즐겨보세요!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

QA Head

이 오디오는 이야기의 원래 언어로 제작되었습니다!

생산성 향상: 더 빠른 릴리스를 위한 새로운 QA 역할 구현 가이드

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

디지털 유목민 들어보기: 태국의 새로운 DTV 비자에 대해 알아야 할 사항

포럼에서 피드까지: 소셜 미디어 알고리즘이 디지털 상호작용을 형성하는 방식

Claude Sonnet 3.5 시스템 프롬프트 유출: 법의학적 분석

Crypto Growth: 효과적인 사용자 페르소나 만들기

디지털 유목민 들어보기: 태국의 새로운 DTV 비자에 대해 알아야 할 사항

포럼에서 피드까지: 소셜 미디어 알고리즘이 디지털 상호작용을 형성하는 방식

Claude Sonnet 3.5 시스템 프롬프트 유출: 법의학적 분석

Crypto Growth: 효과적인 사용자 페르소나 만들기

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps