저번 포스트에 이어서 비즈니스/프로덕트 요구사항에 대해서도 탐색적 테스팅을 진행하는 방법을 기재해봅니다.
아래 포스트에서부터 이어집니다!
요구 사항에 대해 탐색적 테스트 해보기
아직 아무것도 구현된 것이 없는 상태에서 프로덕트/서비스에 대해 테스팅할 준비가 되어있지 않아도, 소프트웨어에 대한 아이디어를 테스트하는 것은 가능합니다.
문제를 조기에 식별하고 수정하는 것은, QA/테스트업계에서 활발하게 논의된 Shift-left를 충족시키기 위해서도 필요한 활동인데요, 이 활동을 요구사항 정의 단계에서부터 진행하는 것 입니다.
https://engineering.linecorp.com/ko/blog/quality-advocator-shift-left-shift-right
사용자의 요구사항을 분석할 때, 탐색적 테스팅 기법들이 어떤 도움을 줄 수 있을까요? 요구사항 회의에서 이렇게 했었더라면, 수많은 문제를 예방할 수 있었을 것이라고 생각합니다.
요구 사항 분석 회의에 참여하기
요구사항에 대해 테스트를 하기 위한 가장 첫 번째로는 요구사항에 대해 알고 있어야합니다.
지금 속해 있는 팀이나 회사에서 어떤 소프트웨어 개발 방법론을 사용하든지 상관없이, 요구사항 회의를 한다는 것은 의심할 여지가 없습니다. 보통 요구사항 회의 라고 부르지만, 때로는 설계 회의 라고 하기도 하고, 프로젝트 킥오프 Kick-off 라고 하기도 합니다. 회사가 애자일 방법론 중 하나를 이용한다면, UserStory workshop 이라고도 부를 것 입니다.
어떤 이름으로 불리던지간에 주요 이해관계자들이 만나서 앞으로 개발될 기능에 대해 함께 대화를 나누어가며 모두가 동일한 수준으로 이해할 수 있도록 함께 만들어주는 자리입니다.
이 자리에 테스트 담당자가 참여하여 비즈니스 요구사항에 대해 같이 분석하고 질의하며 대화를 통해 추가로 정의가 되어야할 기능과 동작들, 기존에 다른 기능들과 동작이 충돌이 날 모순되는 부분은 없는지를 체크해야합니다.
회의에서 제외되었을 때 발생하는 문제들
프로젝트 초기단계에서는 요구사항 회의에 소수의 관계자만 참여하는 경우가 있습니다. 여기서 많은 것들이 정의되기도 하는데요, 그 후에 점점 프로젝트의 규모가 커져가면서 참여하는 이해관계자들이 늘어나기 시작합니다. 이 때, 초기에 회의에 참여하지 않았던 사람들이 회의에 참여하면 기존 인원들이 미처 생각하지 못했던 새로운 의견들을 제시하고, 문제점들을 찾아내기도 하여서 심각한 경우 요구사항에 대해 다시 원점에서부터 생각하게되는 문제가 발생하기도 합니다.
따라서 가능하다면 프로젝트 초기에 연관되어있는 이해관계자들을 가능한 많이 초대를 하여 의견을 나누는 것이 중요하며, 테스트 담당자는 누락된 이해관계자는 없는지, 추가로 검토가 필요한 부분은 없는지 PO/PM과 함께 검토를 하는 것도 필요합니다.
1:1 회의에서 발생하는 오해들
어떤 경우에는 이해관계자 전원이 아니라 핵심 관계자 몇명, 혹은 기획자와 개발자 간의 1:1 회의를 진행하는 경우도 있습니다. 이러한 경우에 테스트 담당자는 다른 이해관계자의 의견을 확인하며 이해관계자들간에 인식하고 있는 요구사항이 정확한지 확인하기 위해 계속 별도로 미팅을 잡아야하는 문제가 발생하게 됩니다. (회의로 인한 리소스 낭비가 발생)
그 사이에서 커뮤니케이션을 하면서 가끔은 미스 커뮤니케이션이 발생하기도 하여 결과적으로는 잘못된 프로덕트가 만들어질 위험이 있습니다.
테스트 케이스 리뷰를 요구사항 리뷰로 활용한다.
요구사항 리뷰가 안된 상태에서, 테스트 방법 (프로덕트에 대해 어떻게 테스트를 진행해야하는지, 혹은 사전에 준비해야할 서버 설정이나 데이터들을 확인하기 위한다던지) / 작성한 테스트케이스에 대해 확인하며 요구사항과 다른 부분은 없는지 등에 대해 리뷰를 하기 위해 관계자들을 불러모아 리뷰를 하는 자리에서 질문을 할 때서야, 뒤늦게야 놓친 요구사항들을 확인할 수 있게되는 경우들이 있습니다.
이 때, 모든 가정에 대해 항상 질문을 던지고, 기획자가 필요로 했던 것과 개발자가 구현하려고 했던 것 사이에 있는 그 어떤 괴리를 찾아내기위해 탐험가의 사고방식을 지닌 누군가가 필요합니다. (그 누군가가 테스트 담당자가 되어야합니다.)
요구사항 회의에서 제외되고 있다면, 가장 좋은 방법은 그들의 모임으로 조용히 들어가는 것입니다. 오피스 내라면 그들의 티타임 자리에 같이 합석한다던지, 원격 회의를 진행한다면 누군가의 캘린더를 확인하고 해당 일정에 대해 같이 참여해도 되겠냐는 연락을 해서 같이 참여하도록 합니다.
기능 구현이 너무 많이 완료되기 전에 요구사항 회의나 테스트 리뷰 회의를 열어야하는 것을 꼭 기억해야합니다. 이슈를 조기에 확인하는 것이 수정하는데에 드는 리소스/코스트를 절감할 수 있게합니다.
(구현된 후에 다시 수정하려면 수정확인까지 포함해서 너무 많은 코스트가 소모된다. Shift-left.)
요구 사항 회의에서 해야 하는 것
요구사항 회의에 참여하게 된다면, 테스트 담당자는 능동적으로 회의에 참여해야합니다.
핵심 가치 찾아내기
각 요구사항 뒤에 숨겨져있는, 소프트웨어가 만들어진 이유를 이해함으로써, 모든 팀원이 각 요구 사항이 정말 필요로 하는 것들을 어떻게 구현해야 하는지 확신할 수 있습니다. 가장 중요한 유저 시나리오 를 확인하고, 이것에 초점을 맞추어서 기획한 테스트를 수정해볼 수 있고, 테스트를 작성할 수 있을 것입니다.
시스템의 핵심 가치를 발견할 수 있는 최고의 장소는 바로 요구사항 회의 입니다. 비즈니스 이해관계자들에게 소프트웨어가 비즈니스에 제공해주기를 원하는 핵심 가치를 물어보도록 합시다. 비즈니스 이해관계자들이 이야기하는 것들을 들으면서 메모를 하면서 중요한 특징이나 기능들에 대한 이야기는 귀 기울여 듣도록 하자.
~성 으로 끝나는 단어들도 집중해서 들어야합니다. 품질 기준과 관련된 신뢰성, 규모 가변성, 사용성, 정확성 등의 단어들인데요, 이러한 단어들에 귀기울아면 이해관계자들에게 어떤 종류의 정보가 가장 중요한지 알 수 있습니다.
“만약 ~한다면?” 이라고 질문을 던지자.
테스트 설계 기법을 적용해볼 수 있는 최적의 시간은 요구사항에 대해 논의하는 시간입니다. 전형적인 조직이라면 해피패스 Happy path 라는 이상적이고 완벽한 환경과 조건에서 소프트웨어가 어떻게 동작하는지에만 모든 팀원이 관심을 둡니다. 물론 안전한 경로에서도 제대로 동작하는지 살펴보고 이해하는 것도 중요합니다. 그러나 모든 것이 완벽하게 준비되지 않은 상황 에 직면했을 때 소프트웨어가 어떻게 동작할 지 이해하는 것도 매우 중요합니다.
가능한 에러 상황을 예측하기 위해 테스트 설계 기법을 사용하여 만약 ~한다면? 이라는 질문을 던져봅시다.
아래는 예시입니다.
- 만약 사용자가 전혀 예상하지 못한 무엇인가를 한다면 어떻게 되는가? 예를 들어 로그인한 사용자가 다시 로그인을 시도한다던지.
- 만약 소프트웨어가 필요한 자원에 대한 접근 권한이 없다면 어떻게 될까? 파일을 읽어야 한다던지, 데이터가 손상되었다던지
- 만약 사용자가 입력한 데이터가 소프트웨어가 기대하고 있는 것과 전혀 다르다면 어떻게 되는가? 최소한으로 필요한 레코드 개수보다 더 적은 개수의 레코드가 입력값으로 들어왔다면?
요구사항을 논의하면서 동시에 효과적으로 탐색적 테스트를 진행하려면 가능한 테스트 시나리오를 즉시 만들 수 있어야 합니다. 구현에 대한 대략적인 아이디어를 생각해낼 수 있어야하고, 머릿속에는 가능한 테스트 케이스들의 목록을 바로 생각해낼 수 있어야 합니다. 머릿속에 그린 테스트 케이스들 중에서 가장 흥미롭거나 가장 관련이 있는 케이스를 선택해서 만약 ~한다면? 시나리오로 만들어내야합니다
이야기를 나누면서 동시에 즉시 테스트를 설계하는 데에 익숙해지면 두 가지 보상을 얻을 수 있다.
- 발생 가능한 위험 요소들에 대해 물어보는 것만으로도 버그를 예방하기 위해 탐색적 기법을 적용할 수 있다.
- 내 질문에 대한 답변을 가지고 시스템이 처리할 수 있는 것과 처리할 수 없는 것을 구분하는 능력을 기르는데 큰 도움이 된다.
가끔은 멍청해보이는 질문을 하자.
어떠한 요구사항의 경우에는 이해관계자들이 어떠한 유사한 서비스/프로덕트 사용 경험으로부터 아 이건 이렇게 동작하는 거겠지? 하는 지레짐작으로 넘어가게 되는 경우가 많습니다. 이러한 경우에는 나중에 프로덕트가 구현이 완료되고 나서 프로덕트에 대해 테스트를 할 떄 알게되는 경우가 많습니다.
가끔은 당연해보이는 것에 대해서도 의문을 가지고 질문을 해봅시다. 해당 기능에 대해 의심을 가지고 있던 사람이 다른 여러명일 수도 있지만, 그들을 대표해서 멍청해보이는 질문을 해봅시다. 이러한 멍청한 질문을 통해 기존의 인식을 없애고 요구사항에 대해 올바르게 이해할 수 있게 되고, 이 행동으로 인하여 회의에 참여하고 있던 다른 이해관계자들과의 인식도 통일될 수 있습니다.
이해관계자간의 인식을 맞추며 프로덕트에 대한 기대치 조정하기
요구사항에 대해 적당히 인식하고, 적당한 인식으로 적당한 구현을 하려고 한 프로그래머의 입장에서는, 테스트담당자가 버그를 계속 찾아내면 낼수록 요구사항 명세서에 없었다며 불만을 가질지도 모릅니다. 즉, 테스터가 억지로 무엇인가를 계속 만들고 내고 있다고 생각할지도 모릅니다. (개발자와 테스트 담당자간 서로 관계가 안좋은 경우가 이러한 경우로 인해 발생하게 된다.)
이것은 테스트담당자와 개발자간의 요구사항에 대한 인식이 서로 다르기 때문에 발생하는 문제이기도 합니다.
버그를 찾아내는 것은 좋은 일이지만, 미리 프로젝트 범위에 대해 충분한 대화를 하고 문제를 해결했다면 더 좋을 것 입니다.
각자가 요구사항에 대해 이해하고 있고, 기대하는 것들에 대해 다른 팀원들과 함께 미리 조정하는 시간을 가지지 않는다면, 아마도 위와 비슷한 상황으로 마무리될 확률이 매우 높습니다.
프로젝트를 돌이키기에는 너무 늦은 상황에서 버그에 대해 이야기하는 경우라면, 실질적인 프로젝트 범위에 대해 논쟁하게 될 것입니다.
내가 리포트한 버그에 대해 인정하고, 수정한다면 그만큼 프로젝트 완료에 영향을 미치게되고, 내가 리포트한 이슈를 무시하고 진행된다면 그만큼의 시간을 낭비하게 됩니다.
회의가 끝난 후에도 요구사항 명세서에 대한 질의를 진행하자.
보통 회의는 1~2시간 이내에 제한된 시간동안 진행되기에 꼼꼼히 문서를 검토할 시간이 충분하지않으며, 진행 속도에 따라서는 몇몇 부분들에 대해 놓칠 수도 있습니다.
회의가 끝난 후에도 요구사항 문서에 대해 직접 inline-comment를 기록한다던지, 별도의 질의응답 문서를 작성하여 서면을 통해 요구사항에 대한 부가 설명을 요구하고, 상세내용에 대해 질의응답을 진행하도록 합시다.
이러한 행위를 통해서 요구사항에서 누락된 부분이라던지, 보완이 필요한 부분들을 Catch-up할 수 있게 해줍니다.
요구사항 논의하면서 차터 작성하기
소프트웨어가 꼭 해야하는 것과 하면 안되는 것들에 대해 질문을 하면서, 나중에 사용할 차터에 대해 미리 작성할 수 도 있습니다.
아래부분을 참고해가며 작성해보면 좋을 것 입니다.
- 요구사항을 논의하는 중에 나오는 기능이나 영역과 상호 연동되는 시스템의 다른 기능들이나 영역들
- 실제 운영서버의 데이터 스냅샷 또는 기존에 사용했던 테스트 데이터
- 핵심 사용자들의 환경 설정 파일 등
- 특별하게 중요한 유스케이스나 페르소나
- 결코 발생하지 않거나 항상 발생해야하는 조건들
- 만약 ~한다면 성능에는 어떤 영향이 있을까? 와 같은 품질 기준과 관련있는 개방형 질문들
- 이해관계자들이 궁금해하는 것들이나 걱정하는 것들.
이러한 조건들에 도출해내고, 이 조건들에 대해 작성한 차터를 리뷰받아볼 수도 있습니다. 리뷰를 받음으로써 이해관계자들이 테스트담당자가 어느 부분을 테스트하게될지에 대해 인식할 수 있게되며, 자연스레 테스트범위에 대한 인지도도 습득하게 됩니다.
능동적 읽기
얼굴을 마주보고 바로 대화하는 것이 요구 사항에 대한 정보를 정확하게 전달할 수 있는 최고의 방법입니다. 그러나 때로는 내가 팀에 합류 하기도 전에 이미 요구사항이 결정되어있는 경우도 있다. 이미 결정된 요구사항들이 문서로 작성되어있다면, 요구사항에 대한 정보를 대화를 통한 논의보다는 문서에서 더 잘 얻을 수 있습니다.
문서에 질문하기
능동적으로 읽는다는 것은 문서를 읽으면서 동시에 문서에 계속해서 질문을 한다 는 의미입니다. 문서에 대해 이미 소개한 만약 ~한다면? 이라고 질문을 던지는 것도 해볼 수 있습니다.
시스템에서 항상 True여야하는 것들에 대한 문장을 찾아냈을 떄에는 그 문장이 False가 되었을 때 어떤 일이 발생할지 생각해봅시다. 예를 들어 데이터의 최대 크기나 최대 사용자 수에 대해 범위를 한정하는 문장을 찾아낸다면, 이 범위를 벗어나는 경우가 발생했을 때 어떤 일이 일어나는지를 알려주는 문장을 찾아봅시다.
문서를 분석해서 정보 분류하기
문서에 있는 정보를 카테고리에 따라 나누는 것은 더 깊게 파헤치고 필요한 것에 더 집중 하는데에 도움이 됩니다. 요구사항 문서를 능동적으로 읽는 것이 더 잘 적용되는 한 가지 모델은 입력, 처리, 출력 모델 입니다. 이 모델을 사용하기 위해 종이 한 장을 준비해서
- 입력
- 처리
- 출력
- 질문
이렇게 4가지 구역으로 나누어봅시다. 관련 주제들을 이 네 가지 구역에 각각 나누어서 기록해봅시다.
입력은 소프트웨어가 받아들이는 것이라면 어떤 것이든 모두 입력에 해당됩니다. 예를 들어 사용자가 제공한 데이터에 관한 참고 자료들을 문서에서 찾아낼 수 있을 것 입니다.
출력은 소프트웨어가 만들어내는 모든 것이 출력에 해당됩니다. 리포트, 사용자에게 보이는 메세지, 로그나 콘솔에서 사용되는 메세지 또는 시스템의 다른 부분으로 전달되는 이벤트 같은 것들이 모두 출력에 포함될 수 있습니다.
처리는 소프트웨어가 어떻게 입력을 출력으로 바꾸는지 설명하는 모든 것이 다 처리에 해당합니다. 알고리즘이나 소프트웨어가 겉으로는 보이지 않아도 내부에서 하는 처리들, 임시 데이터에 대한 자료 등에서 찾아낸 모든 정보 처리가 해당됩니다.
입력, 처리, 출력에 대한 정보를 찾으면서 나온 모든 질문을 질문 영역에 기록해봅시다. 아마도 더 많은 만약 ~한다면? 질문을 찾아낼 수 있거나, 문서에 있는 정보가 명확하지 않다는 것도 발견할 수 있을 것 입니다.
모델 그리기
문서를 읽어가면서 상태 다이어그램이나 컨텍스트 다이어그램과 같이 그림으로 표현한다면 뜻이 더 잘 통할 것 같은 문장이나 단락을 찾아봅시다. 글로 적혀 있는 설명을 그림으로 바꾸어서 표현하는 것은 소프트웨어 설계에 있어 또 다른 시각을 가지게 해줍니다.
ref
- https://engineering.linecorp.com/ko/blog/quality-advocator-shift-left-shift-right
- 엘리자베스 헨드릭슨, 『탐험적 테스팅 : 배우고 통찰하며 개선하는 소프트웨어 테스트』, 오광신 옮김, 인사이트(2014)
