토론했던 테이블 모습 |
우리는 1(A)조 |
토론결과 공유 |
토론장 모습 |
제2회 P-Camp에 다녀왔습니다.
ASTA 국제 S/W테스팅 컨퍼런스와 조인하여 이번엔 테스트를 주제로 열렸습니다.
접수시간에 맞춰 2시간 일찍 퇴근하고 회사동료 두분과 함께 삼성동 코엑스로 향했습니다.
접수시간보다 약간 일찍 도착했는데.. 아직 토의룸 셋팅 작업이 안 끝났더군요.
ASTA 전시부스를 돌아보면서 기다리다가 6시부터 접수가 시작되었습니다.
미리 샌드위치를 주문해서 기부금 5천원을 내고 호밀샌드위치를 받았습니다.
회사에서 아침마다 주는 샌드위치보단 맛있더군요..
p-camp는 스마트 플레이스의 황재선님의 사회로 진행됬는데..
깔끔하고 잼있는 어투로 시선을 중앙으로 집중시키더군요. ^^
ASTA에 사정상 참석하지 못한 분들을 위해 김창준님이 준비하신 튜토리얼시간이 있었는데요.
'Ontogeny of Unit Tests in TDD' 라는 약간은 낯선 주제로 발표를 해주셨습니다.
발표 중간에 '미디어 아트'라는 걸 보여주셨는데..
TDD가 예술로 승화(?)된 듯한 느낌이였습니다.
튜토리얼 앞부분만 잠시 더듬어보면..
테스트를 두 가지로 나눠볼 수 있다.
support programming 테스트, 제품 비판/평가하는 테스트.
전자는 test to pass로 프로그래밍 설계를 돕고, 실수를 줄이고 생산적으로 개발하는게 목적이다.
이 테스트가 없다면 예상못한 bug가 발생할 수 있다.
후자는 test to fail로 결함을 찾는게 목적이다. 이 테스트만 한다면 개발기간이 길어진다.
그리고 테스트는 이 두가지 면이 다 필요하다. ( 메리 포펜딕 )
그러면서.. 크리스토퍼 알렉산더(Christopher Alexander)라는 건축가가 저술한 'Nature of Order'라는 책 소개가 있었습니다.
화려한 수식어가 붙으며 극찬을 받은 책이라고 하는데..
총 4권 중 세미나에서 소개한 2권은 함 읽어보고 싶더군요.
아마존에 찾아보니 60불에 판매중 이네요..
참고로, p-camp에서 보여주신 김창준님의 강의는 요기에서 맛보기 동영상을 보실 수 있습니다.
그 뒤로 본격적으로 이어진 OST..
약 280명정도 참석한 자리여서 토론은 소그룹으로 나눠져 진행되었다.
첨부한 사진에서 분위기가 좀 전달될지 모르겠는데...
내가 참여한 세션은 "웹 환경에서의 테스팅"을 주제로 토론을 했다.
토론 참석자는 개발자, 기획자, QA, 이러닝 연구원, 학생 등으로 다양한 롤을 갖고 있었는데..
어찌 아셨는지 모두 명함을 준비해오는 센스를 발휘해 주셨고. 아이스 브레이크를 갖은 후엔 편안하게 얘기할 수 있었다.
주제가 광범위한 탓에 여러가지 이야기가 오고갔는데..
회사마다 테스트를 대하는 분위기가 틀린 것을 확연히 느꼈다.
- QA가 단순 테스터의 역할만 하고 있는 실정인 것은 대부분 회사가 마찬가지 인 듯 했다.
- QA가 프로젝트 시작 단계부터 투입되 일정관리 및 기획서상 불충분한 부분은 수정요구도 할 수 있는 회사도 있다. QA팀의 진짜 의미를 따진다면 단순 테스터의 역할만 해서는 안될 것이다.
- 프로젝트 릴리즈 후 문제 발생시 QA팀에 책임을 묻는 만큼 프로젝트 진행에 대한 권한도 필요함을 동감했다.
- 어떤 회사에선 기획자가 작업 단위별로 스토리보드를 엑셀로 정리해 개발자에게 전달한다. 구현해야 할 기능, 테스트할 내용 등을 작업별로 정리해서 개발자에게 넘겨주는데.. 히스토리 관리 및 번번히 엑셀을 작업하는데 드는 비용이 크다는 점을 발견했다. 이 경우 이슈트레커를 사용하면 커뮤니케이션 비용을 줄일 수 있다는 의견이 제시됬다.
- 또 다른 어떤 회사에선 QA팀이 생긴지 오래되었는데, QA에 너무 의존한 나머지 기술팀에서 허술하게 개발하고 QA에 책임을 전가했다고 한다. 대충 개발 한 후 테스트 단계에서 오류를 찾아내면 고쳐주고 그렇지 못하면 그냥 릴리즈 한다는 것인데.. 이런 이유로 QA팀을 대폭 축소하게 됬다고 한다.
일단, QA팀에 프로젝트 검수를 맡기면 맘에 홀가분하다고 느낀 적이 있었는데.. (왜냐면 QA팀에서 찾아준 버그만 고쳐서 OK사인을 받으면 오픈할 수 있으니까..) 좀 더 책임감을 가지고 꼼꼼하게 테스트하며 개발해야 겠다는 반성을 하게됬다.
- 벤처의 경우는 QA팀이 별도로 존재하지 않는다. 개발자가 직접 테스트하고 릴리즈 하는데.. 간단한 이슈라 실장비에서 직접 고치는 경우가 있다고 한다. (급하고 정말 실수 없을만한 일이라면 가끔 이러기도 하지..;) 하지만 공동작업을 하는 경우, 이슈가 공유되지 못한다면.. 또는 소스를 저장소에 올려두지 않았다면.. 다른개발자가 소스를 수정하고 commit했을 때 더 큰 문제를 발생 시킬 수 있으므로 주의를 해야한다.
- 퀄리티가 낮음을 QA팀에서 이야기했음에도 불구하고 사업이슈때문에 그냥 릴리즈 해야 했던 사연 등등...
많은 이야기가 오고갔다.
토론에 대한 이야기는 서기를 맡아주신 분이 메일을 주시면 좀 더 보충해 봐야겠다.
느낀점은 큰 회사일수록 QA에 대한 중요성을 인식해 QA부서를 갖추고 있고 개발자들도 단위테스트를 통해 퀄리티를 높이는 느낌이였다.
토론시간은 100분이였는데, 이런저런 이야기들을 나누다 보니 순식간에 시간이 다 지나버렸다.
까칠하다는 개발자들도 일단 입을 떼면 그 다음부턴 이야기가 술술 나오는 듯 하다.. -_-;;
토론 끝난 후 몇몇 팀에서 정리한 내용을 발표했는데...
공감가는 얘기들도 많았고, 전혀 반대되는 결과를 도출한 팀도 있었다.
하지만 모두 열의를 가지고 토론에 임했음을 느낄 수 있었다.
토론결과를 공유하는 시간쯤 되니 열기 때문에 토론장이 덥게 느껴지기까지 했다.
바쁜 근무시간을 쪼개 다녀왔는데..
테스트에 대해 다른 회사 이야기도 전해듣고 공감대도 형성할 수 있는 좋은 시간이 된 것 같다.
3회 p-camp가 열릴지 말지 모른다고 했는데...
부디 이런 토론 문화가 잘 정착했음 하는 바램이다.
댓글