1) 성공을 위해
소프트웨어와 시스템의 배포 이후, 결함으로 인한 장애 발생은 늘 있는 일입니다. 성공적인 결과를 위해서 최대한 결함을 줄여야 합니다. 이를 위한 적절한 시점에 알맞은 테스트를 실행한다면, 적어도 문제로 가득 찬 프로그램을 배포하는 경우를 줄일 수 있습니다.
위와 같은 상황이 벌어지지 않도록 하려면 언제 어떻게 테스팅을 해야 할 까요?
테스터를 요구사항 리뷰, 사용자 스토리 개선에 참여
요구사항을 검토하고, 사용자 스토리 개선에 테스터를 참여시키면 이른 시기에 결함을 발견하여 요구사항에 맞지 않으며 사용자 스토리에 적합하지 않은 잘못된 기능의 개발을 막을 수 있습니다.
테스터와 시스템 설계자의 협업
둘의 협업을 통해 시스템 설계자는 결함에 대한 이해도가 높아져 설계 과정에서 결함이 유입되는 위험이 줄어들고, 테스터는 설계 중인 프로그램에 대한 이해도가 높아져 필요한 테스트를 빠르게 식별할 수 있습니다. 이는 시스템의 결함을 줄이며, 빠른 결함 식별이 가능하게 합니다.
개발자와 협업
서로 코드와 테스트에 대한 이해가 높아지므로 코드 개발에서의 결함 유입이 감소하고, 테스트에서의 결함 식별이 늘어나게 됩니다.
배포 전에 확인, 검증
시스템의 장애를 발견하고 결함을 제거할 수 있어 이해관계자의 요구사항 충족도를 높일 수 있습니다.
빠른 결함의 식별은 전체 개발 기간을 줄일 수 있으며 이는 개발 비용, 시간을 절약하는 동시에 프로그램의 완성도, 충족도를 높일 수 있습니다.
2) 품질 보증(QA)과 테스팅
Q. QA랑 테스팅이랑 같은 거죠?
A. 아닙니다. QA와 테스팅은 크게 '품질 관리'에 속하는 하위 항목입니다.
품질 관리(Quality Management): 품질 측면에서 조직이 가야 하는 방향을 제시하고 제어하는 모든 활동.
품질 보증(Quality Assurance): 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수했는지에 초점.
- 프로세스를 따르면 작업 산출물의 품질은 더 좋아지며, 높음 품질의 산출물은 결함 예방을 합니다.
- 결함의 원인을 찾아 제거하기 위한 근본 원인 분석의 활용과 회고 회의의 결과를 통해 프로세스를 개선하는 것도 중요합니다.
품질 제어: 적합한 품질 수준을 달성하기 위한 다양한 활동. 테스트 활동이 포함됩니다.
3) 오류, 결함, 장애
오류는 결함을 발생시키고, 결함은 장애를 일으킵니다.
오류는 다른 오류의 원인이 될 수 있습니다.
ex) 요구 사항을 도출하며 생긴 오류는 요구사항 결함이 되며, 요구사항 결함은 프로그램 작성 시 오류를 일으켜 코드 결함의 원인이 됩니다.
Q. 결함은 반드시 장애를 발생시키나요?
A. 아닙니다. 결함 중 일부는 발생 가능성이 없거나 매우 낮아서 특수한 조건이 충족되어야 합니다.
오류 발생의 원인
- 시간적인 압박: 사람이 하는 일에 시간적인 압박은 실수로 인한 오류를 발생시킬 우려가 있습니다.
- 사람의 실수: 사람이 하는 일에 실수는 있기 마련입니다.
- 부족한 경험, 기술: 비숙련자는 실수로 인한 오류를 만들어 냅니다. 또한 기술 자체적인 오류가 있을 수 있습니다.
- 코드, 설계, 구조, 문제, 기술의 복잡도: 너무 복잡한 시스템은 작업자의 실수를 유발합니다.
- 시스템 인터페이스에 대한 이해 부족: 낮은 이해도는 오류를 만듭니다.
- 새롭고 익숙하지 않은 기술: 위의 부족한 경험, 기술과 비슷한 이유를 가지고 있습니다.
테스트 결과가 기대한 것과 다르다고 해서 장애가 있다고 할 순 없습니다.
예를 들어, 테스트 환경에서의 방사능, 전자기장, 환경오염에 의한 펌웨어나 하드웨어 적 손실이 결함의 원인이 되기도 합니다. 이러한 다양한 이유로 거짓 양성이 발생할 수 있으며 거짓 음성도 발생할 수도 있습니다.
거짓 양성(False Positive): 결함으로 보고 됐지만 실제 결함이 아닌 경우
거짓 음성(False Negative): 테스트를 통해 발견했어야 할 결함을 발견하지 못한 경우
4) 결함, 근본 원인, 결과
근본 원인: 결함을 만들어 낸 최초의 행동이나 조건.
우리는 결함을 분석함으로써 근본 원인을 찾을 수 있으며, 유사한 결함의 발생 가능성을 낮춥니다.
예시) A은행의 이자 계산 프로그램이 예금의 이자를 잘 못 계산하고 있다는 오류가 발견되었습니다. 이로 인해 많은 소비자들의 불만을 초래하였습니다. 이는 제품의 개발자가 이자 계산법을 이해하지 못한 채로 애매한 사용자 스토리를 기반으로 코드가 잘 못 작성되었기 때문입니다.
결함: 코드에 포함된 잘못된 이자 계산식
장애: 잘못된 이자 지급
결과: 소비자의 불만
최초 결함: 사용자 스토리의 모호성
최초 결함의 근본 원인: 제품 소유자의 지식 부족
해결: 결함이 이자 계산식에 존재하고 근본 원인도 비슷한 원인이라면 개발자에게 이자 계산에 대한 교육을 제공할 수 있습니다. 결함과 근본 원인이 비슷하므로 재교육을 통해 코드를 수정하기로 하였습니다.
이것은 '근본 원인 프로세스'라는 테스트 활동 중 하나입니다.