새로운 서비스를 준비하다보면 문제점을 파악하거나 사용성에 대한 개선, 데이타 수집등의 이유로 프로젝트에 참여하는 몇몇 사람들 외에 더 많은 사람들이 참여하는 테스트가 필요한 경우가 있습니다. 이 때, 팀내 또는 사내 테스트 등을 진행하게 되는데요 이것은 서비스 출시전에 하는 QA과정과도 다르고 프로젝트 참가자들이 일상적으로 해오던 테스트와는 조금 다른 과정이라 이에 대한 주의점을 정리해봅니다.
우선 테스트에 참여하는 사람들은 해당 프로젝트에 직접적인 관련은 없으나 관심과 애정으로 자의든, 지시나 할당처럼 타의든 자신의 시간을 내서 테스트를 합니다.
해당 서비스에 대해서 또 테스트라는 과정에 대해서 잘 모르는 사람들이니 이에 대한 고려와 배려가 필요합니다.
- 테스트의 명확한 목적 설정과 참여자들에게 공유
현재 하려고 하는 이 테스트가 무엇을 목적으로 하고 있으며 참가자들이 테스트 해주면 어떠한 점들이 개선될 것인지를 충분히 설명해야 합니다. 예를 들자면 버그를 잡아야하는지, 기능이 불편하지는 않은지를 알고 싶은지, 부하를 테스트해야하는 것인지, 데이타 수집이 목적인지 말입니다. 그래서 테스트가 끝나면 버그가 잡히는지, 기능이 편리해지는지, 부하가 분산되어 속도가 개선되는지, 데이타를 모으는 과정에서 오류를 찾아낼 수 있는지에 대해서 공유해야 합니다. 이것은 자발적 테스터들이 어떤 점에 주안점을 두어야하는지를 이해하고 효율적으로 테스트 할 수 있으며 자신의 시간과 노력으로 기여하는 가치가 무엇인지를 알려주어 중요한 동기부여가 됩니다. - 테스트 항목과 결과에 대한 구체적인 지정과 설명
이것은 QA에도 해당되는 이야기입니다만 비전문가가 테스트를 할 때에는 더 챙겨야하는 항목입니다. 프로젝트를 진행했던 사람들은 짧게는 수주, 길게는 수개월간 그 서비스의 기획단계부터 함께 해왔기 때문에 용어,화면, 메세지, 결과 화면,인터페이스 등에 매우 익숙합니다. 그러나 테스트를 하는 사람들 중 다수는 그 서비스를 처음 본 사람들입니다. 게다가 그 서비스는 아직 완성품도 아니고 불안정하며 불친절한 상태입니다. 어디부터가 제대로 된 결과이고 어디부터가 오류인지도 사실 알기 어려울지 모릅니다. 예를 들어 “값이 잘 나오는가?”같은 문항은 피해야 할 테스트 항목이죠. 손은 좀 가겠지만 테스터들이 헷갈리지 않도록 캡춰 화면을 이용해서 테스트 해야할 항목과 값을 표시해주는 것도 고려해볼만 합니다. - 불안정한 테스트 환경에 대한 고려
테스트는 모든 개발과정이 완벽히 끝나고 QA에 대비할 수 있는 상태에서만 이루어지지 않습니다. 그러다보니 서버,네트워크,클라이언트,데이타베이스,인증,화면 구성요소, 인터페이스 등 많은 요소들이 불안정하고 미완성인 상태에서 테스트를 해야하는 경우가 자주 생깁니다. 테스트 전 이에 대해 양해를 구하도록 하고, 아울러 불안정한 상황을 줄일 수 있으면 그렇게 할 수 있는 방법들을 준비해야 합니다.
사용자가 값을 넣어야하면 미리 테스트를 위한 데이터를 준비한다던지, 개발자 컴퓨터를 서버로 사용한다면 테스트 기간중에는 서버 연결이 끊기지 않도록 미리 개발자와 협의가 되어 있어야 합니다. 한창 값 넣고 확인 버튼을 눌렀더니 “서버에 연결할 수 없습니다.” 라며 값이 사라져버려서는 안되겠지요.
필요할 때 주위에 있는 동료, 팀원들이 테스트 해줄 수 있다면 더 나은 서비스가 나오는데 많은 도움이 될 것입니다. 그들이 보람을 갖고 혼란없이 쉽게 도울 수 있도록 미리 준비하는 노력이 필요한 것은 당연한 일이겠지요.
좋은 정보입니다. +_+
아크몬드// (–)(__)