STANDARD · IEEE
SWEBOK
소프트웨어 공학 지식 체계. 학계 이론이 아니라 "해보니 되더라"는 현장 경험의 집대성.
요구사항 식별
요구의 원천 데이터를 폭넓게 끌어내는 첫 단계. 정제는 다음 단계의 몫.
요구사항은 출처와 함께 기록해야 누락·중복·상충을 역추적할 수 있다. 식별 단계에서는 거르기보다 폭넓게 끌어내고, 정제는 분석 단계의 몫으로 분리하는 것이 원칙이다.
분석·설계 · 요구사항검증(Validation)
"제대로 된 것을 만들고 있는가"를 고객이 확인하는 활동. 요구사항의 1.0 확정.
Validation은 고객이 확인하는 ‘제대로 된 것인가’, Verification은 엔지니어가 검토하는 ‘제대로 만들었는가’이다. 명세 0.9는 고객 확인을 거쳐야 1.0이 되며, 이 구분이 검수 분쟁을 예방한다.
분석·설계 · 요구사항요구사항 분석
수집한 요구의 누락·중복·상충을 정리하고 실현가능성을 가린다.
요구사항 분석의 핵심은 요구를 더 모으는 것이 아니라 모인 요구의 충돌과 실현 불가능을 이해관계자 앞에서 먼저 드러내는 데 있다. 상충과 비기능 조건을 분석 단계에서 표면화하지 못한 요구는 반드시 개발 후반의 재작업으로 되돌아오며, 그때의 비용은 분석 단계에서 조정했을 때와 비교할 수 없이 커진다.
분석·설계 · 요구사항Trade-Off
하나를 높이면 다른 하나가 낮아지는 상충. 성능과 보안이 대표.
트레이드오프에서 진짜 위험은 상충 자체가 아니라, 그것을 인식하지 못한 채 현장에서 임의로 절충되는 것이다. 무엇을 우선하고 무엇을 양보했는지 비즈니스 우선순위에 근거해 결정하고 그 기준을 기록해 두어야, 이후 변경관리에서 결정을 흔들어도 되는지 판단할 근거가 남는다.
테스트 · 품질테스트 설계 기법
구조 기반·명세 기반·경험 기반의 세 갈래 기법.
테스트 설계 기법은 전수 시험이 불가능하다는 전제에서 출발해, 한정된 자원으로 결함을 가장 잘 찾을 케이스를 고르는 기술이다. 명세 기반·구조 기반·경험 기반은 서로의 사각지대를 메우므로 한 갈래에 의존하지 말고 위험 영역에 맞춰 조합하고, 도출한 케이스는 커버리지로 빈틈을 점검하는 것이 실무의 정석이다.
분석·설계 · 표준SWEBOK
소프트웨어 공학의 경험 지식 체계. 요구사항·테스트의 기준 근거.
SWEBOK은 절차서가 아니라 무엇을 빠짐없이 다루어야 하는지 알려 주는 분야의 지도다. 통독 대상이 아니라 요구사항·테스트가 합의 근거를 거슬러 올라가는지 점검하는 기준의 출처로 쓸 때 가장 유용하다. 관리 체계인 PMBOK과 짝을 이뤄야 관리와 공학이 한 프로젝트 위에서 맞물린다.
분석·설계 · 비교Validation vs Verification
고객이 확인하는 Validation, 엔지니어가 검토하는 Verification. 검수 분쟁의 핵심 구분.
Verification은 명세대로 만들었는지를 엔지니어가 검토하고, Validation은 실제 요구를 충족하는지를 고객이 확인한다. 검수 분쟁의 대부분은 이 둘의 혼동에서 비롯되므로, 요구사항마다 측정 가능한 수용 기준을 명세서에 미리 박아 두는 것이 가장 확실한 예방책이다.
분석·설계 · 비교Needs vs Requirements
잠재 요구(Needs)와 확정 요구(Requirements). 추가 요구는 대개 비기능에서 드러난다.
이해관계자의 말은 Needs일 뿐 Requirements가 아니다. 그 말 뒤의 의도를 검증 가능한 조건으로 다듬는 것이 분석의 본질이며, 명세에서 빠지기 쉬운 성능·보안·가용성 같은 비기능 Needs를 초기에 수치로 합의해 두는 것이 검수 분쟁을 막는 가장 확실한 장치다.
테스트 · 품질단위 테스트
함수·모듈 단위로 검증하는 가장 작은 테스트. QA의 출발점.
단위 테스트의 가치는 커버리지 숫자가 아니라 실패했을 때 원인을 즉시 짚어 주는 정밀함에서 나온다. 단언 없이 호출만 채워 수치를 올린 테스트는 통과해도 아무것도 보증하지 못하므로, 경계값과 예외 경로에 검증을 집중하는 편이 현장에서 훨씬 오래 버틴다.
테스트 · 품질통합 테스트
모듈 간 인터페이스 결합을 검증하는 테스트.
통합 테스트에서 터지는 결함의 상당수는 코드 자체가 아니라 모듈 간 인터페이스 명세의 모호함에서 비롯된다. 데이터 형식·오류 코드·호출 전제를 양쪽이 문서로 합의해 두지 않으면, 빅뱅으로 한꺼번에 붙였을 때 원인 구간을 좁히지 못해 일정이 무너지므로 결합은 추적 가능한 작은 단위로 진행하는 편이 안전하다.
테스트 · 품질시스템 테스트
전체 시스템을 요구사항 기준으로 검증. 비기능 검증 포함.
시스템 테스트에서 발목을 잡는 결함의 다수는 기능이 아니라 명세에 흐릿하게 적혔던 비기능 요구사항, 즉 성능·부하·보안에서 나온다. 더불어 개발 환경과 운영 환경의 데이터 규모·동시성 차이를 좁히지 못하면 시스템 테스트를 통과하고도 운영 직후 문제가 재발하므로, 운영에 준하는 환경을 확보하는 것이 검증 신뢰도의 전제가 된다.
테스트 · 품질회귀 테스트
변경 후 기존 기능의 무결성을 재검증하는 테스트.
한 번 통과한 시험이라도 코드가 바뀌면 그 통과는 무효가 되며, 표면상 무관한 기능이 공통 모듈을 공유해 함께 깨지는 일이 잦다. 회귀 세트를 자동화해 CI/CD에 연결하면 부작용이 운영까지 가기 전에 빌드 단계에서 차단되므로 수정 비용이 가장 낮은 지점에서 멈춘다.
테스트 · 품질화이트박스 테스트
내부 구조·로직을 보고 경로를 검증하는 구조 기반 테스트.
커버리지 수치는 검증이 닿지 않은 빈 곳을 가리키는 지표일 뿐, 결함이 없다는 증명이 아니다. 도달은 했으나 단언이 부실하면 통과만 하고 결함은 그대로 남으므로, 숫자를 채우기보다 위험이 큰 핵심 경로의 실질 검증을 우선하는 편이 옳다.
테스트 · 품질블랙박스 테스트
내부를 모른 채 입출력으로 검증하는 명세 기반 테스트.
블랙박스 테스트의 품질은 결국 요구사항과 명세의 품질을 넘지 못한다. 명세가 모호하면 통과한 테스트도 잘못된 동작을 정상으로 굳힐 수 있으므로, 테스트 케이스를 요구 항목과 추적 가능하게 연결해 검증의 빈틈과 변경 영향을 함께 드러내는 것이 실무의 정석이다.