소프트웨어 테스팅의 목적은 장애를 통해 결함을 도출하고 결함을 해결함으로써 소프트웨어의 품질 향상에 기여하는 것이라고 할 수 있습니다.
하지만 실제 개발 환경에서 결함은 그다지 환영받지 못하는 것이 현실입니다.
결함이 증가할수록 해당 결함을 해결하고 테스트하는데 들어가는 시간과 비용 그리고 노력은 어마어마하게 증가합니다.
특히 테스트 활동이 개발 후반에 집중될 수록 이런 현상은 더 심해지는 경향을 보입니다. 그래서 가장 좋은 해결책은 개발 수명주기 전체에 걸쳐 테스트 활동이 병행되는것이지만 현실은 그렇게 녹록하지 않습니다.
때문에 많은 개발 조직들은 결함을 은닉하거나 수정하지 아니하고 그것은 원래 기획의도라면서 두리뭉실 넘어가기 일쑤입니다.
이것은 결국 부메랑처럼 회사와 조직 그리고 고객에게 엄청난 피해를 일으킬 수도 있습니다.
결함은 분명 환영해야할 일이지만 마냥 환영할 수만은 없는 닭갈비 같은 존재입니다.
우리가 결함에 대한 해결을 미루는 이유는 여러가지가 있지만 제 경험상 가장 주요한 이유 중 하나는 바로 테스터에게 있습니다.
테스터들이 보고하는 결함 보고서를 리뷰해보면 결함보다는 장애 그 자체를 보고하는 경우가 꽤 많습니다.
장애로부터 결함을 격리하는 활동 없이 보고되는 장애는 개발 조직에게 장애의 원인을 규명하는데 꽤 많은 자원을 소모하게 만듭니다.
이러한 장애가 한두건이라면 어떻게든 해보겠지만 이러한 장애가 수백건이 된다면 얘기가 달라집니다.
말 그대로 테스터가 해야할 일을 개발자가 해야하니 개발자에게는 이중고가 되고 그러하니 결함이 수정되지 못하는 악순환이 반복되게 됩니다.
테스터들이 장애로부터 결함을 격리하는 활동을 하지 못하는 것은 시간이나 인력이 부족해서일수도 있고 아니면 몰라서 못하는 것일수도 있습니다.
때문에 결함을 격리하고 결함 수정율을 올리기 위한 6가지 고려사항을 적어볼까 합니다.
첫번째는 장애가 발견되었을 때 이것이 실제로 장애인가? 결함인가?에 대하여 물어볼 필요가 있습니다.
우리가 결함이라고 생각하는 것이 실제로는 장애인 경우가 많습니다. 장애가 발생하는 근본원인을 찾아볼 필요가 있습니다. 테스터는 장애의 핵심원인에 대한 근거를 명확하게 제시할 수 있어야 합니다. 이것이 가장 중요한 활동이고 가장 시간과 노력이 많이 들어가는 활동입니다. 이러한 활동에 들어가는 노력을 줄이기 위해서는 모델을 잘 구축할 수 있어야 하고 테스트 설계에 대한 성숙도가 높아질 필요가 있습니다.
두번째는 발견된 결함에 대한 해결책의 방향에 대한 총의를 확보해야 합니다.
세번째는 해결책이 정말 결함을 해결할 수 있고, 어떤 의미가 있는지 물어봅니다. 해결책이 결함을 해결하여 좋은 결과를 달성할 것이라는데 대한 총의를 확보합니다. 결함을 해결하는데 들어가는 비용과 노력보다 더 많은 것을 얻을 수 있는지에 대한 근거가 제시되어야 합니다. 이러한 근거는 결함의 해결이 제품과 사용자에게 미치는 영향을 예측하여 추정할 수 있습니다. 그리고 이러한 근거는 결함 수정의 우선순위와 리그레션 테스트의 강도에 영향을 미칩니다.
네번째는 해결책으로 잘못될 일은 없는지, 어떤 부작용은 없는지 물어봅니다. 일반적으로 이러한 부작용을 파악하기 위해 모델과 함께 영향도 분석을 합니다. 저는 의존도 분석을 선호하는 편입니다.
다섯번째는 해결책을 어떻게 실현할 수 있을지 물어봅니다. 구현을 방해하는 모든 장애물들이 파악하고 그 대책을 마련할 필요가 있습니다. 이러한 장애물들은 프로젝트 리스크로 지속적인 관리를 해야합니다.
여섯번째는 과연 우리들이 결함을 해결해 낼 수 있을지를 물어봅니다. 결함의 성공적인 해결을 위해 모든 리더쉽이 발휘될 것이라는 경영층의 확고한 의지를 확인할 필요가 있습니다.
그리고 이러한 여섯가지 활동을 수행할 조직이 필요합니다.
단순히 시간에 쫓겨 발견되는 장애가 리뷰도 없이 개발 조직에 전달되고 정확하지 않은 데이터를 기반으로 한 의사결정과 결함 수정은 시간과 비용, 노력을 낭비하게 하고 더 나은 제품을 제공하지 못합니다.
시간이 없다고 하더라도 하나 하나의 장애에 대하여 정확한 분석과 해결 전략을 도출할 필요가 있습니다.
더 좋은 것은 그러한 장애에 대한 원인이 되는 결함이 발생하지 않도록 조직 전체가 테스트에 대한 책임을 가지고 테스트를 실행할 필요가 있습니다.
만약 여러분의 조직이 발견되는 결함이 제대로 수정되지 못하고 미궁에 빠져 있으시다면 위의 6가지 고려사항 중 얼마나 많은 것들을 고려하고 실행하고 계신지 확인해보시기 바랍니다.
하지만 실제 개발 환경에서 결함은 그다지 환영받지 못하는 것이 현실입니다.
결함이 증가할수록 해당 결함을 해결하고 테스트하는데 들어가는 시간과 비용 그리고 노력은 어마어마하게 증가합니다.
특히 테스트 활동이 개발 후반에 집중될 수록 이런 현상은 더 심해지는 경향을 보입니다. 그래서 가장 좋은 해결책은 개발 수명주기 전체에 걸쳐 테스트 활동이 병행되는것이지만 현실은 그렇게 녹록하지 않습니다.
때문에 많은 개발 조직들은 결함을 은닉하거나 수정하지 아니하고 그것은 원래 기획의도라면서 두리뭉실 넘어가기 일쑤입니다.
이것은 결국 부메랑처럼 회사와 조직 그리고 고객에게 엄청난 피해를 일으킬 수도 있습니다.
결함은 분명 환영해야할 일이지만 마냥 환영할 수만은 없는 닭갈비 같은 존재입니다.
우리가 결함에 대한 해결을 미루는 이유는 여러가지가 있지만 제 경험상 가장 주요한 이유 중 하나는 바로 테스터에게 있습니다.
테스터들이 보고하는 결함 보고서를 리뷰해보면 결함보다는 장애 그 자체를 보고하는 경우가 꽤 많습니다.
장애로부터 결함을 격리하는 활동 없이 보고되는 장애는 개발 조직에게 장애의 원인을 규명하는데 꽤 많은 자원을 소모하게 만듭니다.
이러한 장애가 한두건이라면 어떻게든 해보겠지만 이러한 장애가 수백건이 된다면 얘기가 달라집니다.
말 그대로 테스터가 해야할 일을 개발자가 해야하니 개발자에게는 이중고가 되고 그러하니 결함이 수정되지 못하는 악순환이 반복되게 됩니다.
테스터들이 장애로부터 결함을 격리하는 활동을 하지 못하는 것은 시간이나 인력이 부족해서일수도 있고 아니면 몰라서 못하는 것일수도 있습니다.
때문에 결함을 격리하고 결함 수정율을 올리기 위한 6가지 고려사항을 적어볼까 합니다.
첫번째는 장애가 발견되었을 때 이것이 실제로 장애인가? 결함인가?에 대하여 물어볼 필요가 있습니다.
우리가 결함이라고 생각하는 것이 실제로는 장애인 경우가 많습니다. 장애가 발생하는 근본원인을 찾아볼 필요가 있습니다. 테스터는 장애의 핵심원인에 대한 근거를 명확하게 제시할 수 있어야 합니다. 이것이 가장 중요한 활동이고 가장 시간과 노력이 많이 들어가는 활동입니다. 이러한 활동에 들어가는 노력을 줄이기 위해서는 모델을 잘 구축할 수 있어야 하고 테스트 설계에 대한 성숙도가 높아질 필요가 있습니다.
두번째는 발견된 결함에 대한 해결책의 방향에 대한 총의를 확보해야 합니다.
세번째는 해결책이 정말 결함을 해결할 수 있고, 어떤 의미가 있는지 물어봅니다. 해결책이 결함을 해결하여 좋은 결과를 달성할 것이라는데 대한 총의를 확보합니다. 결함을 해결하는데 들어가는 비용과 노력보다 더 많은 것을 얻을 수 있는지에 대한 근거가 제시되어야 합니다. 이러한 근거는 결함의 해결이 제품과 사용자에게 미치는 영향을 예측하여 추정할 수 있습니다. 그리고 이러한 근거는 결함 수정의 우선순위와 리그레션 테스트의 강도에 영향을 미칩니다.
네번째는 해결책으로 잘못될 일은 없는지, 어떤 부작용은 없는지 물어봅니다. 일반적으로 이러한 부작용을 파악하기 위해 모델과 함께 영향도 분석을 합니다. 저는 의존도 분석을 선호하는 편입니다.
다섯번째는 해결책을 어떻게 실현할 수 있을지 물어봅니다. 구현을 방해하는 모든 장애물들이 파악하고 그 대책을 마련할 필요가 있습니다. 이러한 장애물들은 프로젝트 리스크로 지속적인 관리를 해야합니다.
여섯번째는 과연 우리들이 결함을 해결해 낼 수 있을지를 물어봅니다. 결함의 성공적인 해결을 위해 모든 리더쉽이 발휘될 것이라는 경영층의 확고한 의지를 확인할 필요가 있습니다.
그리고 이러한 여섯가지 활동을 수행할 조직이 필요합니다.
단순히 시간에 쫓겨 발견되는 장애가 리뷰도 없이 개발 조직에 전달되고 정확하지 않은 데이터를 기반으로 한 의사결정과 결함 수정은 시간과 비용, 노력을 낭비하게 하고 더 나은 제품을 제공하지 못합니다.
시간이 없다고 하더라도 하나 하나의 장애에 대하여 정확한 분석과 해결 전략을 도출할 필요가 있습니다.
더 좋은 것은 그러한 장애에 대한 원인이 되는 결함이 발생하지 않도록 조직 전체가 테스트에 대한 책임을 가지고 테스트를 실행할 필요가 있습니다.
만약 여러분의 조직이 발견되는 결함이 제대로 수정되지 못하고 미궁에 빠져 있으시다면 위의 6가지 고려사항 중 얼마나 많은 것들을 고려하고 실행하고 계신지 확인해보시기 바랍니다.
장애와 결함의 차이가 무엇인가요?
답글삭제결함은 명세, 모델 ,코드가 잘못 구현된 것으로 정적 테스팅을 통해 식별하고 장애는 제품의 실행 결과가 의도와 다른 것으로 동적 테스팅으로 식별하고 그 원인은 크게 결람에 의한 장애와 환경 특성 장애로 구분합니다.
삭제