1970년대 후반 IBM에서 제품 보증 업무를 담당하며, 담당 제품(워드 프로세싱 시스템)의 테스트 코드 작성 및 하드웨어 구축을 했음. 개발팀에게는 테스트 케이스를 구체적으로 공개하지 않고 일반적인 문제점만 전달하여 버그 수정을 유도했음. 이 방식으로 발견한 버그와 개발팀이 수정한 버그 간의 불일치를 통해 남은 버그의 추정치를 통계적으로 계산할 수 있었음.
QA 팀이 없는 조직에서는 '스니프 테스트'라는 개념을 도입했음. 이는 회사의 모든 사람이 새 기능을 짧은 시간(보통 1시간) 동안 집중적으로 테스트하는 세션으로, 많은 버그 티켓을 생성하는 결과를 가져왔음. 간단한 테스트들이 문제를 일으키는 경우가 많았지만, 이제는 더 이상 놀랍지 않음.
15-20년 전에 일했던 두 회사는 최고 수준의 QA 팀에 투자했으며, 이들은 개발자들이 생각하지 못한 버그를 찾아내는 데 뛰어난 능력을 보였음. QA 팀이 제품 출시 여부를 결정하는 최종 권한을 가졌음. 현재 많은 회사들은 개발자가 자동화된 테스트를 작성하고 코드 커버리지에 많은 시간을 소비하는 것이 더 나은 방법이라고 생각하지만, 실제로 작동하지 않는 제품을 많이 보았음. 자동화된 테스트가 나쁘다는 것이 아니라, 인간 QA 테스터를 없애는 것에 대한 문제 제기임.
조직에서 가장 양심적인 직원들은 종종 가장 불만을 가지고 있음. 그들은 품질 문제를 인식하고 해결하려 하지만 인정받지 못하며, 품질에 대해 말하면 느리게 움직이려는 사람으로 취급받음. '빠르게 움직이고 물건을 부수는' 사람들이 계속해서 보상을 받는 동안, 그들은 뒤처리하는 데 화를 내며, 조직 내에서 신경 쓰는 것이 커리어에 해가 될 수 있음을 느낌.
QA는 비즈니스와 상위 경영진에 의해 '비용 센터'로 간주되는 경향이 있음. '비용 센터'로 여겨지는 부서에서 일하는 것은 피해야 한다는 가설이 있으며, 보상과 인정은 항상 수익을 창출하는 사람들에게 돌아감. QA는 더 많은 일을 더 적은 인원으로 해야 하고, 실패에 대해 비난받으며, 비즈니스가 슬림해져야 할 때 해고되는 첫 번째 장소가 될 수 있음.
QA 엔지니어들은 뛰어난 디버깅 능력을 가지고 있음. 그들은 파이프라인, 소스 코드, 테스트 디렉토리 등 애플리케이션의 모든 측면에서 작업하며, 종종 소프트웨어 엔지니어들이 파이프라인 오류 메시지를 읽지 않고, 기본 문제를 무시하며, 해결책을 추측하는 데 날을 보냄. QA 엔지니어에 대한 무시는 기사에서 과장된 것이 아니며, QA 조직이 엔지니어링 조직만큼 엄격한 면접 과정을 거치지 않기 때문에 QA 엔지니어들은 열등하게 여겨짐.
개인적인 경험에 따르면, 실제로 엔지니어링을 위한 테스트를 작성하는 QA 팀을 만나본 적이 없음. 대부분의 QA 팀은 '테스트 계획'을 수동으로, 또는 드물게 자동화된 브라우저/장치 테스트를 통해 실행함. 이러한 테스트 유형은 가치가 있지만, '단위 테스트'나 '통합 테스트'만큼은 아님. 이 모델에서는 실제 QA 팀보다 엔지니어링 팀이 실제로 QA 역할을 하게 되며, QA 팀은 종종 버그가 아닌 것을 버그로 찾아내어 가치를 떨어뜨림.
마이크로소프트는 QA 팀을 없앤 이후 윈도우와 클라우드 제품에서 더 많은 버그가 발생하는 것을 목격함.
Hacker News 의견
1970년대 후반 IBM에서 제품 보증 업무를 담당하며, 담당 제품(워드 프로세싱 시스템)의 테스트 코드 작성 및 하드웨어 구축을 했음. 개발팀에게는 테스트 케이스를 구체적으로 공개하지 않고 일반적인 문제점만 전달하여 버그 수정을 유도했음. 이 방식으로 발견한 버그와 개발팀이 수정한 버그 간의 불일치를 통해 남은 버그의 추정치를 통계적으로 계산할 수 있었음.
QA 팀이 없는 조직에서는 '스니프 테스트'라는 개념을 도입했음. 이는 회사의 모든 사람이 새 기능을 짧은 시간(보통 1시간) 동안 집중적으로 테스트하는 세션으로, 많은 버그 티켓을 생성하는 결과를 가져왔음. 간단한 테스트들이 문제를 일으키는 경우가 많았지만, 이제는 더 이상 놀랍지 않음.
15-20년 전에 일했던 두 회사는 최고 수준의 QA 팀에 투자했으며, 이들은 개발자들이 생각하지 못한 버그를 찾아내는 데 뛰어난 능력을 보였음. QA 팀이 제품 출시 여부를 결정하는 최종 권한을 가졌음. 현재 많은 회사들은 개발자가 자동화된 테스트를 작성하고 코드 커버리지에 많은 시간을 소비하는 것이 더 나은 방법이라고 생각하지만, 실제로 작동하지 않는 제품을 많이 보았음. 자동화된 테스트가 나쁘다는 것이 아니라, 인간 QA 테스터를 없애는 것에 대한 문제 제기임.
조직에서 가장 양심적인 직원들은 종종 가장 불만을 가지고 있음. 그들은 품질 문제를 인식하고 해결하려 하지만 인정받지 못하며, 품질에 대해 말하면 느리게 움직이려는 사람으로 취급받음. '빠르게 움직이고 물건을 부수는' 사람들이 계속해서 보상을 받는 동안, 그들은 뒤처리하는 데 화를 내며, 조직 내에서 신경 쓰는 것이 커리어에 해가 될 수 있음을 느낌.
QA는 비즈니스와 상위 경영진에 의해 '비용 센터'로 간주되는 경향이 있음. '비용 센터'로 여겨지는 부서에서 일하는 것은 피해야 한다는 가설이 있으며, 보상과 인정은 항상 수익을 창출하는 사람들에게 돌아감. QA는 더 많은 일을 더 적은 인원으로 해야 하고, 실패에 대해 비난받으며, 비즈니스가 슬림해져야 할 때 해고되는 첫 번째 장소가 될 수 있음.
QA 엔지니어들은 뛰어난 디버깅 능력을 가지고 있음. 그들은 파이프라인, 소스 코드, 테스트 디렉토리 등 애플리케이션의 모든 측면에서 작업하며, 종종 소프트웨어 엔지니어들이 파이프라인 오류 메시지를 읽지 않고, 기본 문제를 무시하며, 해결책을 추측하는 데 날을 보냄. QA 엔지니어에 대한 무시는 기사에서 과장된 것이 아니며, QA 조직이 엔지니어링 조직만큼 엄격한 면접 과정을 거치지 않기 때문에 QA 엔지니어들은 열등하게 여겨짐.
개인적인 경험에 따르면, 실제로 엔지니어링을 위한 테스트를 작성하는 QA 팀을 만나본 적이 없음. 대부분의 QA 팀은 '테스트 계획'을 수동으로, 또는 드물게 자동화된 브라우저/장치 테스트를 통해 실행함. 이러한 테스트 유형은 가치가 있지만, '단위 테스트'나 '통합 테스트'만큼은 아님. 이 모델에서는 실제 QA 팀보다 엔지니어링 팀이 실제로 QA 역할을 하게 되며, QA 팀은 종종 버그가 아닌 것을 버그로 찾아내어 가치를 떨어뜨림.
마이크로소프트는 QA 팀을 없앤 이후 윈도우와 클라우드 제품에서 더 많은 버그가 발생하는 것을 목격함.