탐색적 테스팅 - 3. 탐색적 테스팅을 하면서 버그를 찾아내기 위한 노력들 - 2

Dahun Yoo·2023년 10월 3일

QualityAssurance testing 탐색적테스팅

QA or Test

목록 보기

37/38

이번 포스트에서는 저번 포스트에 이어서 탐색적테스팅을 하면서 버그를 찾아내기 위해 어떤 점들에서 신경을 써야할지 기재합니다.

아래 포스트들에서 이어집니다.

이슈를 찾아내기 위해 의식해야할 것들 - 1

결과를 가지고 판단하기

주어진 요구사항에 따라 기대되는 겨로가가 명확한 경우도 있습니다. 그러나 눈앞에 보이는 결과가 정확한지 판단하기 위해, 개인의 주관적인 견해나 특별한 전문 지식을 필요로하는 경우가 더 많습니다.

특정 페이지가 즐겨찾기에 추가되지 않는다면?
박사급 연구원들이 사용하는 소프트웨어를 테스트한다고 했을 때, 입력값에 대한 결과값에 대해 어떻게하면 검증할 수 있을까? 계산식이 옳다는 것은 어떻게 확신할 수 있는가?

사실 이런 경우가 탐색적 테스팅을 할 떄 가장 큰 도전이기도 합니다. 탐색적 테스팅은 소프트웨어와 관련해서 이전에는 그 누구도 생각하지 않았던 질문들을 던지는 것을 포함합니다. 그러나 질문을 던지는 것에서 끝나는 것이 아니라 어떻게 탐험을 계속 진행하는 것이 좋을지, 또는 적어도 찾아낸 수많은 정보 중에서 추가로 조사가 더 필요한 중요한 정보를 어떻게 걸러낼지 하는 것만이라도 생각해보는 것도 필요합니다.

결코 발생하지 않거나, 항상 발생하거나…

시스템은 나름 어떠한 규칙을 가지고 있습니다. 탐색적 테스팅을 수행할 때 우리가 해야할 일 중 하나는, 결코 일어나지 않거나, 항상 일어나야하는 소프트웨어 규칙을 찾아내는 것 입니다.
어떠한 경우라도 테스팅중에 결코 일어나지 않아야 하는 일이 일어나거나, 항상 일어나야 하는 일이 일어나지 않는다면, 그것은 아주 심각한 문제입니다. 그래서 탐색적 테스팅 중에 어떤 결과들이 나와야 하는지 아주 자세하고 확실하게 알지는 못하더라도, 적어도 기대했던 결과들이 아닌 경우에는 절대 그냥 넘어가서는 안 됩니다. 사실 꼭 지켜져야 하는 규칙들이 지켜지지 않는 경우를 찾아낼 수 있다면 좋겠지만, 어떤 데이터나 설정이나 일련의 동작들을 조합해서 이런 경우를 찾아내는 것은 불가능에 가깝습니다.

그렇다면 테스팅 중인 시스템에서 꼭 지켜야하는 규칙들이 무엇인지 어떻게 알 수 있을까요? 시스템이 절대 하면 안되는 것들 또는 꼭 해야만 하는 것들에 대한 힌트를 얻을 수 있는 가장 좋은 시간은 요구사항에 대해 이야기를 나눌 때 입니다.

항상 올바르게 동작해야 하는 시스템의 핵심 기능들
시스템이 절대 타협해서는 안되는, 꼭 지원해야하는 것들 : 신뢰성, 규모 가변성, 사용성, 정확성 같은 품질 기준
프로젝트 이해관계자들이 주목하고 있는 다른 위험 요소들

핵심 기능

시스템은 꼭 수행해야하는 핵심 기능이 있습니다. 소프트웨어는 반드시 필요한 것이 아니라, 가지고 있으면 좋아보이는 부가적인 기능들 또한 가지고 있습니다. 그러나 모든 시스템에는 다른 모든 기능이 실패할지라도 꼭 수행해야하는 핵심 기능들이 있고, 이 핵심 기능들이 시스템의 특별한 고유 기능이 됩니다.
사실 프로젝트의 이해관계자들이 시스템의 핵심 기능이 무엇인지에 대해 서로 다르게 생각하고 있다는 사실을 깨닫기까지는 그리 오래걸리지 않습니다. 시스템이 어떤 기능을 수행해야 하는지를 구체화하는 프로젝트 관리자나 비즈니스 분석가들은 다르게 생각하고 있을 수 있습니다. 프로젝트 이해관계자들이 생각하고 있는 소프트웨어의 핵심 기능들에 대해 공감대를 형상하기 위해서는 다음과 같은 질문들을 서로 해볼 수 있습니다.

