2002년, 미국 국립표준기술원(NIST)은 부적절한 소프트웨어 테스트의 경제적 영향을 자세히 설명하는 보고서를 발표했습니다(NIST 보고서, 2002). 보고서는 다음과 같이 결론지었습니다.
“… 소프트웨어 테스트를 위한 부적절한 인프라로 인한 전국 연간 비용은 222억 달러에서 595억 달러에 이를 것으로 추산됩니다.”
NIST 보고서는 또한 소프트웨어 테스팅 관행의 상태가 매우 부족하다는 점을 지적했습니다.
7년 후, Wong et al.은 IEEE 신뢰성 협회 보고서(Wong et al., 2009)에서 여러 가지가 인명 손실로 이어진 15가지의 널리 알려진 소프트웨어 오류를 검토하고 다음과 같은 결론을 내렸습니다.
“…더 나은 테스트 절차와 관행이 구현되어야 하며, 이는 특히 안전에 중요한 시스템과 관련된 소프트웨어에 해당합니다.”
최근 기사에서 Wong et al.은 여러 산업에 걸친 다양한 소프트웨어 실패를 조사했고(Wong et al., 2017) 다소 냉정한 지적을 했습니다.
“…실망스러운 사실은 소프트웨어가 결함이 없는 것과는 거리가 멀고 매년 (결함이 있는) 소프트웨어를 수정하거나 유지하는 데 많은 돈이 쓰인다는 것입니다.”
이 기사에서는 1985년부터 2015년까지 30년간의 소프트웨어 오류를 분석했습니다. 오류를 촉발한 소프트웨어 버그의 특성과 사용자 오류와 같은 기타 기여 요인을 식별하고 오류를 두 가지 범주로 분류했습니다. 치명적(사망으로 이어짐)인 오류와 치명적이지는 않지만 상당한 경제적 손실을 초래한 오류입니다. 치명적인 오류에는 최소 6명의 환자가 과다한 방사선에 노출된 1985년 Therac-25 사고와 650명 이상이 목숨을 잃은 1995년~1997년의 민간 항공 사고가 포함되었습니다. 또한 전자 건강 기록 소프트웨어 오류로 인해 에볼라에 감염된 환자를 잘못 진단하여 이후 사망에 이르게 한 2014년 에볼라 사건도 포함되었습니다. 치명적이지 않은 오류에는 200만 달러의 손실을 초래한 원자력 발전소 소프트웨어 오류와 70억 달러의 손실을 초래한 Ariane 5 소프트웨어 오류가 포함되었습니다. 저자는 결론에서 다음과 같은 관찰 결과를 제시했습니다.
“… 공공 인프라, 교통 시스템, 소비자 제품 등에서 내장 소프트웨어가 널리 퍼져 있는 현실은 복잡한 소프트웨어 시스템을 다루어 온 사람이 결함 없이 그러한 시스템을 구축할 수 있다고 믿을 수 있다는 사실에 [우리는] 믿을 수 없게 만듭니다…”
안타깝게도, 우리가 점점 더 의존하고 있는 소프트웨어 시스템 유형에 대한 이러한 냉정한 설명에도 불구하고, 이러한 논의에서 빠진 핵심 요점이 있습니다. 즉, 대부분의 소프트웨어 오류는 감지되지 않고 보고되지 않습니다. 어떤 경우에는 오류가 미묘하거나 간헐적이어서 쉽게 간과됩니다. 예를 들어, 통계 소프트웨어 애플리케이션은 잘못 계산된 통계를 제시할 수 있습니다. 이러한 잘못 계산된 통계는 오류이지만, 특히 비전문가에게는 즉시 나타나지 않을 수 있습니다. 그럼에도 불구하고 이러한 오류는 잘못된 또는 최적이 아닌 결정으로 이어질 수 있으며 따라서 매우 중대한 결과를 초래할 수 있습니다.
통합 개발 환경의 정교함, 프로그래밍 방법의 정교함 또는 프로그래머의 기술과 관계없이 소프트웨어를 작성하는 기술은 불완전한 기술이며 버그가 발생할 것이라는 것은 분명합니다. 이러한 현실은 소프트웨어가 출시되기 전에 이러한 버그를 발견하는 것은 소프트웨어 테스트 노력의 엄격성에 달려 있음을 의미합니다. NIST와 Wong et. al.에서 지적했듯이, 그렇게 하지 못하면 중대한 결과가 초래될 수 있습니다. 소프트웨어 엔지니어링 커뮤니티의 상징적 인물인 Barry Boehm은 소프트웨어 엔지니어링 경제학에 대한 그의 획기적인 논문(Boehm, 1984)에서 소프트웨어 배포 후에 버그를 찾아 수정하는 비용은 일반적으로 배포 전에 버그를 식별하여 수정하는 비용보다 최소 100배 더 많다고 지적했습니다.
이런 배경을 감안할 때, 소프트웨어 테스팅 방법이 단순히 부적절하다는 것이 사실일까요? 저는 그렇지 않다고 주장하고 싶습니다. 사실, 소프트웨어 테스팅 연구는 50년 이상 활발한 연구 분야였습니다. 2014년에 Orso와 Rothermel은 논문을 발표하기 전 15년 동안 소프트웨어 테스팅 방법 개발에서 상당한 진전이 있었다고 기술했습니다(Orso and Rothermel, 2014). 2000년 이전의 15년은 소프트웨어 테스팅 방법에서 극적인 발전이 있었던 기간이기도 했습니다. 소프트웨어 테스팅 커뮤니티의 상징적 인물인 Glenford Myers(Myers, 1978)와 Boris Beizer(Beizer, 1984)는 70년대와 80년대에 선구적인 작업을 했습니다. 안타깝게도 가장 중요한 문제는 테스팅 방법의 적절성이 아니라 도입입니다. 소프트웨어 개발 커뮤니티는 수년에 걸쳐 엄격한 소프트웨어 테스팅 방법을 채택하는 데 느렸는데, 그 유용성에 대한 실증적 증거가 있음에도 불구하고(Kuhn et. al., 2015, Morgan, 2018). 이 상황은 두 가지 소프트웨어 개발 현실에 의해 악화되었습니다. 소프트웨어 테스팅 노력은 자금과 자원이 부족한 것으로 악명 높습니다. 게다가 소프트웨어 개발 노력의 속도와 복잡성은 최근 몇 년 동안 극적으로 증가했습니다.
소프트웨어 시스템은 그 어느 때보다 보편화되어 있으며 우리 삶에서 점점 더 중요한 역할을 하고 있습니다. 견고한 소프트웨어 테스트 방법의 중요성은 분명하며 모든 소프트웨어 개발 실무자가 더 잘 알아야 할 소프트웨어 개발의 한 측면입니다. 이러한 필요성을 해결하기 위해 이 블로그 게시물 시리즈를 시작했습니다. 이 게시물은 그 시리즈의 두 번째 게시물이며 앞으로 더 많은 게시물이 있을 것입니다.
인용된 작품
Beizer, Boris. 소프트웨어 시스템 테스트 및 품질 보증 . Van Nostrand Reinhold Co., 1984.
Boehm, Barry W. "소프트웨어 엔지니어링 경제학." IEEE 소프트웨어 엔지니어링 거래 (1984): 4-21.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN(2015). "조합 테스트: 이론과 실제." Advances in Computers , 99 , 1-66.
Myers, Glenford J. “프로그램 테스트 및 코드 연습/검사의 통제된 실험.” ACM 커뮤니케이션 21.9(1978): 760-768.
Morgan, J. (2018). “조합 테스트: 배열을 포함하는 시스템 및 소프트웨어 테스트에 대한 접근 방식.” 시스템 및 소프트웨어 테스트의 분석 방법 , 131-158.
NIST 보고서. "소프트웨어 테스트를 위한 부적절한 인프라의 경제적 영향." 미국 국립표준기술원 계획 보고서 02-3. 2002년 5월.
Orso, A. 및 Rothermel, G. (2014) "소프트웨어 테스트: 연구 여행기(2000–2014)", ACM 소프트웨어 엔지니어링의 미래에 관한 회의록 , 2014년 5월, 117–132쪽
Wong, W. Eric, Vidroha Debroy, and Andrew Restrepo. “최근의 치명적인 사고에서 소프트웨어의 역할.” IEEE 신뢰성 협회 2009 연례 기술 보고서 59.3(2009).
Wong, W. Eric, Xuelin Li, Philip A. Laplante. "적을 더 잘 알고 앞으로 나아갈 길을 닦자: 소프트웨어 오류에서 버그가 하는 역할에 대한 검토." Journal of Systems and Software 133(2017): 68-94.
소프트웨어가 수천 가지의 다양한 기능을 제공한다면, 그 모든 기능이 서로 잘 작동한다는 것을 보장하는 것이 어려워지고, 두 가지 기능이 세 번째 기능과 조화를 이루는 것도 어려워집니다.
이는 Jmp와 JSL의 Tiny Traps 에서 확인할 수 있습니다.
때로는 2~3개의 멋진 기능을 결합하면 예상치 못한 결과가 나오기도 합니다.
이 모든 작은 상호작용을 테스트하기란 어렵습니다. 하지만 사용자의 집단 지능에는 가능성이 있습니다. ; )
사용자 피드백을 정리하고 전달하기 위해 노력해 주신 JMP 지원팀에 진심으로 감사드립니다!
완벽하게 작동하는 소프트웨어를 제공하려는 열의에 찬 개발자들께 감사드립니다!
조합 테스트(아래 게시물 참조)는 상호 작용으로 인한 오류에 초점을 맞춘 테스트 접근 방식입니다. 기본 수학적 객체는 커버링 배열이므로 수천 개의 입력이 있는 경우에도 매우 효율적인 접근 방식입니다! 이는 향후 블로그의 주제가 될 것입니다.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN(2015). "조합 테스트: 이론과 실제." Advances in Computers , 99 , 1-66.
Morgan, J. (2018). “조합 테스트: 배열을 포함하는 시스템 및 소프트웨어 테스트에 대한 접근 방식.” 시스템 및 소프트웨어 테스트의 분석 방법 , 131-158.
훌륭한 블로그 @JosephMorgan , 다음 작품이 기대되네요.
커버링 어레이를 사용하고 수행할 수 있는 테스트 세트 수에 제한이 있는 경우, 첫 번째 테스트의 결과/분석에서 강도 2(강도 3이 일부 포함됨)를 알 수 있으므로 첫 번째에서 일부 요소를 삭제하여 강도 4 이상을 캡처할 수 있는 두 번째 커버링 어레이를 계획할 수 있습니까? 커버링 어레이로 분석 및 순차적 테스트 워크플로를 허용하는 개발 중인 방법이 있습니까?
감사해요!
@Vins , 이를 위한 방법이 개발 중입니다. 따라서 답은 "예, 예"입니다. 불과 몇 주 전 MEMOCODE-2024( https://memocode2024.github.io/program.html )에서 저희 동료가 이에 대한 발표를 했습니다. 아이디어는 베이지안 분석을 사용하여 후속 테스트 케이스(즉, 순차적 테스트 케이스 설계 방법)를 선택하는 것입니다. 논문 제목은 다음과 같습니다.
"MaLT: 복잡한 소프트웨어 시스템의 기계 학습 기반 테스트 사례 설계 및 오류 현지화"
MEMOCODE-2024 컨퍼런스의 회의록은 곧 나올 예정이지만 제목에 대한 Google Scholar 검색을 하면 논문을 찾을 수 있을 것입니다. 저는 아마도 조합 테스트 블로그에서 이에 대해 조금 언급할 것입니다.
저는 @JosephMorgan 과 @hogi가 말한 소프트웨어 테스팅의 중요성에 동의합니다. 테스팅을 할 수 있는 엄청난 가능성이 있거든요.
실제로 각 조직이나 사용자는 소프트웨어를 테스트하기 위한 고유한 운영 구조를 갖고 있을 수 있습니다.
따라서 새로운 JMP 버전에서 새로운 기술적 문제가 발견되면 기존 소프트웨어 버전(사용자가 이미 사용하고 있는 버전)을 재사용할 수 있는 대안이 허용되어야 한다고 생각합니다. 이러한 문제는 하룻밤 사이에 해결할 수 없기 때문입니다.
