2.11 소프트웨어 품질

개요와 동기

소프트웨어 품질은 시스템이 명시된 필요와 합리적인 기대를 얼마나 잘 충족하는가입니다. 동작하는지 이상을 뜻합니다. 시스템이 시간이 지나도 신뢰할 수 있고, 안전하고, 유지보수 가능하고, 사용하기 쉽고, 성능이 좋고, 목적에 맞는지를 뜻합니다. 품질은 테스트보다 넓습니다. 테스트(2.4장)는 결함을 드러내는 하나의 활동입니다. 품질은 올바른 것을 잘 만드는 전체 규율이며, 그렇게 했음을 증거로 아는 것입니다. 시스템은 모든 테스트를 통과하고도 유지보수할 수 없거나, 접근할 수 없거나, 사용자가 실제로 필요로 하는 것에 잘 맞지 않으면 품질이 낮을 수 있습니다.

큰 팀에서 품질은 한 사람의 머릿속이나 한 팀의 습관에 살 수 없습니다. 수백 명의 엔지니어, 여러 제품, 오래 사는 시스템에는 품질에 대한 공유된 정의, 그것을 보증하는 명시적 프로세스, 나아지는지 나빠지는지 알려 주는 측정이 필요합니다. 그것이 없으면 “품질”은 마감과의 모든 논쟁에서 지는 막연한 열망이 되고, 결함이 쌓여 변경이 느리고 위험해집니다.

기업과 정부 환경에서는 이해관계가 더 높아집니다. 규제를 받고, 안전이 핵심이고, 시민 대면인 시스템은 품질을 단지 주장하는 것이 아니라 입증해야 합니다. 문서화된 프로세스, 추적 가능한 증거, 독립적 검증이 의무인 경우가 많습니다. 나쁜 품질은 직접적인 재정적, 법적, 평판의 비용을 지며, 일부 영역에서는 사람을 위험에 빠뜨립니다. 모델, 프로세스, 측정, 문화로 만들어진 의도적인 품질 규율이 품질을 우연에서 관리되는 성과로 바꿉니다.

핵심 원칙

품질은 목적 적합성에 요구사항 적합성을 더한 것입니다. 둘 다 명시적으로 정의하십시오.
품질은 테스트로 넣는 것이 아니라 내장하는 것입니다. 검증은 결함을 찾고, 예방은 결함을 피합니다.
품질 보증(우리의 프로세스가 건전한가?)과 품질 통제(이 제품이 좋은가?)를 구분하십시오.
검증(verification)은 “올바르게 만들었는가?”를 묻고, 타당성 확인(validation)은 “올바른 것을 만들었는가?”를 묻습니다.
소수의 의미 있는 지표로 품질을 측정하십시오. 지표를 목표가 아닌 신호로 다루십시오.
결함의 비용은 늦게 발견될수록 오르므로, 품질 활동을 앞으로 당기십시오.
품질은 끝의 관문이 아니라 조직 전체와 그 문화의 속성입니다.

권장 사항

ISO/IEC 25010 같은 공유 품질 모델을 채택한다

인정받는 제품 품질 모델을 채택해 조직에 품질의 공통 어휘를 주십시오. ISO/IEC 25010은 기능 적합성, 성능 효율성, 호환성, 사용성, 신뢰성, 보안, 유지보수성, 이식성을 포함하는 특성을 정의합니다. 이를 품질을 구체적으로 만드는 데 쓰십시오. 각 시스템에서 어떤 특성이 가장 중요한지, 각각에 “충분히 좋음”이 무엇을 뜻하는지 정하십시오. 이런 제품 품질 특성은 아키텍처(3.1장)를 이끄는 바로 그 품질 속성입니다. 품질과 아키텍처는 하나의 관심사에 대한 두 시각이므로, 서로 경쟁하는 두 개가 아니라 하나의 우선순위 목록을 공유하게 하십시오.

품질 보증과 품질 통제를 분리한다