누가 사용하고 어떤 목적으로 사용하는지
다른 대안은 있는지? 다른 서비스 대신 왜 우리 서비스를 써야하는지.
이 소프트웨어에 대해 설명 가능한지.
만약 한 가지 기능을 제외하고 나머지 모든 기능이 동작하지 않는다고 하면, 꼭 동작해야하는 그 한 가지 기능은 무엇인지?

품질 요소

때로는 ~성 이나 비기능 요구사항 이라고 부르는 소프트웨어의 품질 요소는 결코 해서는 안되는 것들과 항상 해야만 하는 것들을 또 다른 관점에서 볼 수 있도록 도와줍니다.

정확성 : 결코 부정확하거나 틀린 결과값을 반환하지 않고, 계산에 사용될 수 없는 입력값에 대해서는 항상 에러 메세지를 보여준다
신뢰성 : 사용자가 시기를 놓치든, 잘못된 입력값을 입력하든, 예상치 못한 행동을 하든지 상관없이 항상 사용자의 마지막 상태를 그대로 복구한다.
가용성 : 사용자 요청이 있으면 정해진 시간 내에 항상 응답한다.
사용성 : 사용자 행동이 어떤 결과를 야기하는지 항상 피드백을 제공하고, 현재 상태에서 사용 가능한 것들을 분명하게 알려준다.
접근성
보안성 : 권한이 없는 사용자에게는 결코 노출하지 않고, 사용자가 악의적인 의도로 코드를 입력할 수도 있으니 어떤 경우에도 사용자의 입력값을 결코 코드로 실행하지 않는다.

위에서 소개한 것은 하나의 예시일 뿐입니다.

위험 요소

이해관계자들이 가장 우려하는 위험 요소는 숨겨져 있어서 보이지 않는, 결코 해서는 안되는 것들과 항상 해야만 하는 것들이다. 의료 기기같이 안전이 필수인 시스템에서는 환자에게 해를 끼치는 모든 것이 놓쳐서는 안되는 위험요소입니다. 금융 관리 시스템에서는 돈이 없어지는 것이 위험 요소입니다. 결제 시스템에서는 고객의 결제 금액이 청구되지 않거나 과잉 청구되는 것이 위험 요소입니다.

사용 가능한 다른 자원들

테스트를 해야하는 시스템이 있는데, 이 시스템에 대한 자세한 요구 사항 정의서나 설계 문서가 없는 상황이라면, 시스템이 어떻게 동작해야 하는지 예상하는 것이 불가능해 보일지도 모릅니다. 하지만 시스템의 동작을 예상하는 데 필요한 가장 훌륭한 자원을 이미 가지고 있다고 할 수 있는데, 그것은 바로 테스트 가능한 소프트웨어 그 자체 입니다. 또한 필요한 다른 자원들을 얻을 수 있는 기회가 있는 경우도 있습니다. 상황에 따라 다르겠지만, 비슷한 일을 하는 다른 소프트웨어 패키지에 대한 정보를 얻을 수 있는 기회도 있습니다. 또는 소프트웨어가 공개된 표준에 따라 개발되고 관리되는 경우도 있습니다.

내적 일관성

소프트웨어 사용자들은 자신이 사용하는 소프트웨어가 당연히 모순이 없는 일관성을 가지고 동작할 것이라고 믿습니다. 그래서 소프트웨어가 정확하게 동작하고 있는지 평가하는데 있어 소프트웨어 그 자체가 큰 도움이 될 수 있습니다.

표준

