소프트웨어 품질
어디서나 자주 들을 수 있는 이야기이지만 소프트웨어는 지금 정말 우리 주변에 사용되지 않는 곳이 없습니다. 예전에 하드웨어로 만들었던 혹은 사람이 담당했던 업무의 상당 부분을 소프트웨어가 자동화된 기술로 처리하고 있습니다. 그렇기 때문에 점차 단순히 기술적인 진보만을 뜻하는 것이 아닙니다. 경제적인 가치를 예전보다 훨씬 더 많은 부분 소프트웨어가 만들어내고 있습니다.
전통적인 시장의 많은 부분을 소프트웨어가 대체하고 있습니다. 소매는 아마존, 그다음에 우리나라에도 있는 많은 온라인 숍들이 예전의 소매 경로를 대체하고 있습니다. 그다음에 동영상 같은 경우도 고전적인 방송사가 아니라 유튜브나 여타 많은 비디오 채널들, 엔터테인먼트의 경우에는 게임 혹은 영화의 배급채널도 요즘에는 전부 다 소프트웨어를 통해서 이루어지고 있습니다.
사진, 마케팅, 광고, 텔레커뮤니케이션, 스카이프나 카카오톡 같은 새로운 채널들이 기존의 서비스를 대체하고 있습니다. 리크루팅, 소셜 네트워크나 링크드인 같은 구인 서비스마저도 온라인에서 많이 이루어지고 있습니다. 따라서 소프트웨어가 기존의 시장을 지배하던 경제적 가치를 많은 부분 대체하고 있기 때문에 그만큼 그 역할과 품질이 중요해집니다.
소프트웨어 품질이 소프트웨어가 널리 사용되는 만큼 실제 세계에 바로 영향을 미칩니다. 따라서 소프트웨어 품질 상의 문제는 실제 세계에서의 문제로 바로 연결이 되는 것입니다. 그렇기 때문에 품질을 최대한 향상시키는 것을 목표로 하는 소프트웨어 테스팅의 중요성이 더욱더 대두됩니다.
미국의 나사에 대응하는 유럽연합 항공우주국에서 만든 Ariane5라는 로켓입니다. 그런데 이 5호가 유명한 이유는 성공했기 때문이 아니고 발사 40초 이후에 폭발했습니다. 그래서 엄청나게 큰 재정적인 손해를 끼쳤을 뿐만 아닙니다. 우주 개발 프로젝트 자체에도 지연을 낳았습니다.
조금 이따가 나중에 다시 보겠지만 소프트웨어를 조금이라도 이해하시는 분들이 알면 굉장히 어처구니없는 초보적인 실수 때문에 어마어마한 돈과 프로젝트가 좌초되는 위기를 겪었습니다.
그다음 예제로 소프트웨어 테스팅을 연구하거나 가르치시는 분들이 흔히 꺼내드는 게 THERAC-25라는 기계입니다. 이거는 의료용 장비입니다. 캐나다에서 개발된 방사능 치료 장비입니다. 항암치료를 하기 위해서 방사능을 환자의 몸에 쏘이는 기계입니다. 이전 버전에서 하드웨어로 구성되어 있던 안전장치를 환자가 치사량의 방사능을 쪼이지 않도록 하는 소프트웨어 로직으로 대체를 했습니다.
그런데 로직에 결함이 있어서 결국에는 몇 명의 환자가 치사량 이상의 방사능을 맞았습니다. 실제로 사망에 이른 케이스가 있습니다. 아직까지 소프트웨어 테스팅 교과서에서 소프트웨어 오류가 인명피해로 바로 직결된 고전적인 예로 거론되는 것이 THERAC-25의 예제입니다.
마지막으로 인명까지 피해가 연결되지 않더라도 재정적인 피해로 바로 직결되는 경우가 있습니다. 이 예는 2012년에 스웨덴 증시에서 사용하는 소프트웨어에 결함이 있었습니다. 실수로 스웨덴 전체 GDP의 131배에 해당하는 주문을 증권시장에 자동으로 소프트웨어가 띄우고, 이게 사람에 의해서 걸러지지 않았던 사고가 있습니다.
물론 거래가 실제로 벌어지지는 않았습니다. 결함에 의해서 그 정도 혼란을 초래할 수 있다는 것도 증명이 됐습니다. 다른 방법도 많이 있지만 오늘 이 강의를 통해서 알아보려고 하는 건 소프트웨어 테스팅 기법입니다. 소프트웨어 테스팅은 넓게 말해서 소프트웨어의 품질에 관여한 사람들에게 최대한 정보를 제공할 수 있도록 수행되는 모든 종류의 조사를 소프트웨어 테스팅이라고 보시면 매우 넓은 의미에서 테스팅의 정의가 되겠습니다.
그게 소프트웨어 제품이건 아니면 사용자들에게 제공하는 서비스건 마찬가지로 관련된 소프트웨어의 품질을 모두 다루는 것이 소프트웨어 테스팅의 목표입니다.
소프트웨어 품질의 다양한 측면
첫째, Dependability, 의존할 수 있어야 된다는 거죠. 소프트웨어가 올바르게 기능하고 그다음에 늘 올바르게 기능하고, 한 번만 올바르면 안 되고 늘 올바르게 기능해야 됩니다. 그다음에 안전해야 하고, 그리고 예상치 못한 입력이 들어오더라도 갑자기 무너지지 않아야 합니다.
그 중에 첫 번째는 작동이 올바라야 한다는 겁니다. Correctness라고 합니다. 잘 정의된 어떤 기준에 맞춰볼 때 소프트웨어가 내놓는 답이 항상 옳아야 한다는 것입니다. 이걸 정말 보장하기 위해서는 옳은 답밖에 내놓을 수 없다는 증명을 필요로 합니다. 실제로 사용하는 시스템에서는 옳다는 것을 증명하기가 상당히 어렵습니다.
이게 왜 테스팅을 저희가 사용하는지에 대한 논의로 나중에 이어질 겁니다. 의존성의 두 번째 꼭지로는 Reliability, 즉 얼마나 믿고 사용할 수 있느냐는 하는 개념이 등장합니다. 소프트웨어가 한 번만 옳아서는 계속해서 안전하게 사용할 수가 없습니다.
내가 언제 사용하더라도 꾸준하게 일관성 있게 맞는 답을 내놓을 수 있는 속성을 Reliability라고 합니다. 사실 완벽하게 보장을 하기가 쉽지 않습니다. 왜냐하면 소프트웨어를 테스팅하는 사람이 무한정 오랜 시간 동안 사용해보고 답을 내릴 수 없기 때문에 대체적으로는 일부 한정된 시간 동안 조사를 하고 그 결과를 바탕으로 통계적인 추론을 하는 것으로 의존성, Reliability에 대한 테스트를 가늠합니다.
그 외에 두 가지가 더 있는데, 하나는 안전성, 그러니까 기능의 옳고 그름이나 모든 면을 종합했을 때 이 소프트웨어의 사용이 사람에게 유해한 결과를 낳을 수 있는지를 따지는 것이 안전성에 대한 속성입니다. 그다음에 Robustness, 강견성이라고 합니다. 의도하지 않은 입력이 들어오더라도 소프트웨어가 갑자기 이상한 행동을 하지 않아야 합니다. 설사 예측하지 못한 입력에 대해서라도 위해한 행동을 할 수 없습니다.
소프트웨어 품질 항목
여기까지가 소프트웨어를 믿고 사용할 수 있는지 의존성에 대한 부분입니다. 그 외에도 다른 품질의 항목이 있습니다. 예를 들어서 성능. 보통 굉장히 넓은 의미로 통틀어서 소프트웨어의 성능이라는 표현을 많이 하는데, 실제로는 기능적으로 옳은지, 소프트웨어의 성능이 좋은지는 약간 다른 의미로 사용합니다.
기능적으로 옳을 뿐만 아니라 소프트웨어는 실행속도가 빨라야 한다든지 네트워크 사용량을 최대한 줄여야 한다든지 메모리를 가능한 적게 사용한다든지 등등의 지표들 또한 성능에 관련된 것으로 간주할 수 있습니다. 그다음에 넓게 봐서는 품질에 포함이 됩니다.
마지막으로 사용성도 마찬가지로 소프트웨어의 품질입니다. 이것은 소프트웨어의 기능이 옳고 그르냐를 떠나서 사용자가 실제로 사용할 때 얼마나 편리한지, 사용자 편의를 고려해서 만들어졌는지 등을 테스트합니다.
'SW > 테스팅' 카테고리의 다른 글
| AI가 자동화된 소프트웨어 테스팅을 혁신하는 방법: 미래의 SQA를 위한 전략적 도구 (0) | 2024.04.16 |
|---|---|
| 생성형 인공지능을 이용한 Shift-Left 테스트 고도화 (0) | 2023.11.14 |
| SW 테스팅 : 완벽한 테스팅은 가능한 것일까? : KMOOC (0) | 2020.10.12 |
| SW 테스팅 : 결함, 에러, 실패 : 개념, 기법, 관계, 사례 : KMOOC (0) | 2020.10.03 |