품질 보증(QA)과 품질 통제(QC)를 구별되지만 보완적인 활동으로 다루십시오. QA는 프로세스 지향이고 예방적입니다. 표준, 리뷰, 완료의 정의, 교육을 통해 일이 이루어지는 방식을 개선하여 애초에 결함이 나타날 가능성을 낮춥니다. QC는 제품 지향이고 탐지적입니다. 테스트, 코드 리뷰, 감사처럼 실제 작업 산출물을 검사해 들어온 결함을 잡습니다. 성숙한 조직은 둘 다에 투자하되 QA 쪽으로 기웁니다. 결함을 예방하는 것이 찾아서 고치는 것보다 싸기 때문입니다.

명시적인 소프트웨어 품질 관리 프로세스를 운영한다

품질을 조용한 희망이 아니라 관리되는 프로세스로 만드십시오. 중요한 작업에는 목표 품질 특성, 보증 및 통제 활동, 인수 기준, 책임자를 밝히는 품질 계획을 쓰십시오. 이미 가진 관행에 엮어 넣으십시오. 통제이자 지식 공유 방법으로서의 코드 리뷰(2.5장), 자동화된 안전망으로서의 테스트 전략(2.4장), 지속적 검사로서의 정적 분석입니다. 품질 데이터를 정기적으로 검토하고 인시던트에만 반응하는 대신 추세에 따라 행동하십시오.

검증과 타당성 확인을 별개의 규율로 실천한다

검증(verification)은 작업 산출물이 명세를 충족하는지, 즉 각 단계의 올바른 입력이 올바른 출력을 내는지 리뷰, 정적 분석, 요구사항에 대한 테스트로 확인합니다. 타당성 확인(validation)은 완성된 시스템이 사용자 필요와 의도된 용도를 실제로 충족하는지 사용자 테스트, 인수 테스트, 파일럿, 현장 피드백으로 확인합니다. 둘 다 필요합니다. 시스템은 결함 있는 명세에 비추어 올바를 수 있고(검증되었으나 타당하지 않음), 진짜 필요를 다루면서도 결함이 있을 수 있습니다(타당하나 검증되지 않음). 규제 환경에서는 개발자와 별개의 당사자가 수행하는 독립적 검증 및 타당성 확인(IV&V)이 요구될 수 있습니다.

의미 있는 지표로 품질을 측정한다

품질 성과와 그 동인을 반영하는 소수의 지표를 골라 시간에 따라 지켜보십시오. 유용한 척도로는 결함 밀도, 결함 유출률(릴리스 전 대비 프로덕션에서 발견된 결함), 탐지 및 수리까지의 평균 시간, 변경 실패율, 복잡도와 중복 같은 코드 건강 신호, 사용자가 보고한 문제와 접근성 적합성 같은 타당성 확인 신호가 있습니다. 허영 지표와 조작 가능한 지표는 피하십시오. 목표가 된 지표는 현실을 측정하기를 멈춥니다. 숫자를 리뷰와 사용자 피드백의 정성적 신호와 짝지으십시오.

결함을 체계적으로 특성화하고 관리한다

결함을 꺼야 할 불이 아니라 데이터로 다루십시오. 심각도, 유형, 근본 원인으로 분류하십시오. 발견에서 해결까지 추적하십시오. 재발을 예방할 수 있도록 패턴을 찾으십시오. 근본 원인 분석과 결함 분류 같은 기법으로 일회성 실수를 체계적 약점과 구분하십시오. 배운 것을 갱신된 표준, 추가된 테스트, 개선된 리뷰로 QA에 되먹임해 같은 부류의 결함이 돌아오지 않게 하십시오. 원인을 이해하지 못한 채 고친 결함은 다시 초대한 결함입니다.

품질 비용을 의도적으로 관리한다

