(번역) No Documentation? No Problem!

이하 BETTER SOFTWARE FEB. 2004의 아티클을 번역한 것을 공개한다.

No Documentation? No Problem!

How to make requirements appear out of thin air by Lakshmi Narayani

테스터들과 테스트 매니저들은 종종 테스트 해야 할 요구사항이 없음에 대해서 불평한다. 이 상황의 발단에서 부터 신화를 헤쳐보자. 요구사항이 없다고 말할 때, 그것은 요구사항 문서가 없는 것이다. 확실히 소프트웨어는 아무것도 없는 상태에서 개발되지는 않는다. 소프트웨어를 착안하고, 디자인하고 만드는데 기여하는 사람들이 분명히 존재한다. 그들은 약간의 문서를 가지고는 있거나 최소한 자신들의 머리속에 이러한 내용을 가지고 있다.

하지만 자신들의 머리속에 있는 이러한 정보를 어떻게 테스터가 사용할 수 있게 할까? 나는 4년이상 소프트웨어 테스팅에 몸담았었는데, 일을 하는데 필요한 올바른 툴을 가지지 못해 좌절했었다. 그래서 나는 이것에 대해서 생각한 적이 있었다. 무엇이 테스터들의 힘일까? 우리는 건방진 질문을 하는 것으로 악명이 높다. 그렇지 않나? 따라서 탐사하고, 탐색하고, 깊게 파고드는 우리의 능력을 이용하고, 올바른 질문을 해서, 나는 약간의 역공학을 수행하는 툴을 스스로 만들었으며, 그것은 당신의 눈앞에 요구사항을 드러내게 만들어주는 툴이다.

Step 1: 이면의 정보를 드러나게 하라.

가장 먼저 해야할 것은 소프트웨어의 목적과 기능을 이해하려고 노력하고 탐색하는 것이다. 해당 소프트웨어의 이전 버전이 사용가능하다면, 이해를 증진시키기 위해 그것을 연구하라. 해당 소프트웨어가 현존하는 버전이라면 버그 리포트, 실제 필드에서의 결함, 그리고 해결책 등을 주의 깊게 살펴보라. 버그 리포트는 대개 오류가 난 동작에 대해 상세한 내용을 담고 있다. 의도된 기능에 대해서 충분한 문서가 존재하지 않는 경우, 버그 리포트는 훌륭한 소스가 된다.

개발팀과의 토의나 미팅을 요청(주장)하라. 어떤 것들은 문자 그대로 그리스어나 라틴어처럼 들릴 수도 있다. 참고 견디고 집중해보라. 당신의 과제는 가능한한 배우는 것이다.

유사한 소프트웨어에서 정보를 수집하고, 소프트웨어에 들어가는 전형적인 기능을 식별하라. 인터넷 검색은 정보를 수집하는 한가지 방법이 될 수 있다. 예를 들어, 웹 기반의 주문 처리 시스템이나 기업형 정보 포탈을 테스팅하는 경우, 사용 가능한 다른 제품을 통해 정보를 얻기를 원할 것이다.

Step 2: 매직 테이블을 작성하라

이러한 탐색과 정보 수집의 모든 과정을 거치면 결국 과도한 질문을 유발하게 된다. 모든 명백한 것들과 그다지 명백하지 않은 기능들에 대해 질문해 보라. 어떤 것도 가정하지 말고, 어떤 수단을 모두 동원하려고 하지는 말아라. 당신이 지금 필요로 하는 것은 핵심적인 것 즉, 질문을 문서화하는 것이다.

당신의 질문들은 명백하게 소프트웨어의 어떤 측면과 연관이 될 것이다. 예를 들어, 당신이 GUI 기반의 소프트웨어를 테스팅한다고 가정해보자. 4컬럼의 테이블을 작성함으로써 시작할 수 있다. (그림 1을 보라)

1. 스크린/윈도우 이름
2. 오브젝트 이름
3. 기능
4. 전문가의 코멘트 (이 컬럼을 잊지말라!)

모든 스크린/윈도우의 포괄적인 리스트로 채워라. 개개의 스크린과 윈도우 외에도, 그 스크린과 윈도우와 연관이 있는 질문이나 모든 오브젝트를 나열하라.

모든 윈도우와 오브젝트는 그것과 연관된 기능이 존재할 것이다. 소프트웨어를 탐색해서 얻은 정보를 기초로 해서, 비교하는 연구를 수행하고(Step 1), 이 각각의 오브젝트와 연관된 것으로 판단되는 기능을 기록하라. 예상되는 기능이 분명치 않은 경우에는, "분명하지 않음"이라고 적어라. 당신이 특정한 질문을 가지고 있다면, 기능 컬럼에 그러한 질문을 포함시켜라.

그림 1: 작업중인 매직 테이블

