P-Camp 그 두번째 만남을 다녀왔습니다. 2007년 10월 10일 수요일, 코엑스 컨퍼런스센터 401호에서 열렸습니다. 시작하기 전에 신청했던 샌드위치를 먹고나서(처음에는 물이 없어서 그냥 먹다가……

지금까지는 기획자-개발자간의 커뮤니케이션이 중요했다면 이제는 기획자-개발자-QA 모두의 커뮤니케이션이 중요하겠네요.

그리고 또 하나, QA 매니져의 백그라운드도 중요하더군요. 개발자 출신의 QA인지, 기획자 또는 다른 배경을 가지고 있는 QA인지에 따라 QA 업무에 대한 인식이 전혀 달랐습니다.

지난 10월 8~11일에 열린 대규모 국제 컨퍼런스 ASTA, 테스트 엔지니어 쪽에 종사하시는 많은 분에게 큰 호응과 관심을 받은 행사였습니다. 저희 올라워커들도 행사 이곳저곳에 참여해 크고 작

예를 들면 어떤 모듈에 에러가 발생했을때 해당 모듈을 수정하기 전까지는
비슷한 경우의 수를 대입해도 똑같이 에러가 발생할것이라는걸 짐작할수있는데요.
그 경우의 수를 20 x 20 가지의 수를 모두 테스트를 진행하고 해당결과서에
모두 기록한 적이 있었습니다.
그럼 400가지의 ‘실패’ 결과가 나오게 됩니다.
이런 경우 결과서는 엄청나게 두꺼워지고,
QA는 테스트 결과 많은걸 잡아냈다는 만족감을 느낄수 있을 겁니다.
그리고 그만한 시간을 투자했을테구요.(QA 2명이서 1주일)
물론 다른 유용한 오류를 잡아내기도 했습니다.
그러나 결과서 일부가 이런 오류를 기록하느라 시간을 보냈다는것이 안타갑습니다.

그오류를 개발자가 고치는데 10분도 안걸려서 400건이 처리 되어버렸으니까요.
이것은 아마도 QA가 해당 Biz 로직을 모르거나, 프로그램특성을 잘 모르는데에서
비롯될수도 있지만, 결과서라는 형식표현에도 영향이 있었으리라 생각 됩니다.

개발자나 품질향상에는 분명 도움이 되지만, QA 업무 효율을 위해서는 해당 프로젝트 도메인을 잘이해하고 개발자와 함께 숨쉴수 있는 ‘Team’으로써의 QA가 필요할것 같다는 생각이 드네요.

QA … 전 좋았는데 각개발자들은 싫어 하더라구요 ^^;;
싫은 이유가 QA를 위한 QA팀이 아니라 QA결과문서를 만들기 위한 QA라면서…
그래도 그들의 피드백은 품질향상에 분명히 도움이 되었습니다.