고전적인 범주로 품질 경제학을 이해하십시오. 예방 비용(교육, 표준, 좋은 설계, 도구), 평가 비용(리뷰, 테스트, 감사), 실패 비용(릴리스 전의 내부 재작업과 사용자가 발견하는 훨씬 비싼 외부 실패)입니다. 투자를 예방과 초기 평가 쪽으로 옮기십시오. 거기에 쓴 한 푼이 나중의 여러 푼의 실패 비용을 피하기 때문입니다. 이 비용을 보이게 하여 “품질에 쓸 시간이 없다”가 실제로는 대신 실패에 더 쓰겠다는 선택임이 드러나게 하십시오.

품질 문화를 만든다

품질을 모두의 책임으로 만들고, 끝에서 검사하는 하류의 QA 부서에 넘기지 말고 소프트웨어를 만드는 팀이 소유하게 하십시오. 리더는 품질 성과에 보상하고, 결함과 아차 사고를 보고하는 것을 안전하게 만들고, 품질 데이터를 몽둥이가 아닌 학습 도구로 다뤄야 합니다. 결함에 대한 비난 없는 접근은 문제를 일찍 드러냅니다. 비난하는 접근은 비싸질 때까지 숨깁니다.

장단점

관행 / 선택	장점	단점
공식 품질 모델 (ISO 25010)	공유 어휘. 명시적 우선순위	교조적으로 적용하면 오버헤드
무거운 품질 보증 (예방)	더 적은 결함. 더 낮은 총비용	선행 투자. 성과가 늦게 나타남
무거운 품질 통제 (검사)	빠져나간 결함을 잡음	비쌈. 결함을 늦게 발견
독립 V&V	높은 보증. 객관적	비용이 큼. 더 느림. 적대적으로 느껴질 수 있음
풍부한 품질 지표	가시성. 조기 경보	조작 위험. 측정 오버헤드
전담 QA 팀	집중과 전문성	개발자의 책임을 덜어 줄 수 있음
팀이 소유하는 품질	소유 의식. 빠른 피드백	전반에 걸친 규율과 기술이 필요

핵심 트레이드오프는 투자 대 보증이며, 시기에 의해 형성됩니다. 예방은 나중의 더 큰 실패 비용을 피하려고 지금 돈을 씁니다. 그래서 경제적으로 알맞은 품질 수준은 최대가 아닙니다. 더 많은 보증의 한계 비용이 그것이 피하는 실패 비용과 같아지는 점입니다. 그 점은 안전 핵심 시스템에서는 높고 위험이 낮은 내부 도구에서는 낮습니다. 또 다른 반복되는 긴장은 소유권입니다. 중앙 QA 그룹은 전문성을 쌓지만 개발자가 책임을 덜게 할 수 있습니다. 팀이 소유하는 품질은 소유 의식을 쌓지만 모든 곳에서 기술과 규율을 요구합니다.

팀과 논의할 질문