의료 업계, 금융 서비스, 방위 산업 같이 규제가 엄격한 분야에서 소프트웨러를 개발한 경험이 있다면, 소프트웨어가 꼭 지켜야 하는 표준에 이미 익숙할 것이고, 심한 경우에는 표준때문에 아주 고생했던 기억이 있을 수 있습니다.
규제가 심한 분야가 아니라 할지라도, 테스트하는데 놓치지 말아야하는 것들의 목록을 만드는데 도움이 되는 표준들을 찾을 수 있습니다.

GUI 가이드 라인 문서
통신 프로토콜
W3C 기반 HTML 문법, HTTP status code
Open Web Application Security Project에서 제공하는 보안 웹 애플리케이션과 웹 서비스 구축 가이드

물론 소프트웨어가 관련 표준들을 따를 것인지 아닌지 결정하는 것은 소프트웨어의 요구사항을 정의할 때 놓치지 말고 챙겨야 할 중요한 결정 사항 중 하나입니다. 소프트웨어가 표준들을 지키는지, 지키지 않는지 확인하는 데 시간과 노력을 허비할 필요는 없습니다. 그러므로 소프트웨어가 어떻게 동작할 지 예측하려고 표준 문서를 참고하기 전에, 소프트웨어가 이 표준을 따르기로 했는지, 모든 이해관계자가 이미 동의했는지 확인 해보는 것 이 중요하겠습니다.

비교하기

회사에서 하나가 아닌 여러 소프트웨어 패키지를 만드는 경우라면, 여러 다른 상황에서 소프트웨어가 어떻게 동작해야하는지 확인이 필요할 때 다른 패키지들을 참고 할 수 있습니다. 인증되지 않은 사용자가 인증이 꼭 필요한 정보를 요청할 때 시스템은 어떻게 응답해야할까요? 파일 내용을 기반으로 일괄 처리를 하는 시스템이 있는데, 받은 파일이 아무 내용도 없는 빈 파일이라면 어떻게 해야할까요? 등등.. 회사의 다른 소프트웨어들이 이러한 질문들에 대한 답을 이미 가지고 있을 수 있습니다.

고객이 직접 사용하는 소프트웨어를 테스팅하고 있다면, 이 소프트웨어의 참조 모델이 될 수 있는 비슷하거나 연관된 소프트웨어를 찾을 수 있을 것입니다. 특별하게 정의된 표준이 없는 경우라 할지라도, 애플리케이션들이 대부분 공통으로 사용하는 접근 방법이 있는 경우가 많습니다. 비슷하거나 연관 있는 부분이 많아서 비교가 가능한 시스템들을 이미 사용해본 경험이 있는 경우라면 비교가 가능한 시스템들이 특별히 더 큰 도움이 됩니다.
그러므로 테스팅을 시작할 때, 내가 지금 테스팅하려는 소프트웨어와 비교가 가능한 다른 소프트웨어들을 찾아내서 참고하면 훌륭한 가이드 역할을 해줄 것입니다.

추정

몇몇 소프트웨어는 소프트웨어가 어떻게 동작할지 예측하려고 여러 방향으로 시도해보아도, 그 어떤 예측도 허용하지 않는 경우가 있습니다.. 과학이나 금융과 관련된 소프트웨어들은 보통 다양하고 수많은 입력값들을 가지고 굉장히 복잡한 계산을 수행하는데, 이 분야가 너무 복잡하기 떄문에 결괏값을 예상하는 것이 거의 불가능하다고 볼 수 있습니다. 심지어는 그 분야 전문가라 할지라도 계산된 결괏값이 맞는지 아닌지 확인하는 것은 아주 고된일이 되기도 한다.

심지어 시뮬레이션이나 모델링 소프트웨어는 예측하기가 훨씬 더 어렵습니다. 이런 소프트웨어들은 확률에 따라 결괏값을 계산하기 위해 비결정적 알고리즘을 사용하기 때문에, 의도적으로 예측하기 어렵게 만들어졌다고 볼 수 있습니다.
그러나 아래와 같은 방법들을 사용하면 아주 정확한 값보다는 결과의 특징들을 잡아낼 수 있습니다.

