(기고) 다시쓰기 - "검증 일정(주기)을 줄이는 방법"

다시 쓰기 - "검증 일정(주기)을 줄이는 방법"

​

어제 썼던 글에 대해 오늘 다른 글을 읽다가 생각나는 내용이 있어 보완하는 글을 써야겠다는 생각이 들었다.

​

또 한편으로는 최근에 "테스트를 개선해서(프로세스나 자동화 등) 테스트 일정을 줄일 수 있나요?"라는 질문을 여러 차례 받기도 했는데 이 부분도 설명을 더 할 필요가 있을 것 같다.

​

결론부터 말하면

[1] '테스트 일정을 줄이는 방법'은 "개발을 잘하면 된다."

[2] '테스트를 개선'하면 "좋은 품질의 제품"이 딜리버리된다.

​

설명하면,

[1] '테스트 일정을 줄이는 방법'은 "개발을 잘하면 된다."

실제 저 질문을 하신 분중에 한분이 나에게 한 질문 중 하나는,

​

"개발이 2개월이라면 일반론으로 얘기했을 때 검증은 얼마나 걸리나요?"

​

"테스트는 4주요."

​

"네?? 개발이 두달인데 테스트를 한달을 한다고요????!!!"

​

"네. 일반화해서 얘기한다면 최초 테스트에 1주, 결함을 조치하고 확인하는데 1주, 전체 재테스트를 하는데 다시 1주(이때 추가 결함을 다시 조치하고 확인), 그리고 성능 테스트 같은 비기능 테스트를 1주 한다고 볼 수 있습니다."

이 얘기는 앞,뒤 더 많은 얘기를 갖고 있기는 하지만 원래 얘기하고자 하는 바로 보면,

​

개발을 잘 해서 결함이 거의 없으면,

처음 1주-테스트 수행 시간이 크게 줄어든다.

다음 1주-결함 조치하고 확인 테스트하는 시간도 크게 줄어든다. 결함이 아예 없으면 이 1주를 없앨 수 있다.

다음 1주-코드 수정으로 인한 영향 확인을 위해 회귀 테스트 관점으로 수행하려는 재테스트 자체도 필요없다.

마지막 1주 - 비기능 테스트도 모든 코드 수정이 완료된 다음에 수행하려던 계획을 바꿔 아예 처음 1주차에 병행으로 시작을 할 수도 있다.

​

(반대 사례로는 개발을 너무 못해서,

테스트 기간 1주일을 꽉 채워서 수백개의 결함이 리포팅됐다.

걔 중 중요한 것만 먼저 조치하자고 했는데도 조치하고 확인하는데 3주가 걸렸다.

재테스트를 1회 했음에도 여전히 Side-Effect 등으로 또다시 백 수십개의 결함이 리포팅됐다. 그 뿐 아니라, 아예 구조적인 문제들, 기획을 새로 정의해야 하는 이슈들도 있어서 오픈 자체를 2개월 정도 미뤘던 경험이 있다.)

​

이전에 금융권 차세대 시스템 구축 프로젝트에서 전체 개발 및 테스트 일정을 수립한 적이 있다.

고객사 상무님, 총괄 PM과 얘기하면서 개발기간 6개월, 통합 테스트 기간 8개월 일정(통합 테스트 1차부터 4차까지)에 대해 논의를 했었다.

두 분 다 개발이 6개월인데, 어떻게 테스트가 8개월이냐고 황당해 하셨다.

-이 일정을 내가 세운 건 아니었다. 개발 팀이 세운 계획 일정이다-

​

이 8개월간의 테스트 기간은 순수 테스트 일정이 아니다. 1~4차까지 다양한 관점에서 개발 완성물을 확인하고 다시 개발하는 일정이다.

​

살짝 옆길로 새서 이런 글도 있다.

"테스트를 안 하면 모두가 행복하다? - Poor testing의 결과"

https://blog.naver.com/genycho/220257357201

[2] '테스트를 개선'하면 "좋은 품질의 제품"이 딜리버리된다.

처음 질문을 하신 분들의 공통된 포인트는 이거였다.

(a) 테스트 프로세스를 잘 잡아서 테스트 일정을 줄여주세요

(b) 테스트 자동화를 통해서 테스트 일정을 줄여주세요

(c) 조기 테스트, Early Testing을 통해서 일정을 줄여주세요

​

기존에 링크드인에 올리기도 했던 개인적인 사례를 통해 생각해 보자.

(a-1) 테스트 프로세스상 제품과 고객에 맞는 테스트 계획을 세웠다. 이에 따라 기능 테스트 외에도 성능 테스트, 호환성 테스트를 수행하기로 했다. 또한 내부 아키텍처에 따라 제품 내부에 이질적인 인터페이스 영역에 API 테스트를 추가로 수행했다. 이로 인해 테스트 수행 기간이 더 늘어났고, 많은 이슈들이 리포팅되었고, 각 이슈들을 수정하는 데에도 시간이 더 걸렸다.

=> 테스트 공수, 일정은 더 늘어났고, 더 좋은 제품을 만들 수 있었다

​

(a-2) 테스트 프로세스상 요구사항, 기획서를 리뷰하는 절차를 추가했다. QA는 QA뿐만 아니라 리뷰 내용과 절차를 모든 이해관계자와 같이 수행했다. 이에 따라 명확하지 않거나 구체적이지 않은 요구사항, 기획 요건들이 파악되었고 수정되었다. 또 부수적으로 이 과정에서 새로운 인싸이트가 떠올라 추가적인 기능들이 정의되었다.

=> 전체개발 일정은 더 늘어났고, 테스트 케이스들은 더 풍부해졌고 테스트 수행 공수는 더 늘어났다. 하지만 더 좋은 제품을 딜리버리 할 수 있었다

​

(b-1) API 테스트 자동화와 GUI 테스트 자동화를 도입하였다. Early Testing의 관점에서 백엔드 개발이 완료된 시점, 전체 개발이 완료된 직후부터 자동화를 구축하고 운용하였다. 여러 개발 요소들은 끊임없이 변경됐고, 실제 정상 동작하던 기능들이 코드 수정으로 인해 결함이 발생하기도 했다.

=> 자동화 구축을 위한 테스트 인력의 작성/모니터링 공수는 상당했다. 개발 일정을 줄여주는데는 도움이 되기는 했다.

​

(b-2) 반복되는 테스트 작업들을 자동화하였다. 이런 경우 테스트 인력은 테스트를 안 하는게 아니라, 더 리스크가 높고 복잡한 영역으로 테스트 커버리지를 확장한다.

​

(c-1) Early Testing 자체는 테스트 일정을 줄이기 위한 접근법이 아니다. 결함을 조기에 발견하면 결함을 수정하는 비용이 급격하게 줄어든다라는 개념을 기본으로 하고 있다. 결함을 일찍 찾기 위해서는 오히려 테스트 공수가 더 들어간다.

​

그렇다고 해서 이 테스트 활동들이 전체 테스트 일정, 공수가 아예 무관한 것은 아니다. 이 테스트 활동들은 개발을 잘하게 만든다. 그리고 앞서 얘기한 것처럼 개발을 잘 하면 테스트 일정은 줄어들 수 있다. 선순환이다.

​

이게 맞는 접근이고, 논리적인 순서라고 생각한다.

그리고 이걸 극대화한 것이 애자일의 한팀(Whole Team) 접근법이라고 생각한다.