Test 되지 않은 것은 분명히 문제가 있다.

지난 주까지 개발자들이 BT를 마치고 부서내 검증팀에 패키지가 넘어갔다.
조마조마 했는데 본격적인(?) 시험 첫날 점수가 38점. 달랑 13가지 시험했는데 그 중에 8개가 NOK 판정을 받았다.

문제점 나온 걸 보니 참 답답하다.
다행히(?) 많은 문제들이 H/W 케이블 이슈로 보이고, 아직 정리되지 못한 DB data 초기값 오류로 보인다. 후자의 경우에도 참 할 말은 많지만 일단 접고.
그 외에 눈에 띄는 문제는 역시나 제대로 시험하지 않은 경우에 발생한 문제다.

부서내 검증랩이 생긴 지 근 1년이 되었다. 그들도 이제 몇 차례(10번은 넘은 듯) 시험을 하면서 나름대로의 노하우가 생겨서 흔히 개발자들이 간과하기 쉬운 경우도 꼭 시험할 것이다. 이번에도 개발자들이 제대로 확인하지 않은 내용들이 우수수 걸리고 있다.

이번에도 어리숙한 친구들이 딱 걸렸다. 당최 이해가 안되는 것은 늘 하는 가장 기본적인 설정에서 동작하는 것을 확인했다고 테스트 다했다고 하는 마음이다.

사실 늘 하던 경우를 위해 코드를 수정해 가면 이 과제를 할 이유는 없다. 이 과제에서 바뀐 내용이 무엇이고, 그 변경된 내용을 확인하려면 어떤 경우를 테스트해야 하는 지를 고민했어야 한다. 구체적으로 못 챙긴 내 잘못도 크지만 실은 각 파트별 PA에게 몇 번을 반복해서 했던 말이다.

> 변경사항에 대해 확인하고, 그 내용이 구현되었는 지, Test case에 추가되었는 지 확인해라

사람들은 말한다. PA 한 번 쯤은 해 봐야 한다고. 나도 평생 개발자로 남고 싶은 심정이지만 그래도 딱 1번 쯤은 해 볼 필요가 있다고 생각한다. 그래야 남의 입장이 되어 보고, 개발자들을 이끌고 과제를 진행하는 역할도 해봐야 얼마나 담당자들이 허술하게 생각하는지를 알 수 있다.
이런 경험을 한번 해 봐야 내 담당 블럭을 책임 질 때도 좀 더 신경쓰게 될 것이다.
그리고 얼마나 사람들에게 일을 하게 만드는 것이 어려운 지.
얼마나 사람들이 Block Test(Unit Test)을 허술하게 하는 지,
얼마나 사람들이 남에 대해서 배려하지 않는 지, 이런 점을 보완하기 위해 “뭔가”가 필요하다는 것을 알게 된다. 아니 알게 되었다.

자 그럼 이제 어떻게 해야 할까?

사실 이런 점을 개선하기에 하나의 과제만을 담당하는 PA(Project Assistant?)는 적당한 배역이 아니다. 개발자를 챙기는 매니저들이 신경을 써 줘야 하는데 매니저들 대부분이 PA를 겸직하고 있어 그 들 역시 신경을 쓸 겨를이 없다. 하지만 개발자들에게 있어 PA는 그저 시어머니 같은 역할 일 뿐이다. 일정을 재촉하고, 문제점 해결을 종용하는 역할만을 하니. 사실 담당자들에게 있어 어떤 과제를 (더) 한다는 것은 큰 의미가 없다. 그거 귀찮은 일 하나가 늘었다는 것 외에 어떤 의미가 있겠는 가.

그래서 결국 개발자들의 자질을 높이고, 개발자가 만들어내는 코드의 품질을 높이기 위해서는 매니저나 선배들이 관심을 가지고 좋은 습관을 들이도록 잔소리도 하고, 좋은 본보기를 보여줘야 한다.

써 놓고 보니 내 주변의 현실의 정확히 정 반대의 이야기를 쓰고 있다.

그나저나 오늘 받은 숙제를 내일 아침 가자 마자 확인하려고 할 텐데

> 점수가 너무 낮다. 근본 문제가 뭐고, 해결 책이 뭐냐?

Leave a Reply

Your email address will not be published. Required fields are marked *