현재 소프트웨어에서 구현/고려된 유사 제품의 연구를 통해 드러난 핵심 기능들이 들어있나? 그렇지 않다면 왜인가? 소프트웨어를 제작할 때 의도적으로 제외시킨 것인가 또는 간과하여 빠뜨린 것인가? 기능 컬럼에 이러한 질문을 적어 넣어라. 목적은 오브젝트와 질문을 연관시키는 것이다.

Step 3: 매직 워드를 보강하기 위해 전문가에게 문의하기

이러한 질문에 답을 얻을 필요가 있으며 당신이 이해하고 있는 바가 검증되어야 한다. 당신이 질문을 하고 있지 않은 오브젝트에 대해서도 기능적인 질문처럼 당신이 이해하고 있는 바를 서술하라. 기술 전문가, 컨셉 디자이너, 비즈니스 부서 대표자, 개발자들에게 질문 테이블을 돌려본다. 기본적으로 어떤 제시를 해줄 수 있는 팀내 모든 사람에게 회람한다. 그들에게 각각의 테이블의 행에 대해 자신들의 대답, 사고, 이해한 바를 피드백 달라고 요청한다. 그들의 피드백을 코멘트 컬럼에 나열한다.

피드백은 항상 즉각적이지 않을수도 있다. 하지만, 기억할 것은 인내는 항상 요구된다는 점이다. 상기를 시켜주고 자주 대응하라. 이러한 것이 이루어지지 않는다면, 팀이 모여 이슈와 질문을 논의할 수 있는 미팅의 스케줄을 빠르게 제공하라. 모든 질문을 모든 사람에게 보내지 말고, 분할하여 정복하는 접근법을 시도해서, 질문의 일부분에 맞는 전문성을 가진 전문가에게 보내라. (Try the divide-and-conquer approach - instead of sending all the questions to everyone, send a subset of the questions to each expert based on her area of expertise.) 이러한 접근법이 효과를 발휘하지 않는다면, 상사의 도움을 구하라. 그리고, 품질 있는 제품을 전달하기 위해서는 이러한 데이터를 취합하는 것이 중요하다는 것을 그들에게 확신시켜라. 매니저에게 이 점을 모든 관계자들에게 의사소통하도록 촉구하라.

그림 2: 보라! 요구사항으로 채워진 테이블이다.

Step 4: 약간의 술책을 발휘하라

모든 답변을 취합하고, 코멘트를 유형화해서 조직하고, 그룹의 합의를 도출한다. 전문가들이 낸 질문에 제공된 답변에 근거하여, 테이블의 기능을 업데이트한다. 각개 전문가로 부터의 모든 코멘트를 포함하여, 차례로 각 전문가의 답변을 모두 처리한다.

이 시점에서, 전문가들의 의견 사이에서도 중복되고 불일치하는 것이 많이 있을 수 있다. 만일 불일치하는 의견이 존재하는 경우 이를 반복적인 프로세스로 처리할 필요가 있다. 필요한 경우 미팅을 요청한다. 끈기있게 설득적으로 인내를 가지고, 모든 질문들이 처리되고 불일치가 해결될 때까지 반복한다. 결국 당신은 전문가 그룹의 동의를 얻게 될 것이다. 코멘트 컬럼에 특정 기능을 명확히 해준 전문가의 이름을 적어라. 이것은 미래에 당신이 대응을 하는데 도움이 될 것이다.

(마술사가 내는 기합) 얍!

당신은 이제 게임 내의 모든 플레이어가 동의하고, 테스트 팀에 의해서 준비된 모조(pseudo)의 요구사항 문서를 얻은 것이다. (하지만, 얼마나 "모조"한 것인가? 정말인가?) 당신은 잘 수행했다는 데 대해 자부심을 가져도 된다.

나는 내가 작업했던 테이블 템플릿을 공개했다. 당신은 동일한 템플릿을 사용할 수도, 그것을 개선할 수도 있다. 이 아이디어는 모든 적절한 정보를 표의 형식으로 수집하고, 변경이 발생하면 테이블의 업데이트를 지속적으로 수행하는 것이다. 기억하라. 이 프로세스는 요구사항이 이미 사용가능하지만 잘 정의되어 있지 않은 경우에도 사용할 수 있다.

초기에는 이것에 매우 많은 시간과 노력이 들어갈 것이다. 하지만, 곧 다른 플레이어들은 요구사항을 명확하게 정의하는 것의 중요성을 인식하고, 나를 믿게되어, 상황은 지금보다 매우 많이 달라질 것이다. 이 접근법을 적용해야 하나? 내 생각에는 최소한 시도할 만한 가치는 있어 보인다. 행운을 빈다. {끝}

Lakshmi Narayani is a CSQA with five years of experience in software testing. Lakshmi has condected many training sessions on testing concepts, processes, and tools. Currently, Lakshmi works as a senior system executive of Efunds, Chennai, playing the role of team lead for a Web based order-processing applications testing project. Email: lakshiminarayani@hotmail.com