도미닉 마에스 (Dominiq Maes) / 선임 테스트 컨설턴트 스티븐 메르텐스 (Steven Mertens) / 테스팅 매니저 1. 빨리 시작하고 준비하라 성공적인 소프트웨어 개발 프로젝트의 핵심은 만반의 준비다. 프로젝트는 종종 깊이 있는 사전조사 이전에 열정적인 개발자가 잠시 동안 노력을 기울여 만들어내는 간단한 아이디어로부터 시작되곤 하는데, 이는 결과적으로 프로젝트를 지연시키고 시간이 나 비용 초과를 초래하는 예측하지 못한 문제들을 야기하곤 한다. 테스팅은 초기 단계부터 도입되어야 하며, 이러한 방법으로 당신은 프로젝트에 귀중한 노력을 쏟아 붓기 전에 프로젝트의 성공 가능성과 그에 따른 리스크에 대해 긍정적인 시각을 가지게 될 것이다. 여기에 더해, 테스트 혹은 품질 관련 부서는 요구사항과 디자인 문서들을 리뷰하기 위해 초기 단계부터 반드시 포함되어야만 한다. 리뷰는 결함을 발견하기 쉽게 해주므로 만약 프로세스 초기부터 리뷰가 수행된다면 프로젝트 후반부의 값비싼 수리나 수정 비용을 절감하여 전체 비용을 절약할 수 있다. 요구사항 단계에서 발견된 결함을 수정하는 비용은, 최종 생산된 제품에서 발견된 동일한 결함을 수정하는 비용보다 평균 100배 정도나 저렴하다. 테스트 수행을 준비하는 것아말로 당신의 프로젝트를 가능한 가장 짧은 시간 내에 완수하도록 만드는 현실 수단이다. 테스트될 애플리케이션이 전혀 준비되기 전에 테스트 스크립트를 구체적으로 명확하고 테스트 시나리오를 미리 작성함으로써 테스트 수행과 동시에 활용 가능한 시간을 절약할 수 있다.2. 당신의 니즈에 알맞은 테스팅 방법을 선택하라반복적인 개발 모델, 즉 V모델(V-Model), 애자일(Agile), 익스트림 개발(Extreme Development) 등의 소프트웨어 개발 프로세스는 이에 알맞은 테스트 프로세스가 필요하다; 당신의 애플리케이션에 적합한 테스팅 방법을 선택하라. 이러한 프로세스는 당신의 관리부서에게 사업적/프로젝트의 위험을 인지시키는 장점을 제공할 뿐만 아니라, 테스팅 팀이 그러한 위험들을 완화해왔다는 것을 (다른 부서 사람들에게) 인지시켜줄 것이라는 위안도 제공할 것이다. 오직 당신의 프로젝트만이 가지고 있는 독특한 특성에 집중하라. 모든 것에 적용되는 테스트 방법이라는 것은 세상에 존재하지 않는다. 하나의 회사 혹은 하나의 프로젝트를 위해 만들어진 프로세스는 아마도 다른 회사나 프로젝트에는 거의 적합하지 않을 것이다. 당신은 신속한 대응과 다양한 변화가 필요한가? 프로젝트의 목표가 현존하는 애플리케이션에 기능을 추가하는 것인가? 당신의 개발 프로세스상에서 존재하는 많은 다양한 시각들이, 적합한 테스팅 접근법을 선택하는데 영향을 끼칠 수 있다. 당신이 어떤 것을 선택하더라도 당신의 테스트 프로세스가 체계적으로 구조화되어야하며, 개발 프로세스의 초기 단계부터 시작되어야 함을 잊어서는 안 된다. 3. 테스트를 주도하라테스트 팀은 종종 프로젝트 안에서 혼자서는 업무를 진행하기가 어려우므로, 조직 내에서 자발적으로 역할을 수행해야 한다. 일부 프로젝트 매니저들은 프로젝트의 데드라인이 지켜지지 못하는 위험에 처했을 때, 더 이상 품질이 중요한 요소라고 생각하기 힘든 상황이라며 테스트 팀의 충고를 가볍게 넘겨버리려는 경향이 있다. 이와 함께 개발이 지연될 때 많은 프로젝트 리더들이 테스트 실행에 할당된 시간을 오히려 좀 더 많은 개발 업무를 수행하는 데 할애하려고 한다. 따라서 테스팅은 일반적으로 건너뛰어 버리거나 연기되기도 한다. 이는 종종 애플리케이션이 제품화되는 단계에서 재작업을 하도록 만드는 프로젝트의 총체적인 품질 문제라는 심각한 결과를 초래한다. 추가 작업은 결국 전체 프로젝트의 일정 지연과 비용 상승을 초래하게 된다. 만약 당신의 조직이 충분한 규모가 된다면(예를 들어, 1년에 IT 프로젝트를 몇 개 수행할 정도로), 당신은 이미 출시된 애플리케이션과 새로운 프로젝트에 대해 독립적이고 일관된 테스팅을 수행하는 별도 부서, 즉 테스트 팩토리(Test Factory)를 만드는 것도 고려해볼 수 있다. 4. 리뷰, 리뷰, 리뷰, 리뷰...테스팅은 개발 프로세스 초기부터 시작되어야만 한다. 그렇다고 애플리케이션 테스팅을 시작하기 위해 코드를 기다리는 늦장함을 가져서는 안 된다. 가장 초기부터 문서 리뷰를 시작해야 함을 다시 한 번 상기하라; 충분히 리뷰가 수행된 문서들은 개발 사이클후반부에 발견되는 결함의 65% 가량을 절감할 수 있는 효과를 낸다. 이는 결국 시간과 비용에 있어 큰 절감 효과를 가져온다.리뷰 대상에 대한 설명이나 준비 없이 당신의 문서를 동료들에게 리뷰해달라고 '그냥 보내지 마라'. 대신 그들이 그 문서에 대해 리뷰해주기를 원하는 특정 부분을 할당해주라. 일부 사람들에게는 기술적인 측면을 확인토록 하고, 다른 사람들은 한층 더 높은 수준에서 문서를 검토하게 하며, 또 다른 사람들은 문서가 회사 내부에서 사용하는 레이아웃 표준을 사용했는지 검토하게 하라. 이러한 방법을 통해 단지 문법적인 오류가 발견되어 리뷰 회의를 개최해야 하는 불필요함을 미연에 방지할 수 있다. 리뷰는 또한 매우 소모적인 일이기 때문에, 단기간에 수행되어야 하며 최대한 한 시간을 넘지 않는 한도 내, 약물 집중력을 방해 않도록 한 회의에 10페이지 정도의 리뷰만 수행하는 것이 좋다. 번잡하고 지저분한 사무실 환경에서 리뷰하는 것은 될 수 있으면 피하라. 아울러 리뷰를 진행하는 동안은 이메일을 확인하지 마라. 당신이 리뷰를 진행하는 방법에서 전문가가 되도록 하라. 전문적이고 조직적으로 어떻게 리뷰를 진행할지, 코드를 작성하기 배우는 데 시간 걸리기 마련이다. 5. 우선순위를 정하라모든 것을 테스트하는 것이 불가능함은 일반적으로 널리 통용되는 명제다. 평범한 애플리케이션이나 혹은 시스템이라고 할지라도, 하나하나 테스트하기에는 너무 많은 기능과 가능성이 존재한다. 애플리케이션을 테스트하는 데 수년의 시간이 걸릴 수도 있기 때문에, 애플리케이션 중에서 위험 수준이 가장 높거나 가장 많이 사용되리라 예상되는 부분을 테스트하는 것이 무척 중요하다. 테스트 전략을 수립하기에 앞서 우선 완벽한 위험 평가(Risk Assessment)가 수행되어야만 한다. 어떤 분야의 위험을 감소시킬 것이냐에 따라 테스트 기법을 선택해야 한다. 프로젝트가 수반하고 있는 위험에 기반해 전략을 수립하라. 기억하라: 위험이 없다면, 테스트를 할 필요도 없다. 6. 측정하라다음과 같은 중요한 두 가지 질문이 제기될 수 있다. 당신은 테스트 프로세스에 대해서 무엇을 알고 있는가? 당신은 테스트 프로세스에 대해서 무엇을 알고 싶은가?대부분의 경우, 서로 다른 개발 단계에서 애플리케이션 결함을 수정하는 데 드는 비용을 산정하는 것은 쉽지만, 어떤 것들이 비용에 포함되어야 하며 당신이 얼마나 효율적으로 이러한 결점을 찾아내는지는 어떻게 산정할 것인가? 이러한 질문에 대한 핵심은 측정을 시작하라는 것이다. 당신의 테스트 프로세스와 당신이 속한 테스트 부서의 업무 효율 및 효과를 측정하기 위해 데이터를 수집하라. 당신이 당신의 프로세스에 대해 알아야 할 필요가 있는 정보를 제공하는 메트릭스를 활용하라. 예를 들어 테스트 시나리오, 밀도, 결함 밀도, 제품화 이후 최종 발견된 결함 건수 등을 기준으로 메트릭스를 수립할 수 있다. 언제 측정을 시작하는 것이 가장 좋은가 라는 질문이 자주 제기된다. 우리의 경험에 따르면 그 정답은 바로 지금이다. 지금이 메트릭스를 만들기에 가장 적합한 시간이며, 더 신속하게 데이터를 수집할수록 품질 개선을 시작할 수 있다. 7. 언제 테스트를 그만둘지 결정하라언제 당신은 테스트 수행을 그만둘 것인가? 규칙적으로라면, 추가 버그를 찾아내는 비용이 당신이 찾아낸 위험과 더 이상 균형을 이루지 못할 때 버그 헌팅 을 중단해야 한다. 일반적인 환경에서 테스트를 종료하기로 할 때, 다음 단계로 진행해야 하는지 결정하기 위해 종료 기준(exit criteria)을 마련해둘 필요가 있다.예를 들어, 테스트 스크립트 중 90%가 실행되고 해결되지 않은 결함이 5개 이내여야 한다 와 같은 기준을 설정해야 한다. 당신의 프로젝트 기준을 명백하게 수립하도록 하라. 프로젝트가 시작되는 시점에서 당신의 프로젝트 종료 기준에 대해 논의하고 이를 당신의 테스트 계획에 반영하라. 그럼으로써 더 이후에 발생할 수 있는 논쟁에서 자유로워질 수 있다. 만약 종료 기준이 마련되어 있지 않다면, 테스터들은 모든 결함이 발견되거나 해결될 때까지 테스팅을 계속하려고 할 것이다. 8. 보존해두라소프트웨어 테스팅의 장점 중 일부는 테스트웨어(Testware)의 구조적인 보존(Structured Preservation)에 있다. 테스트를 완료하는 단계에서는, 당신의 산출물을 평가하고 또 이를 추후에 재사용하기 위해 보존하는 데 일부 시간을 투자해야 한다. 테스트 케이스는 추후의 다른 프로젝트 혹은 이후에 발생하는 매번 유지보수 단계에서라도 재사용하도록 저장되어야 한다. 당신은 항상 이전의 테스트 케이스를 즉시 재사용 가능한 상태로 보유해야 하며, 이러한 방법으로 당신의 전체 테스트에 드는 노력의 약 30~50% 가량을 절감할 수 있다. 9. 의사 소통하라많은 회사의 구성원들이 이건 내 책임이 아니야 라는 업무 태도를 견지하고 있다. 최종 고객들, 설계자, 개발자, 테스터와 관련 부서간 의사소통이 부족하다. 너무나도 자주, 이런 의사소통의 부재가 요구사항의 잘못된 해석, 원치 않던 기능 추가와 불만족스러운 최종 고객들을 양산해낸다. 의사 소통은 품질 에 있어서 핵심사항이다. 최종 고객의 의견에 늘 귀 기울이고 최고 결과를 얻기 위한 완벽한 팀을 구성하라. 외교적이면서도 건설적인 논의를 하라. 소프트웨어 개발은 끊임없이 예산과 품질, 그리고 어느 부분에 초점을 맞추어야 할지가 서로 균형을 맞추어야 한다. 10. 마지막이지만 중요한 점: 간단명료함을 유지하라종종 회사는 테스팅을 고려하면서 행정적 절차에 빠져드는 경향이 있다. 능률적인 테스트 프로세스는 무엇보다 간단명료함이 뒷받침되어야 하며, 번거로운 행정 절차의 연속이어서는 안 되고, 그렇다고 당신의 품질 팀과 개발자들에게 힘든 시간인 지루한 방식이 되어도 안 된다. 당신의 프로젝트나 회사에 적합하거나 업무, 즉 당신의 애플리케이션의 품질을 보장하는 데 적합한 방식을 선택하라. 행운을 빈다! * 출처 : testers insight for the best software, winter 2008, vol 1
커뮤니티