같은 부류의 결함이 두 번 나타나면 근본 원인 분석을 하며, 아니면 그냥 다시 고칩니까? 원인을 이해하지 못한 채 고친 결함은 다시 초대한 결함이며, 큰 팀에서는 아무도 점을 잇기 전에 같은 근본 원인이 많은 서비스에 걸쳐 표면화될 수 있습니다. 결함을 데이터로 다루는 것(심각도, 유형, 원인으로 분류하고 패턴을 캐는 것)이 꾸준히 더 믿을 만해지는 팀과 같은 실수를 다시 고치느라 바쁜 팀을 가릅니다. 결함 추적기를 회의에 가져와 반복되는 특징을 찾아보십시오. 최근 인시던트 중 체계적으로 다루지 않은 원인을 공유하는 것이 몇 건입니까? 답은 예방에 공급되어야 합니다. 반복되는 원인이 갱신된 표준, 새 공유 헬퍼, 추가된 테스트, 더 나은 리뷰 체크리스트를 이끌어야 합니다. 한 곳의 수정이 부류 전체가 돌아오는 것을 멈추는 방법이기 때문입니다.
우리 팀에서 결함이나 아차 사고를 보고하는 것은 안전하며, 보고한 사람에게는 무슨 일이 일어납니까? 품질은 문화의 속성이며, 비난 없는 접근은 문제를 일찍 드러내고 비난하는 접근은 비싸질 때까지 숨깁니다. 규제 또는 시민 대면 시스템에서 이는 공개적 실패나 벌금을 뜻할 수 있습니다. 위험에 가장 가까운 엔지니어가 주니어인 경우가 많고 침묵을 지킬 유인이 강한 규모에서 가장 중요합니다. 정직한 신호를 가져오십시오. 아차 사고가 기록되고 논의됩니까, 사라집니까? 사후 검토는 원인에 이름을 붙입니까, 사람에게 이름을 붙입니까? 행동은 품질 데이터를 몽둥이가 아닌 학습 도구로 만들고, 문제를 드러내는 사람에게 보상하고, 비난 없는 사후 검토를 실행하는 것입니다. 팀이 보고하기를 두려워하는 것은 예방할 수 없기 때문입니다.
타당성 확인이 실제로 릴리스를 막을 수 있으며, 마감이 다가올 때 그 권한은 누구에게 있습니까? 검증(올바르게 만들었는가?)과 타당성 확인(올바른 것을 만들었는가?)은 별개의 규율이며, 타당성 확인은 실패한 접근성 검사, 실패한 인수 테스트, 결정적인 사용자 리서치가 정말로 출시를 막을 수 있을 때만 힘이 있습니다. 기업과 정부 환경에서 이는 의무인 경우가 많고, 때로는 개발자와 별개의 당사자에 의한 독립적 검증 및 타당성 확인을 통해서이며, “그래도 출시했다”는 감독 기관이 받아들이는 답이 아닙니다. 최근 몇 번의 릴리스를 가져오십시오. 어떤 품질 신호가 실제로 하나라도 멈춘 적이 있습니까, 아니면 관문은 항상 날짜에 양보합니까? 타당성 확인이 릴리스를 막은 적이 없다면 장식입니다. 해법은 품질 계획에 인수 기준을 앞서 쓰고, 가부 결정의 소유자를 정하고, 그 결정에 전달 압력과 독립적인 실제 권한을 주는 것입니다.
우리의 불량 품질 비용을 실제로 알고 있으며, 지출을 실패에서 예방으로 의도적으로 옮기고 있습니까? 불량 품질 비용(COPQ)은 내부 재작업, 프로덕션 인시던트, 긴급 수정, 지원 부하, 잃은 사용자, 벌금으로 잃는 돈이며, 리뷰와 테스트에 쓰는 눈에 보이는 지출보다 거의 항상 큽니다. 큰 팀에서 실패 비용은 인시던트 채널, 지원 대기열, 아무도 재작업으로 기록하지 않는 재작업에 흩어져 있어, 누군가 합산하기 전까지 보이지 않습니다. 긴장은 예방이 예산 주기에서 지금 돈이 들어 나중에 다른 사람의 예산에 떨어질 실패 비용을 피하는 것이므로, 거래를 영원히 미루기 쉽다는 점입니다. 실제 수치를 가져오십시오. 인시던트 수와 비용, 재작업 시간, 유출된 결함 비율, 예방, 평가, 실패에 걸친 현재 지출의 분할을 가져와 혼합을 더 앞으로 옮겨야 할지 결정하십시오. 수명 비용의 대부분이 첫 릴리스 이후에 떨어지는 기업과 정부 시스템에서는 COPQ를 예산을 쥔 사람들 앞에 놓으십시오. 감독 기관이 볼 수 있는 숫자는 “품질”에 대한 막연한 호소보다 맞바꾸기 훨씬 어렵기 때문입니다.
우리의 품질 지표 중 어느 것이 조용히 목표가 되었으며, 이제 어떤 행동을 이끌고 있습니까? 목표가 된 지표는 현실을 측정하기를 멈춥니다. 커버리지 비율을 쫓으면 결함을 잡는 테스트가 아니라 숫자를 움직이는 테스트가 나옵니다. 규모에서 이는 위험합니다. 수십 개 팀에 공유되는 헤드라인 대시보드가 모두의 유인을 정하고, 조작 가능한 지표는 조작을 모든 곳에 한꺼번에 퍼뜨리기 때문입니다. 상충하는 고려는 여전히 측정이 필요하다는 점이므로, 답은 거의 “지표를 버려라”가 아니라 “반대 신호와 짝짓고 리뷰와 사용자의 정성적 증거와 함께 읽어라”입니다. 현재 지표 집합을 가져와 각각에 대해 압박 아래 있는 사람이 품질을 개선하지 않고 그것을 움직이려고 무엇을 할 수 있는지, 그런 일이 일어나는 것을 본 적이 있는지 물으십시오. 규제 및 시민 대면 환경에서는 근본적인 타당성 확인(접근성, 실제 사용자 성과)이 진정으로 수행된 적 없는데 초록으로 보이는 적합성 지표를 특히 경계하십시오. 감사자는 결국 숫자 뒤의 현실을 시험할 것이기 때문입니다.
여기서 품질은 누가 소유하는가: 코드를 쓰는 팀인가, 끝의 별개 그룹인가, 그리고 우리는 실제로 어느 쪽에 자원을 대고 있습니까? 소유권이 하류의 모든 것을 형성합니다. 하류 QA 사일로는 개발자가 쓰는 코드에 대한 책임을 덜게 하고, 팀이 소유하는 품질은 모든 팀에 기술과 규율을 요구하는 대가로 소유 의식을 쌓습니다. 큰 팀에서 이것은 둘 중 하나가 아닙니다. 지속 가능한 패턴은 보통 팀이 코드 리뷰와 자동화된 테스트를 통해 품질을 소유하고, 끝에서 품질을 검사해 넣는 대신 표준을 유지하고, 프로세스 개선으로서 품질 보증을 운영하고, 코칭하는 작은 중앙 그룹이 지원하는 것입니다. 품질 작업이 현재 어디서 일어나는지, 결함이 빠져나갈 때 누가 책임지는지, 예산과 인원이 실제로 어디에 있는지 대 수사가 품질이 사는 곳이라고 말하는 곳에 대한 정직한 지도를 가져오십시오. 기업과 정부 조직에서는 독립적 검증 및 타당성 확인 요건을 더하십시오. 일부 보증 체계는 별개의 당사자를 의무화하므로, 어떤 통제가 전달 팀에 속하고 어떤 것이 감사를 충족하려면 독립적으로 남아야 하는지 의도적으로 정하십시오.

