GN⁺: QA 팀을 해체한 것이 잘못된 결정이었을지도 모른다는 지적

QA 팀을 없애는 것이 실제로 나쁜 결정이었을 수도 있다

• 소프트웨어 배포의 가장 느린 부분은 테스팅임. 연속적인 배포가 존재하는 이유가 테스팅이기 때문에, 이것이 병목 지점이 되는 것은 최적화된 상태로 간주됨.
• 최적화의 습관과 행동은 QA 팀을 병목 지점으로 보고 이를 제거하려는 산업의 경향으로 이어짐. 이로 인해 QA 역할에 대한 존중이 감소하고, 질 좋은 소프트웨어를 생산하지 못하는 문제가 발생함.
• 개발자들은 소프트웨어 품질 관리를 제대로 파악하지 못함. 많은 조직들이 소프트웨어 품질에 대한 책임 소재를 모르고 있으며, QA 기능을 유지한 곳들도 이를 위한 자리를 찾는 데 어려움을 겪음.

소프트웨어 실천에서 품질을 관리하기 위해 해야 할 일

• 결함 추적: 사용자가 버그에 대한 정보를 제공하고 개발자가 버그를 기록할 수 있는 방법이 필요함.
• 트리아주: 버그 트리아주는 버그를 할당, 우선순위 지정, 정리, 분류, 중복 제거 등을 관리하는 과정임.
• 결함 조사: 버그를 재현하는 것은 버그 관리의 중요한 부분으로, 실제 문제를 파악하고 해결하기 위한 엔지니어링 노력이 필요함.
• 집중: 품질에 집중하는 사람들이 회사에 있어야 하며, 품질과 속도 사이의 균형을 위해 품질을 옹호하는 사람이 필요함.
• 엔드 투 엔드 테스팅: 시스템의 소유권 문제는 복잡한 아키텍처로 인해 발생하며, 이는 제품 출시 전 실제 사용 테스트의 부재로 이어짐.

GN⁺의 의견

• QA 팀을 없애는 것은 장기적으로 볼 때 소프트웨어 품질에 심각한 영향을 미칠 수 있는 관리상의 실수임.
• 소프트웨어 개발 과정에서 품질 보증은 중요한 업무이며, 이를 무시하거나 경시하는 태도는 결국 실패로 이어질 수 있음.
• 이 기사는 소프트웨어 산업 내에서 QA의 중요성을 재조명하고, 품질 관리에 대한 적절한 인식과 조직 내에서의 역할 분담의 필요성을 강조하는 데 흥미로움을 제공함.

[neo]

Hacker News 의견

• 1970년대 후반 IBM에서 제품 보증 업무를 담당하며, 담당 제품(워드 프로세싱 시스템)의 테스트 코드 작성 및 하드웨어 구축을 했음. 개발팀에게는 테스트 케이스를 구체적으로 공개하지 않고 일반적인 문제점만 전달하여 버그 수정을 유도했음. 이 방식으로 발견한 버그와 개발팀이 수정한 버그 간의 불일치를 통해 남은 버그의 추정치를 통계적으로 계산할 수 있었음.

• QA 팀이 없는 조직에서는 '스니프 테스트'라는 개념을 도입했음. 이는 회사의 모든 사람이 새 기능을 짧은 시간(보통 1시간) 동안 집중적으로 테스트하는 세션으로, 많은 버그 티켓을 생성하는 결과를 가져왔음. 간단한 테스트들이 문제를 일으키는 경우가 많았지만, 이제는 더 이상 놀랍지 않음.

• 15-20년 전에 일했던 두 회사는 최고 수준의 QA 팀에 투자했으며, 이들은 개발자들이 생각하지 못한 버그를 찾아내는 데 뛰어난 능력을 보였음. QA 팀이 제품 출시 여부를 결정하는 최종 권한을 가졌음. 현재 많은 회사들은 개발자가 자동화된 테스트를 작성하고 코드 커버리지에 많은 시간을 소비하는 것이 더 나은 방법이라고 생각하지만, 실제로 작동하지 않는 제품을 많이 보았음. 자동화된 테스트가 나쁘다는 것이 아니라, 인간 QA 테스터를 없애는 것에 대한 문제 제기임.

• 조직에서 가장 양심적인 직원들은 종종 가장 불만을 가지고 있음. 그들은 품질 문제를 인식하고 해결하려 하지만 인정받지 못하며, 품질에 대해 말하면 느리게 움직이려는 사람으로 취급받음. '빠르게 움직이고 물건을 부수는' 사람들이 계속해서 보상을 받는 동안, 그들은 뒤처리하는 데 화를 내며, 조직 내에서 신경 쓰는 것이 커리어에 해가 될 수 있음을 느낌.

• QA는 비즈니스와 상위 경영진에 의해 '비용 센터'로 간주되는 경향이 있음. '비용 센터'로 여겨지는 부서에서 일하는 것은 피해야 한다는 가설이 있으며, 보상과 인정은 항상 수익을 창출하는 사람들에게 돌아감. QA는 더 많은 일을 더 적은 인원으로 해야 하고, 실패에 대해 비난받으며, 비즈니스가 슬림해져야 할 때 해고되는 첫 번째 장소가 될 수 있음.

• QA 엔지니어들은 뛰어난 디버깅 능력을 가지고 있음. 그들은 파이프라인, 소스 코드, 테스트 디렉토리 등 애플리케이션의 모든 측면에서 작업하며, 종종 소프트웨어 엔지니어들이 파이프라인 오류 메시지를 읽지 않고, 기본 문제를 무시하며, 해결책을 추측하는 데 날을 보냄. QA 엔지니어에 대한 무시는 기사에서 과장된 것이 아니며, QA 조직이 엔지니어링 조직만큼 엄격한 면접 과정을 거치지 않기 때문에 QA 엔지니어들은 열등하게 여겨짐.

• 개인적인 경험에 따르면, 실제로 엔지니어링을 위한 테스트를 작성하는 QA 팀을 만나본 적이 없음. 대부분의 QA 팀은 '테스트 계획'을 수동으로, 또는 드물게 자동화된 브라우저/장치 테스트를 통해 실행함. 이러한 테스트 유형은 가치가 있지만, '단위 테스트'나 '통합 테스트'만큼은 아님. 이 모델에서는 실제 QA 팀보다 엔지니어링 팀이 실제로 QA 역할을 하게 되며, QA 팀은 종종 버그가 아닌 것을 버그로 찾아내어 가치를 떨어뜨림.

• 마이크로소프트는 QA 팀을 없앤 이후 윈도우와 클라우드 제품에서 더 많은 버그가 발생하는 것을 목격함.