어제 회사에서 조금 일찍 출발해서 P-CAMP에 참가했다. 기대했던만큼 재미있고 다양한 경험을 할 수 있었다.
“When Process, Project, Product and People Met S/W Testing”라는 주제로 진행된 이번 P-CAMP는 김창준님의 “테스트 주도 개발에 있어서의 단위 테스트의 개체 발생론”이라는 조금은 어려운 발표로 시작됐다. 패턴 언어의 창시자인 크리스토퍼 알렉산더의 “Nature of Order”의 이론과 소프웨어 개발 방법론을 접목시킨 이 발표는 참신하면서도 아직은 이해하기 어려운 부분이 많은 그런 발표였다. Living Structure에 이미 15가지 패턴이 내포되어 있다면, 성공적인 프로젝트에 이미 그런 패턴이 자연스럽게 포함되는건 아닐까? 좀 더 생각을 정리할 필요가 있을 것 같다.
그리고 진행된 100분 토론. 내가 알고 있는 기존 OST보다는 유동적이지 못한 그런 토론이였다. 참가자가 많았고 시간도 적고 결국 하나의 주제 토론에 참가하면 100분간 장소 이동 없이 하나의 토론에 집중하는 방식으로 진행됐다. 몇 가지 주제 중에서 망설이다가 결국 최근 가장 관심이 갔던 ‘기업 문화’와 관련된 토론에 참가했다. 총 10명이 토론에 참가했고, 짧은 시간 동안 각자의 경험과 알고 싶은 것들에 대해 이야기했다. (10명은 토론하기에는 너무 많은 인원인 것 같다. 하나의 주제로 깊이 있게 얘기하기에는 100분이라는 시간도 너무 짧아서 아쉬움이 많이 남는다.)
8명의 엔지니어와 1명의 QA 전문가, 그리고 1명의 기자. 이렇게 구성된 멤버로 시작된 토론은 현재 소속된 조직에서의 테스트 문화에 대한 공유부터 어떻게 하면 테스트를 기업에 정착시킬 수 있는지에 대한 방법론까지 다양한 주제로 진행됐다.
규모의 문제가 있겠지만 개발 인력이 적은 곳은 아직 테스트 프로세스가 정립이 안되어 있거나 전문 테스터가 없는 경우가 많았다. 제품 출시 이전에 테스트를 통해 품질 향상을 가져올 수 있지만 이 부분에 대한 인식이 많이 부족한 것 같았다. (물론 검수 테스트를 해도 버그를 다 잡을 수는 없기 때문에 베타 테스팅이나 결국은 출시 후 빠른 사후 조치로 결함을 제거하는 방법이 필요하다는 의견도 있었다.)
이미 QA 부서가 있는 회사인 경우 QA의 역할에 대한 의견이 많았다. QA가 과연 개발 단계의 어느 시점부터 참여해야 하는지, 또는 QA가 어떤 역할까지 수행해야 하는지에 대해 대화를 나눴는데, 아직 QA라는 직종 자체가 형성되어 가는 과정에 있기 때문에 논란의 여지가 많았던 것 같다. (특히, QA가 PM 역할까지 수행하는 것에 대한 사례나 단점 등에 대해 얘를 많이 했다.)
100분의 토론 끝에 테스트가 제대로 수행될 수 있는 기업 문화를 만들기 위해서는 ‘테스트의 중요성’에 대한 인식을 공유할 필요가 있다는 결론에 도달했다. 테스트가 비용의 낭비가 아닌 결국 개발 비용 감소와 품질 향상으로 인한 매출 증대로 이어질 수 있다는 인식 형성이 필요하다. (실제로 QA 프로세스 도입 후 매출이 증가했다는 경험도 있었다.)
그리고 여러 분야에서 활동하고 있는 다양한 사람들을 만날 수 있었고, 또한 경험하기 힘든 난상 토론을 할 수 있어서 정말 좋았다. 앞으로도 다양한 곳에서 만남을 이어갈 수 있고, 또한 온라인 상에서도 많은 의견을 나눌 수 있기를 기대해 본다.
7 Comments
방금 친하게 지내는 과장님께서 [따지크]님 블로그를 보여주시더군여..
토론 때 같이 얘길 나누셨다고 하시더라고요.
전 신청해 놓고 집에 일이 있어 참석 못해 매우 아쉬웠답니다.
담에 기회되면 많은 얘길 나누고 싶네요~~
ㅋㅋ 만두랑 종화님이랑 두 분 다 안오셨나봐요? 기대 많이 하고 있었는데 아쉽네요.
또 기회가 있겠죠. 어제 한혜란 과장님 덕분에 파란에 대해 좀 알게 됐네요.
저도 기대가 컸는데 아쉽게 되었습니다.
혜란 과장님께서 어제 좋은 자리였다니 더욱 아쉽네요.
파란? 지표상으론 올해 그동안의 적자에서 흑자로 전환하는 첫 해가 되고있죠.
그런데 부작용도 많습니다. 최근들어 제가 속한 팀만해도 이직자들이 속출하니까요. 저 역시 요즘 여러가지로 생각이 많습니다. 가까운 지인분들과도 만남을 통해 여러가지로 방향을 모색중이기도 하죠.
그래도 아직 제가 생각하는 것과 실행하는 것에 대해 포기하지 않고 도전하고 있는데 점점 힘이 빠지네요. 여러가지로 생각을 많이하게 되지만 새로운 도전이라 받아들이고 좋은 결과가 있도록 고민해야 겠네요. ^^
좋았겠어요……
QA … 전 좋았는데 각개발자들은 싫어 하더라구요 ^^;;
싫은 이유가 QA를 위한 QA팀이 아니라 QA결과문서를 만들기 위한 QA라면서…
그래도 그들의 피드백은 품질향상에 분명히 도움이 되었습니다.
QA결과문서를 위한 QA라… 개발자가 QA에게 의존하는 것도 문제지만 QA가 잘못된 목표를 가지고 있을 때 프로세스 개선보다는 부작용이 많을 수 있겠군요.
개발자들이 직접해야 하는 테스트를 QA에서 진행하면 개발자 부담이 줄지 않나요?
맞아요.
개발자의 부담이 줄어들었어요.
문제는 QA도 한일에 대한 결과를 문서로 보여 지게 되는데요.
이 문서를 보면 효율적이지 못한 경우가 있어요.
예를 들면 어떤 모듈에 에러가 발생했을때 해당 모듈을 수정하기 전까지는
비슷한 경우의 수를 대입해도 똑같이 에러가 발생할것이라는걸 짐작할수있는데요.
그 경우의 수를 20 x 20 가지의 수를 모두 테스트를 진행하고 해당결과서에
모두 기록한 적이 있었습니다.
그럼 400가지의 ‘실패’ 결과가 나오게 됩니다.
이런 경우 결과서는 엄청나게 두꺼워지고,
QA는 테스트 결과 많은걸 잡아냈다는 만족감을 느낄수 있을 겁니다.
그리고 그만한 시간을 투자했을테구요.(QA 2명이서 1주일)
물론 다른 유용한 오류를 잡아내기도 했습니다.
그러나 결과서 일부가 이런 오류를 기록하느라 시간을 보냈다는것이 안타갑습니다.
그오류를 개발자가 고치는데 10분도 안걸려서 400건이 처리 되어버렸으니까요.
이것은 아마도 QA가 해당 Biz 로직을 모르거나, 프로그램특성을 잘 모르는데에서
비롯될수도 있지만, 결과서라는 형식표현에도 영향이 있었으리라 생각 됩니다.
개발자나 품질향상에는 분명 도움이 되지만, QA 업무 효율을 위해서는 해당 프로젝트 도메인을 잘이해하고 개발자와 함께 숨쉴수 있는 ‘Team’으로써의 QA가 필요할것 같다는 생각이 드네요.
개발자의 생산성을 작성한 코드 라인 수로 측정하는 오류와 비슷한 것 같네요. QA가 발견한 버그 수를 바탕으로 QA의 성과를 평가한다면 Max님이 이야기한 것과 같은 부작용이 발생할 수 밖에 없을 것 같습니다.
지금까지는 기획자-개발자간의 커뮤니케이션이 중요했다면 이제는 기획자-개발자-QA 모두의 커뮤니케이션이 중요하겠네요.
그리고 또 하나, QA 매니져의 백그라운드도 중요하더군요. 개발자 출신의 QA인지, 기획자 또는 다른 배경을 가지고 있는 QA인지에 따라 QA 업무에 대한 인식이 전혀 달랐습니다.