분야별 관점

스타트업. 의식보다 속도가 중요하니, 제품을 실제로 지키는 두세 가지 품질 특성, 대개 신뢰성과 유지보수성을 이름 붙이고 세련됨은 기다리게 하십시오. 인력을 둘 수 없는 별도 QA 그룹을 세우기보다 코드 리뷰와 적당한 자동화 테스트 스위트로 팀 전체가 품질을 소유하게 하십시오. 같은 부류의 버그가 두 번 나타나면 근본 원인에 20분을 쓰고 공유 헬퍼 하나와 테스트를 추가해, 예방이 싸게 유지되고 빠르게 움직이는 동안 변경 실패율이 낮게 유지되게 하십시오.

소기업. 전담 품질 전문가도 빠듯한 예산도 있으니, 운영해야 하는 프로세스보다 구매하는 도구와 플랫폼에 내장된 품질에 의지하십시오. 소프트웨어를 고를 때 벤더의 품질 증거를 구매의 일부로 다루십시오. 보안 태세, 접근성, 지원 응답성, 릴리스가 얼마나 자주 깨지는지입니다. 유지할 사람이 없는 정교한 지표 프로그램 대신, 프로덕션 인시던트, 고객이 보고한 문제, 수정까지의 시간 같은 싸고 정직한 신호 몇 개를 추적하십시오.