범위 한정하기
특성 찾아내기 : 어떤 특정 기능을 테스트할 때, 해당 기능의 특성을 찾아내는 것이 도움이 된다. 예를 들어 0에서 9 사이에 있는 정수 하나를 무작위로 골라주는 함수 를 테스트해야한다고 한다면, 1000회 실행했을 때 0은 한 번도 나오지 않는 반면에 9가 350회나 나왔다면, 문제가 있다고 할 수 있다.
결과를 가지고 반대로 다시 해보기 : 때때로 결과가 정확하다고 말할 수 있는 가장 쉬운 방법은, 나온 결과를 가지고 반대로 계산해보는 것입니다.지도 알고리즘의 경우에는 A라는 장소에서 B라는 장소까지 가는 기로가 반대로 B라는 장소에서 A라는 장소로 가는 길의 각각의 거리가 큰 차이가 없어야한다.
조건 설정하기 : 어떤 시뮬레이터를 테스트한다고 할 때, 해당 값이 제대로 나오고 있는지 확인하는 것은 불가능할 수 있습니다. 각 파라미터들이 어떤 영향을 미치는지 이해하기 위해 각 파라미터를 약간씩 바꾸어 보면서 확인한 후에, 설정 가능한 모든 값을 최댓값으로 바꾸어서 해본다던지, 그런 후에는 다시 최솟값으로 바꾸어서 실행해볼 수 있습니다.
어떤 값들은 최댓값, 어떤 값들은 최솟값으로 바꾸어서 테스트를 해봅니다. 그러면 그 파라미터의 효과가 최대화되며 파라미터가 미치는 영향을 더 손쉽게 확인할 수 있습니다.

순서와 상호 작용 다양하게 바꿔보기

실제 사용자들은 대부분 소프트웨어 애플리케이션을 ㅈ어해진 규칙에 따라 사용하지 않습니다. 소프트웨어 어플리케이션을 만들 때 의도한 사용 순서를 따르지 않고 닥치는 대로 사용하는 경우가 매우 많습니다.
웹 앱이 브라우저의 히스토리 탐색을 지원하는지 안하는지는 상관없이 브라우저의 뒤로가기와 앞으로가기를 무한정으로 반복하는 사용자가 있기도합니다. 메뉴에 실행취소와 재실행이 있으면 최대한 몇 번까지 사용가능한지를 확인하지않고 끊임없이 사용하는 유저도 있습니다. 복사와 붙여넣기를 할 때 프로그램끼리 호환되는지를 확인하지도 않는다.

또한 사용자들은 주어진 제약 사항을 회피하려고 다른 여러 방법들을 사용해보기도 합니다. 때떄로 이용자의 아이들이나 애완동물들도 컴퓨터에 접근할 수 있다. 결과적으로 키를 막 누르거나 순서 없이 무작위로 데이터나 프로그램을 삭제하거나 무엇인가를 설치, 삭제하는 도중에 컴퓨터 전원을 끄는 것과 같이 논리적인 사고를 지닌 사용자에게 서는 절대 이렁나지 않을 것 같은 일들이 일어나기도 합니다.
소프트웨어를 매뉴얼에 따라 사용하든지 아니면 의도하지 않은 방법으로 사용하든지 상관없이 잠재되어있는 심각한 문제를 찾아내려면, 소프트웨어와 상호 작용하는 방법을 바꿔볼 필요가 있습니다.

명사와 동사

테스트를 진행중인 소프트웨어에 점점 더 익숙해지면, 소프트웨어와 상호 작용하는 방법에 있어 특정 습관에 빠질 가능성이 높습니다. 이 습관을 고치기 어려운 두 가지 이유가 있습니다.

내 습관 이외의 다른 방법이 있다는 것 자체를 모르기 때문
내가 어떤 습관을 가지고 있다는 것을 알고 있지만 그것이 너무 편하고 이미 익숙해졌기 떄문

입니다.

자기 습관을 깨뜨릴 수 있는 한 가지 방법은 어떠한 규칙도 따르지 않고 무작위로 모든일을 진행 해보는 것이다.

