'좋은' 테스트 계획의 중요성

REVIEW

 

소프트웨어 테스팅 과정 단계

유닛테스팅: 개발자가 주로 오류발생이 쉬운 구조와 하위수준 기능성 보증을 위해 본인이 작성한 코드를 테스트하는 것

디자인 검증(verification) 테스팅: 개발자에 의해 실행되는 통합 테스팅을 통해 모듈의 통합을 테스트하고, 테스팅팀 또는 개발자에 의해 완성되는 기능성 테스팅을 포함

시스템 검증(validation) 테스팅: 테스트 팀에 의해 행해지며, 시스템이 완성되거나 개발이 거의 끝나갈 때, 시스템의 상위수준의 행동과 비기능적 퍼포먼스를 테스트하는 것

고객 인수 테스팅: 최종 제품을 고객에게 인수 가능(acceptable)한지 고객과 테스팅 팀이 함께 수행하는 테스팅.

 

---

디자인 검증(verification)과 시스템 검증(validation)

→ 테스트 문서화(documentation) 가장 유용하게 쓰임

 

https://www.testnbug.com/wp-content/uploads/2015/04/TestPlan.png

 

왜 좋은 테스트 계획이 필요한가? - 테스팅이라는 노력(effort)을 체계화하고, 스케쥴 계획하며, 관리하기 위해 - 테스트 케이스 작성에 있어서 도움이 되기에 - 개발자들과 관리진 사이의 커뮤니케이션 향상을 위해 - 소프트웨어 품질 측정은 목적으로서, 계획 되어야하기에  - 좋은 테스트 셋을 개발하기 위해서는 계획이 중요하기에 - 언제 그만할지 알기 위해 - 팩트가 있을 때 더 효과적인 주장을 할 수 있으므로

 

테스트 계획을 도구로 사용할 때,

나와 팀, 그리고 프로젝트를 위해 할 수 있는 것들로서

누가 무엇을 언제 해야하는지에 대해서 구체적으로 할 것

 

 

생각할 수 있는 가능한 모든 테스트들을 리스트하기

왜 그 작업이 행해져야하는지에 대해서는 포함하지 않아도 됨

→ 정당화는 미팅 중에 해도 상관 없음

 

 

테스트 해야할 요구사항들을 리스트하기

→ 요구사항 메트릭을 사용하자

프로젝트가 커질수록, 테스트 작성시 요구사항들을 부주의하게 놓칠 수 있다

요구사항 메트릭 또는 추적성 메트릭(TM)을 사용함으로서,

테스트가 안 된 필수요건들을 찾아낼 수 있으며

요구사항과 관련되지 않은 테스트 케이스들을 알아낼 수 있다

 

 

요구사항에 속하지 않는 테스트가 행해져야할 부분을 알아낼 수 있다

→ 프로젝트의 잠재적인 문제점을 발견할 수 있는 기회

관리(management)는 리스크를 관찰하는 연습

모르는 것을 적절하게 관리할 수 없음 → 비교할 기준점(benchmark)이 있어야함

비교할 기준점 = 테스트 계획

 

---

 

테스트 계획에 있어 염려해야할 점 - 충분치 않은 시간 - 빠른 변화 - 테스트 도구들의 부족 - 관리 서포트의 부족 - 충분하지 않은 트레이닝 - 고객/유저 관여의 부족

 

염려해야할 부분들을 살펴보면,

예방할 수 있는 것들도 있고

어떻게 반응해야할지 준비해야할 수 있는 것들도 있다

 

 

빠른 변화 = 너무 많은 빌드 또는 너무 많은 요구사항의 변화

미완성된 요구사항들이 너무 자주 리뷰되면,

변화들이 생길 것을 알면서도 마일스톤들이 그저 체크됨

추후 결정될(TBD) 요구사항을 절대 허용하지 않기 → 모두에게 손해

 

 

테스팅이 계속 문제점을 찾아내면,

테스트 또는 QA에게 릴리즈를 지체시키는 탓을 돌린다

그러나, 테스팅이 너무 빨리 끝나고 문제점들이 더 나오게 되더라도 QA 탓이다

→ 문제는 항상 나올 수 있음!

 

 

테스팅 결과는 버그의 부재를 증명할 수 없다!

테스팅은 버그를 발견할 수'만' 있다

 

 

제품이 릴리즈 준비가 안 되었다고 결정하기에는 어려움이 있다

폭포수(waterfall) 모델 타입 테스팅에 있어 불리한 점들 중 하나로 볼 수 있음

테스터들이 릴리즈 준비가 안 되었다는 것을 증명하기에는 극대한 부담을 느낀다

그러므로, 테스트 매니저들이 필요하다

 

 

모든 소프트웨어 엔지니어링 = 품질을 보증하기 위해 정밀/엄격함(rigor)을 적용

적절한 테스팅 절차가 따라오는지에 대해 확인함으로서, 품질 향상을 하기 위한 과정이다

 

---

플랜을 짜고 따른다고해서 좋은 제품일까?

 

NO!

하지만, 플랜과 함께 실행하는 것은 다른 대체안들보다는 낫다