대기업. 일은 많은 팀에 걸친 일관성입니다. ISO/IEC 25010 같은 공유 품질 모델을 채택하고, 품질 보증(프로세스)과 품질 통제(제품)를 구분하고, 지출을 예방 쪽으로 옮기는 품질 비용 검토를 운영하십시오. 품질은 전달 팀이 소유하게 하되, 표준을 유지하고 결함 유출률, 변경 실패율, 코드 건강 추세의 대시보드를 두는 작은 중앙 그룹이 지원하게 하십시오. 어휘와 관문을 표준화해 그룹들이 품질 관행을 재발명하지 않게 하되, 팀이 그 기준을 자기 방식으로 충족할 여지를 남기십시오.

정부. 조달, 투명성, 공적 책임성이 틀을 정하니, 품질 요구사항을 계약에 쓰고 주장이 아닌 문서화되고 추적 가능한 품질 증거를 요구하십시오. 개발자와 별개의 당사자에 의한 독립적 검증 및 타당성 확인, 의무적인 접근성 적합성, 감사 추적의 일부로 유지되는 심각도와 근본 원인이 있는 결함 기록을 기대하십시오. 불량 품질 비용 수치(재작업, 이의 신청, 서비스 실패)를 감독 기관에 보고하고, 타당성 확인이 의존하는 시민을 실패시킬 릴리스를 막을 실제 권한을 갖게 하십시오.

사례

스타트업. 다섯 명 규모의 스타트업은 초기 제품에서 중요한 품질 특성이 신뢰성과 유지보수성이라고 정하고 픽셀 단위 세련됨은 기다리게 합니다. 품질은 팀 전체가 소유합니다. 코드 리뷰와 적당한 자동화 테스트 스위트가 통제이며, 결함을 넘길 별도의 QA 그룹은 없습니다. 같은 부류의 버그가 두 번 나타나면 빠른 근본 원인 점검에 20분을 쓰고 공유 헬퍼 하나와 테스트를 추가해, 매번 손으로 다시 고치는 대신 재발이 멈춥니다. 그 작은 예방 습관이 빠르게 움직이는 동안 변경 실패율을 낮게 유지합니다.

대기업. 한 대형 금융 서비스 회사는 ISO/IEC 25010을 품질 어휘로 채택하고, 제품마다 신뢰성, 보안, 유지보수성의 목표 수준을 기록합니다. 팀이 품질을 소유합니다. 코드 리뷰와 자동화 테스트는 파이프라인의 통제이고, 작은 중앙 그룹은 표준을 유지하고 코칭하며 QA를 운영합니다. 품질 대시보드가 결함 유출률, 변경 실패율, 코드 건강 추세를 추적합니다. 결함은 분류되고 근본 원인이 분석되며, 반복되는 원인은 공유 라이브러리와 체크리스트의 갱신을 이끕니다. 리더십은 분기마다 품질 비용 데이터를 검토하고 지출을 예방 쪽으로 옮겨 프로덕션 인시던트와 그것을 고치는 비용을 모두 줄였습니다.

정부. 시민 대면 급여 플랫폼을 제공하는 한 국가 기관은 문서화된 품질 증거를 요구하는 보증 체계 아래 일합니다. 릴리스마다 품질 계획이 있는 공식 품질 관리 프로세스를 운영하고, 개발자와 별개의 팀이 하는 독립적 검증 및 타당성 확인을 둡니다. 검증은 정책까지 추적된 요구사항에 대해 각 작업 산출물을 확인합니다. 타당성 확인에는 접근성 적합성 테스트와 실제 시민과의 사용자 리서치가 포함되며, 어느 쪽이든 릴리스를 막을 수 있습니다. 결함은 감사 추적의 일부로 심각도와 근본 원인과 함께 추적되고, 불량 품질 비용 수치(재작업, 이의 신청, 서비스 실패)가 감독 기관에 가서 예방에 대한 지속적 투자를 정당화합니다.