명사와 동사를 찾아낸다.: 시스템에 대해 명사와 동사로 표현해본다. 가령 이메일을 보내는 프로그램이라면, 프로그램에는 이메일, 첨부, 연락처, 계정, 폴더 와 같이 사물을 뜻하는 명사들이 있고, 이러한 명사들에 대한 동작으로 작성하기, 보내기, 수정하하기, 전달하기 등이 있다. 이러한 것은 꼭 이메일 프로그램이 아니더라도 사용해볼 수 있다.
무작위로 조합하기 : 다음으로는 찾아낸 명사와 동사들을 섞어서 무작위로 문장을 만든 다음에, 그러한 절차로 테스트를 해보는 것이다. 이렇게 함으로써 전혀 예상하지 못한 시나리오를 만들 수 있다.
몇몇 명사와 동사의 조합은, 연락처를 삭제하다 와 같이 완벽하게 의미있는 문장이 되기도 한다. 그러나 헤더를 보관하다 처럼 말도 안되는 의미없는 문장들도 만들어진다. 이렇게 무의미한 문장들은 테스트에 도움이 안될 것 같지만, 사실 테스트를 위한 여러가지 영감을 얻기에는 의미있는 문장보다 이렇게 무의미한 문장들이 더 큰 도움이 된다. 무의미한 문장들을 만나게 되면 상상력을 최대한 발휘해보자.

이러한 무작위로 만들어진 시나리오를 따라 테스트를 진행할 때, 예상하지 못했던 것들에서 힌트를 얻기 위해 주의깊게 살펴봐야 한다는 것을 꼭 기억합시다. 특히 시스템이 꼭 해야하는 것들과 절대 해서는 안되는 것들을 위반하는 경우는 없는지 신경써야합니다.

무작위로 사용하기

GUI가 있는 애플리케이션을 사용하는 방법을 바꿔보는 것은 아주 중요합니다. 마우스를 사용하지 않고 테스트를 진행하면, 화면에 보이는 구성 요소들을 마우스로 클릭했을 때나 마우스 포인터가 올려져 있을 때 잘못 동작한다는 사실을 알아내지 못할 수 있습니다. GUI가 있는 애플리케이션을 테스트할 때 동일한 일을 할 수 있는 여러가지 방법에 주의를 기울어야합니다.. 버튼, 링크, 메뉴, 윈도우 컨트롤과 같이 GUI를 이루는 모든 요소에 주목해야합니다.

테스트를 하면서 한 가지 방법만을 계속 고수하기 보다는, 테스트를 진행하면서 일정 시간이나 장소에 따라 이전과는 다른 방법을 선택해서 사용해보는 것이 큰 도움이 될 것 입니다.

페르소나

페르소나는 우리가 만든 시스템을 사용하는 사용자 유형을 대표하는 가상의 전형적인 인물을 의미합니다. 페르소나는 시스템을 설계할 때 도움이 되는 것 처럼, 시스템을 탐험할 때도 페르소나가 아주 유용하게 사용될 수 있습니다.
페르소나의 입장이 되어서 생각해봅시다. 소프트웨어를 탐험할 때 페르소나의 개인적인 성격, 의도, 관심사 등을 받아들여야합니다. 내가 만든 페르소나가 선택할 것 같은 것을 똑같이 선택하도록 노력해야한다.

소프트웨어를 탐험할 때 실제 사용자 역할을 대신해주는 전형적인 페르소나를 정의함으로써 서로 다른 사용자들이 소프트웨어를 얼마나 다르게 사용하는지에 따라 달라지는 변화들과 관련된 문제들을 더 잘 찾아낼 수 있습니다.

좀 더 나아가서 기술에 대해 전혀 모르는 페르소나를 상정한다고 가정해봅시다. 그런 사람의 입장이 되어서, 기술적인 지식이 전혀 없는 사람의 역할을 하면서 그 사람이 처한 상황을 재미있게 즐겨봅시다.

3~4개의 포스트에 걸쳐 탐색적 테스팅을 진행해야할 때에 알고 있어야할 것들에 대해 기재해봅니다. 위 내용들은 『탐험적 테스팅 : 배우고 통찰하며 개선하는 소프트웨어 테스트』 의 내용을 요약하면서 동시에 저의 경험들을 같이 기재해본 내용들입니다. 좀 더 자세한 내용에 대해 알고싶으신 분들은 해당 책을 읽어보시길 바랍니다.

끝!

ref