비즈니스 사례: 동기, ROI, TCO

품질의 수익은 더 낮은 총소유비용과 꾸준한 전달 속도입니다. 품질 비용에는 두 측면이 있습니다. 좋은 지출인 예방과 평가는 눈에 보이고 통제할 수 있습니다. 설계, 표준, 리뷰, 테스트, 도구입니다. 불량 품질 비용(COPQ)은 더 크지만 숨겨진 경우가 많습니다. 내부 재작업, 프로덕션 인시던트, 긴급 수정, 고객 지원, 잃은 사용자, 규제 벌금, 평판 훼손입니다. Crosby의 “Quality Is Free”까지 거슬러 올라가는 연구는 불량 품질의 총비용이 그것을 예방하는 비용을 압도하며, 결함이 늦게 잡힐수록 훨씬 비싸진다는 것을 일관되게 발견했습니다. 설계에서 발견한 문제는 프로덕션에서 발견한 같은 문제의 비용의 일부에 불과합니다.

리더십에게 논거는 “품질에 더 써라”가 아닙니다. “전체적으로 덜 쓰려면 일찍 써라”입니다. 자체 데이터(인시던트 수와 비용, 재작업 시간, 유출된 결함 비율)에서 COPQ를 정량화하고 예방과 초기 평가가 그것을 어떻게 낮추는지 보이십시오. 품질을 사업 성과에 연결하십시오. 신뢰성은 고객을 붙잡고, 유지보수성은 미래의 변경을 싸게 유지하고, 보안과 접근성은 법적 곤란을 피하게 합니다. 비용의 대부분이 첫 릴리스 이후에 떨어지는 오래 사는 기업과 정부 시스템에서는 품질의 유지보수성과 신뢰성 차원이 수명 비용을 지배합니다. 그래서 초기 품질 투자는 내릴 수 있는 지렛대 효과가 가장 큰 결정 중 하나입니다.

안티패턴과 함정

최종 관문으로서의 품질: 품질을 내장하는 대신 끝에서 검사하여 결함이 가장 비쌀 때 발견되는 것.
테스트와 품질의 혼동: 테스트 통과가 높은 품질을 뜻한다고 가정하고 유지보수성, 사용성, 목적 적합성을 무시하는 것.
별개의 사일로로서의 QA: “품질을 소유하는” 하류 팀이 개발자가 쓰는 코드에 대한 책임을 덜게 하는 것.
지표 연극: 커버리지 비율이나 결함 수를 목표로 쫓아 조작을 부르고 실제 품질을 가리는 것.
타당성 확인 없는 검증: 명세를 올바르게 만들면서 명세가 진짜 필요를 충족하는지 확인한 적이 없는 것.
근본 원인 분석 없음: 체계적 원인을 다루지 않고 결함을 하나씩 고쳐 같은 부류가 반복되는 것.
불량 품질 비용 무시: 실패 비용이 숨겨지고 측정되지 않아 품질을 순수한 비용으로 다루는 것.

성숙도 모델

1단계(시작). 품질은 정의되지 않고 그때그때 이루어집니다. 개인의 성실에 실려 있고, 주로 끝의 수동 테스트로 확인되며, 결함은 드러날 때 반응적으로 다뤄집니다. 공유 모델도, 지표도, 보증과 통제 사이의 구분도 없습니다.

2단계(발전). 코드 리뷰, 자동화 테스트, 결함 추적기 같은 기본 관행이 나타납니다. 일부 품질 데이터가 수집되지만 고르지 않고 팀마다 자기 방식으로 합니다. 품질은 여전히 대부분 테스트로 보이고, 예방은 최소이며, 검증은 이루어지고 타당성 확인은 비공식적입니다.

3단계(표준화). 조직이 (ISO/IEC 25010 같은) 공유 품질 모델을 채택하고, QA를 QC와 분리하고, 품질 계획과 인수 기준을 갖춘 품질 관리 프로세스를 문서화해 팀 전반에 일관되게 적용합니다. 검증과 타당성 확인은 별개이고 의도적이며, 결함은 합의된 체계에 따라 분류되고 근본 원인이 분석됩니다.

4단계(관리). 품질이 기준선에 대해 측정되고 통제됩니다. 소수의 의미 있는 지표(결함 밀도, 결함 유출률, 탐지 및 수리까지의 평균 시간, 변경 실패율, 복잡도와 중복 같은 코드 건강 신호)가 시간에 따라 추적되고, 품질 비용이 예방, 평가, 실패에 걸쳐 정량화됩니다. 인수 및 품질 관문은 의견이 아닌 증거에 따라 시행되고, 추세는 고정된 주기로 검토되며, 타당성 확인은 릴리스를 진정으로 막을 수 있습니다.

5단계(오케스트레이션). 품질이 비즈니스와 위험 계획에 통합된, 지속적으로 개선되고 문화적으로 소유되는 규율입니다. 예방이 강조되고, 품질 비용 데이터가 투자가 가는 곳을 이끌며, 근본 원인 발견이 재발을 체계적으로 막습니다. 팀이 품질을 끝에서 끝까지 소유하고, 지표가 지속적 개선에 공급되며, 조직은 제품, 위험, 규제가 변함에 따라 품질 실천을 적응시킵니다. 이는 10.8장의 성숙도 모델의 높은 단계와 맞닿아 있습니다.

논의를 위한 아이디어

ISO/IEC 25010의 어떤 품질 특성이 시스템에 가장 중요하며, 각각에 “충분히 좋음”은 무엇입니까?
조직의 예방-평가-실패 지출 혼합은 어디에 있으며, 옮겨야 합니까?
실제로 검증과 타당성 확인을 구분합니까, 아니면 둘 다 “테스트”로 뭉뚱그립니까?
품질은 소프트웨어를 만드는 팀이 소유합니까, 별개의 그룹에 위임됩니까, 옮기면 무엇이 달라지겠습니까?
진짜 불량 품질 비용은 얼마이며, 사업 논거를 세울 만큼 잘 측정할 수 있겠습니까?
품질 지표 중 어느 것이 진짜 신호이고, 어느 것이 조작 가능한 목표가 되었습니까?

핵심 요점

품질은 테스트보다 넓습니다. 신뢰성, 보안, 유지보수성 같은 특성에 걸친 목적 적합성에 적합성을 더한 것입니다.
공유 품질 모델(ISO/IEC 25010)을 써서 품질 속성이 명시적이고 아키텍처(3.1장)와 정렬되게 하십시오.
품질 보증(예방, 프로세스)과 품질 통제(탐지, 제품)를 분리하고 예방 쪽으로 기우십시오.
검증(올바르게 만들었는가)과 타당성 확인(올바른 것을 만들었는가)을 별개의 규율로 실천하십시오.
소수의 의미 있는 지표로 품질을 측정하고, 재발을 예방하도록 결함을 심각도와 근본 원인으로 특성화하십시오.
품질 비용을 관리하십시오. 예방과 초기 평가는 특히 오래 사는 시스템에서 실패보다 훨씬 쌉니다.
코드 리뷰(2.5장)와 테스트 전략(2.4장)의 지원을 받아 팀이 품질을 소유하는 비난 없는 품질 문화를 만드십시오.

참고 문헌과 더 읽을거리

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), Software Quality knowledge area.
ISO/IEC 25010, Systems and software engineering: Systems and software Quality Requirements and Evaluation (SQuaRE): System and software quality models.
ISO/IEC 25000 series (SQuaRE), Software product quality requirements and evaluation.
Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain.
W. Edwards Deming, Out of the Crisis.
Capers Jones and Olivier Bonsignour, The Economics of Software Quality.
Gerald Weinberg, Quality Software Management.
ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (quality assurance and V&V process context).