이번 포스트에서는 실제 프로덕트가 완성된 후에 탐색적 테스팅을 수행하면서, 버그를 찾아내기 위해 어더한 점들에 대해 신경써야하는지를 기재해봅니다.
아래 포스트들에서 이어집니다.
- https://velog.io/@dahunyoo/탐색적-테스팅-1.-Test-charter란-무엇일까
- https://velog.io/@dahunyoo/탐색적-테스팅-2.-Business-Product-Requirement-에-대해-테스트해보자
탐색적 테스팅을 위한 필수 요소들
Exploratory testing is simultaneous learning, test design, and test execution.
James Bach, p2, 『Exploratory Testing Explained』,
테스트 설계하기
테스트 설계 방법으로는 탐색적 테스팅이라고해서 특별한 무엇인가가 있는 것은 아닙니다. 우리가 평소에 수행하던 경계값 분석, 상태 다이어그램, 동치분할 등의 방법으로 테스트해볼만한 부분들에 대해 설를 수행합니다. 다만, 기존의 테스트와 약간 다른 점은 테스트를 수행하면서 바로바로 떠올리고 적용할 수 있어야한다는 점입니다.
테스트 수행하기
설계한 내용을 바탕으로 테스트를 수행합니다. 테스트를 수행하면서 테스트에 대한 아이디어가 떠오르면 그 즉시 바로 테스트를 수행하는 것이 좋습니다. 다른 테스트와 다르게, 탐색적 테스팅은 무엇인가 아이디어가 떠오르면 그 자리에서 즉시 실행으로 옮긴다는 것 입니다.
주어진 상황에 따라 그 즉시 테스트를 설계하고 수행하면, 해당 상황에서 가장 흥미로운 정보에 따라 테스트 방향을 바꾸어 가며 테스트를 수행합니다.
테스트를 통해 학습하기
테스트를 계속해서 진행하다보면 소프트웨어가 어떻게 동작하는지 대강 알게됩니다. 관찰하면 할수록 계속해서 더 많은 것을 배우게 됩니다.
학습한 내용을 바탕으로 테스트 조정하기
이렇게 테스트를 하면서 얻은 지식을 바탕으로, 어떤 조건들에서 제대로 동작하는지, 하지 않는지를 알아낼 수 있고, 이렇게 알아낸 정보들을 바탕으로 더 어려운 테스트를 위해 이용할 수도 있습니다.
시간 관리
테스트를 하다보면 시간가는 줄 모르고 계속해서 시도하는 경우가 있습니다. 우리가 리소스를 사용하는 것에 대해 구조화하고 체계적으로 하지 않는다면, 목적없이 해매다가 몇시간이나 해매고도 의미있는 정보를 하나도 얻지 못할 수도 있습니다.
이런 경우를 막기 위해, 탐색적 테스트는 세션 기반으로 수행되어야합니다. 즉, 주어진 시간에 대해 몇 번의 세션으로 나누어 구성하는 것이 좋고, 각각의 세션에 대해서는 목적성을 부여하여 어느 부분에 초점을 맞추어야하는지도 설정해야합니다.
이렇게 세션 기반으로 진행하게되면, 각 세션에서 테스트를 수행하면서 무엇을 테스트했고, 어떤 정보를 알게되었는지 메모해놓아야합니다. 세션 종료 이후에 이슈를 리포트한다던지 정보를 공유할 때는 메모해놓은 것을 기반으로 제대로 된 형식을 갖추어 이용합니다.
이슈를 찾아내기 위해 의식해야할 것들 - 1
세심하게 관찰하기
테스팅을 진행할 때, 너무 명백하고 겉으로 드러나는 질문들을 뛰어넘어 더 본질적인 질문들을 던져야한다. 연구 보고서를 테스트한다고 가정해보면, 보고서가 제대로 보이는지만 확인하는 걸로는 충분하지 않습니다. 보고서가 가능한 여러 시나리오에서 정확한 정보를 보여주는지 확인하는 것이 필요합니다. 로그인 기능을 테스트한다면, 로그인을 하고 메세지를 보는 것 이상의 무엇인가를 해야합니다. 즉 로그인 후에 사용자가 접근 권한을 가진 정보만을 열람할 수 있는지 확인해야합니다.
어떤 기능을 테스트하든지 상관없이, 겉으로 드러나는 질문만을 사용하여 테스트할 수도 있고, 또는 더 깊게 파고드는 질문을 던지면서 테스트를 진행할 수 있습니다. 더 가치 있는 더 많은 정보를 얻으려면, 더 나은 정보를 가져다주는 깊게 파고드는 질문을 해야합니다.
찾아내기 힘든 실마리를 찾기 위해 집중하기
때로는 무엇인가 잘못되어있다고 알려주는 단서가 시스템 로그 기록에 있는 에러보다 더 찾아내기 어려울 때가 있습니다. 화면에서는 아주 작아서 찾아보기도 힘든 일부분이 심각한 문제의 전조가 되기도 합니다. 때로는 예상치 못했던 작은 부분이 우리가 사소한 것들을 놓쳐서 큰 문제를 만들지 않도록 주의시켜주기도 합니다. 메모리 사용량의 급격한 증가는 메모리부족 out of memory 문제를 일으켜서 예기치 않게 프로그램을 종료시키기도 합니다.
- 시각 : 하드디스크를 사용하지도 않는데 하드디스크 사용 점멸등이 깜빡거리는지
- 청각 : 하드디스크 사용하는 순간이 아닌데도 하드디스크 소리가 나는지
- 촉각 : 컴퓨터가 열떄문에 뜨거워지지 않는지
테스트 용이성과 보이지 않는 것을 보이게 만들기
테스트 용이성이란, 가시성과 제어성을 의미한다.
즉, 테스트가 쉬운 시스템은 시스템 내부 동작을 볼 수 있게 해주는 높은 가시성과 보이는 것들을 잘 다룰 수 있게 해주는 충분한 제어 포인트를 모두 지원합니다.
가장 큰 걸림돌은 애초부터 모니터링과 제어를 염두에 두지 않고 만들어진 시스템을 모니터링하고 제어하는 방법 입니다.
- 운영체제에서 제공하는 모니터링 프로그램 사용하기.
- 파일 생성/수정/삭제를 하는 흐름을 모니터링하는 프로그램을 사용한다던가
- 네트워크 트래픽을 확인한다.
- 개발자도구를 이용한다던가.
- 데이터베이스라면 추가/갱신/삭제가 되었을 때 자동으로 알려주는 트리거를 만들어서 사용한다.
다시 말해, 테스트 중인 소프트웨어가 특별히 더 테스트하기 힘든 상황에 있다면, 소프트웨어와 관련이 있는 파일 시스템, 네트워크, 관계형 데이터베이스, 운영 체제와 같은 외부 자원들을 모니터링하고 충분히 활용할 수 있어야합니다.
콘솔과 로그
콘솔과 로그는 시스템 내부 동작에 대한 정보를 알려주는 아주 중요한 자원입니다. 아직은 확실하게 에러가 발생하지는 않았지만 에러가 발생 가능한 상황에서 미리 알려주는 조기 경보 시스템 역할도 합니다. 또한 콘솔과 로그는 대체적으로 시스템의 중요한 동작들에 대한 정보도 제공하기 때문에, 콘솔과 로그를 통해 애플리케이션 기능과 구조를 이해하는 데도 도움을 줍니다.
변하는 것들을 담고 있는 변수
테스팅에서 변수는 내가 직접 변경할 수 있거나 소프트웨어가 실행중에 간접적으로 변경될 수 있는 모든 것을 의미한다.
특히나 여러 가지 방법으로 시스템이 하는 일에 영향을 미칠 수 있는 변수들을 찾아내야합니다.
- 금방 눈에 띄는 너무도 명백한 변수
- 놓치기 쉬운 교묘하게 숨어 있는 변수
- 간접적으로만 접근할 수 있는 변수
너무도 명백한 변수
어떤 변수들은 너무도 명백하게 바로 변수임을 알 수 있습니다. 예를 들어, 사용자 화면에 입력 양식이 있고, 그 안에 여러 입력 필드가 있다면 내가 직접 값들을 변경할 수 있기 때문에 이 입력 필드들은 당연히 변수가 됩니다. API를 조작하고 있다면, 이 인터페이스를 통해서 함수들을 호출하면서 넘겨주는 값들도 변수입니다. 사실 이렇게 너무나도 명백한 변수들이 중요하기는 하지만, 일반적으로 이렇게 명백한 변수들은 이미 수없이 많이 테스트되었기 떄문에 관심을 덜 쓰게 된다.
단순하게 값만 바꾸어서 테스트하는 것은 큰 도움이 안될지도 모르지만, 떄때로 어떤 값을 선택하여 테스트하는 지가 매우 중요할 때가 있습니다. 값이 달라지면 특징도 달라지기 때문입니다.
예를 들어 0과 1로 이루어진 이진수를 입력으로 받아서 10진수로 변환해주는 소프트웨어가 있다고 가정해봅시다. 입력값으로 101 또는 011 을 사용하여 테스트를 한다고 하면, 아마도 입력값 두 개 사이에 큰 차이가 없다고 생각할지도 모릅니다. 그러나 101 은 대칭이고, 011 은 대칭이 아닙니다. 대칭으로 이루어진 입력값을 사용하여 테스트를 진행하면, 프로그램이 비트를 반대 방향부터 읽는 문제가 있어도 문제를 알아차리지 못하게 됩니다. 반면에 대칭이 아닌 값을 사용하여 테스트하면 프로그램이 비트를 반대방향부터 읽는 문제가 있는 경우, 즉 2진수 011 의 비트를 오른쪽부터 읽었을 때 올바른 10진수 값인 3이 아닌 비트를 왼쪽에서부터 읽어서 구한 값인 6으로 변환하기 때문에 문제를 발견할 수 있을 것입니다.
교묘하게 숨어 있는 변수
미묘한 변수들의 예시로는, 브라우저의 주소창에 보이는 웹사이트 주소의 파라미터처럼, 사용자가 눈으로 볼 수는 있지만 사용자가 직접 변경하도록 해줄 의도는 아닌 경우 입니다. 웹사이트 주소의 경우, 물음표 뒤에 키/값으로 이루어진 파라미터 변수가 포함되는 경우가 있습니다. 이론상으로는 이런 파라미터 변수들의 값을 직접 변경해서는 안되는데요, 이런 변수의 값들은 보통 링크를 클릭했을 때, 웹 애플리케이션이 알아서 자동으로 설정해줍니다. 하지만 일반 사용자들이 직접 이 파라미터 변수와 값들을 건드려 웹 사이트 주소를 엉마응로 만들어 놓는 경우도 있습니다.
때로는 사용자들이 좋은 의도로 웹 사이트 주소를 변경하는 경우도 있기는 합니다. 리포트에서 다음 페이지로 바로 넘어가고 싶을 떄나, 또는 사용자 화면에서 여기저기 옮겨 다닐 필요 없이 이미 알고 있는 웹페이지로 가고 싶을 때 웹 사이트 주소를 바로 변경하기도 합니다. 또는 예전에 저장해놓은 즐겨찾기를 통해 오래전에 사용되다가 이제는 사용되지 않는 파라미터를 가진 웹 사이트 주소를 사용하기도 합니다. 또 다른 경우로 악의를 품은 사용자가 보안이 취약한 부분을 찾아내려고 웹 사이트 주소의 파라미터를 직접 수정하기도 한다.
이렇게 취약해 보이는 부분을 중심으로 탐험하는 것도 아주 좋은 방법일 것 입니다. 특히 사용자가 임의로 수정했을 때 심각한 문제가 발생할 수 있는 변수들이 있다면, 더욱 신경써서 테스트해야합니다.
사용자의 직접적인 수정을 허용하지 않는 또 다른 예로는, 보이지 않는 기본 설정 정보가 있습니다. 때로는 쿠키나 환경 설정 파일에 사용자를 위해서가 아닌 소프트웨어를 위한 기본 설정 정보들을 저장하기도 한합니다. 사용자가 이 값들을 직접 수정하면, 권한이 없는 시스템이이나 정보를 사용하는 것이 가능해질 수도 있습니다. 그래서 변수를 찾아내려고 테스트를 할 때는 보이지 않는 설정 정보도 고려해야합니다.
간접적으로만 접근이 가능한 변수
대부분의 경우, 가장 중요한 변수들은 깊이 숨겨져 있습니다. 어떤 시점에 로그인하고 있는 사용자 수, 검색결과 개수, 내가 원하는 조건에 충족하는 경우 아니면 충족하지 못하는 경우 등과 같이 보통 간접적으로만 얻을 수 있는 것들이 대부분입니다.
이런 변수들은 알아차리기가 어려워서 놓치기 아주 쉽지만, 찾아내서 잘 활용한다면 시스템에 아주 결정적이고 중요한 정보를 알아내는 데 큰 도움이 된다.
변수 찾아내기
셀 수 있는 것들
모든 시스템은 우리가 셀 수 있는 무엇인가 를 가지고 있습니다. 셀 수 있는 값을 가지는 변수들은 간과되기 쉽고 문제가 너무 늦게서야 발견되기 때문에 찾아내기 쉽지 않은 변수이긴 합니다.
시스템에 있는 셀 수 있는 값을 가지는 변수들 중에서 좀 더 자세하게 살펴보고 싶은 변수가 있다면, 변수가 가질 수 있는 값을 기준으로 다음과 같은 기법들을 사용하여 테스트해볼 수 있습니다.
- 0, 1, 1 이상
- 극대 : 소프트웨어가 처리할 수 있는 것보다 더 많은 입력값을 요청.
- 극 소수 : 소프트웨어가 보통 입력값으로 기대하고 있는 것보다 더 작은 수의 입력값이나 더 적은 요청으로 테스트.
0 이라는 숫자는 그 자체만으로도 우리가 꼭 지켜봐야하는 숫자입니다. 보통 입력값으로 하나가 아닌 여러 아이템이 세트로 필요한 소프트웨어의 경우, 입력값으로 0개의 아이템이 올 때 제대로 처리하지 못하는 경우가 많습니다.
상대적 위치
테스트를 진행하는 대상이 상대적인 위치를 가지고 있다면 처음, 중간, 끝 부분을 각각 테스트하는 기법을 사용할 수 있습니다. 하나의 예시로, 텍스트 편집기를 테스트 할 때, 붙여넣기 기능을 테스트하려고 문장을 복사하고 붙여넣기를 했는데 줄의 처음 부분이나 중간 부분에서는 아무런 문제가 없었는데, 이상하게도 줄의 맨 끝에서 붙여넣기를 하면 문제가 발생한다던지..
리스트에 있는 데이터를 보여주는 또 다른 시스템에서는 리스트 마지막에 있는 아이템을 삭제하려고만 하면 실패하할 수도 있습니다.. 리스트에 있는 첫 번째 아이템이나 리스트 중간에 있는 다른 아이템은 삭제가 가능했지만, 제일 마지막에 있는 데이터를 삭제할 때에는 문제가 발생해 삭제에 실패할 수도 있습니다.
아이템이 다른 아이템들과 비교했을 때 상대적으로 올바른 위치에 있는지 알아보기 위해 아이템 위치를 옮겨가며 탐혐하는 방법도 있습니다. 특히, 어떤 컴포넌트들의 경우에 어떤 컴포넌트가 앞에서보이고, 어떤 컴포넌트가 뒤에서 보일지를 결정하는 z-index라는 값이 있습니다. 이 값을 변경해가면서 의도한대로 정확하게 보이는지를 확인할 수 있습니다. 리스트가 자동으로 정렬되는지 확인하려면 리스트 처음이나 맨 마지막에 들어가야하는 아이템을 추가해 테스트하는 것이 좋을 것 입니다..
아이템들을 정렬할 때 특히나 조심해야하는 경우는 숫자의 크기 순서로 정렬되어야 하는데 알파벳 순서로 정렬되는 경우이기도 합니다.
파일과 저장 공간
보통 시스템들은 어디에서 파일이나 데이터를 찾아야 하는지 장소가 미리 정해져 있습니다. 파일 시스템에 있는 파일을 찾기도 하고, 하드 디스크 드라이브 이름이나 식별자를 이용하기도 합니다. 필요한 자원들이 실제로 있는 곳의 위치가 바뀌는 경우라면, 이 변수도 충분히 테스트해볼 만한 가치가 있습니다.
위치를 변경하는 것만으로도 예상하지 못했던 결과를 만나기도 합니다. 분산 시스템 환경에서 어떤 자원들을 방화벽 뒤로 이동시키면, 어떤 시스템은 그 자원들을 이용하지 못한다는 사실을 발견할 수도 있습니다. 어떤 설치 프로그램들은 설치 경로를 직접 지정하는 경우에 문제를 일으키기도 합니다. 아니면 제거 프로그램이 문제를 일으킬 수도 있습니다. 기본적으로 주어지는 하드디스크 위치가 아닌 다른 곳에 설치하려고 하면 문제가 발생해서 설치를 진행할 수 없는 설치 프로그램도 있기도 합니다.
지리적 위치
소프트웨어는 시간대, 우편주소, 우편번호, 해발고도 등 지리적 위치와 관련된 정보를 가지는 경우가 많습니다. 주소나 지리적 좌표를 바꾸어가면서 테스트를 하면, 시스템이 어떤 특정 위치에서만 원활하게 동작하는 경우를 쉽게 만날 수 있습니다.
지리적으로 매우 먼 위치까지 경로를 찾을 수 있는지 확인한다던지, 서로 다른 시간대에 있는 사용자들이 동일한 시스템에서 작업을 하는 경우에, 시스템에 있는 어떤 정보들은 수정된 시간이 처음 만들어진 시간보다 더 이른 시간대로 설정되진 않는지 체크해 볼 수도 있습니다.
형식
날짜, 우편 주소, 파일 경로, 인터넷 주소, 특정 파일의 내용, 메세지 같은 많은 것이 형식이 이미 정해져 있습니다. 하지만 어떤 경우에는 보기에는 달라 보여도 의미가 같은 경우가 있습니다.
- 미국의 전화번호 : (866)867-5309 , 866-867-5309 …
- 우편 번호 형식 : 다섯숫자 / 여섯숫자 / 다섯자리-네자리 / 영어를 섞어쓰는 우편번호
- 날짜 형식 : dd/mm/YY, YYYY/mm/dd, YYYY-mm-ddd …
- 파일 확장자 : 같은 사진파일이나
jpg,png,gif등등
유효하지 않은 형식도 항상 눈여겨볼 필요가 있습니다. 데이터 종류에 따라 특정 상황에서는 유효하지 않은 경우도 있다.
- 나이가 마이너스 라던지
- 2월 29일 이라던지
파일 내용을 읽어서 분석하는 시스템의 경우에는, 파일 내용에 변경을 가함으로써 예상하지 못했던 형식을 사용하여 테스트할 수도 있을 것 입니다.
- 아무 의미없는 임의의 문자나 단어들을 파일 곳곳에 추가해서 테스트한다던지
- 빈 파일을 이용한다던지
크기
모든 파일은 크기 라는 속성이 있습니다. 소프트웨어가 파일을 읽어서 어떤 작업을 하는 경우라면, 빈 파일이나 아주 크기가 큰 파일을 이용해 탐험을 해보는 것이 좋습니다. 비슷한 상황으로는 소프트웨어가 데이터베이스에 있는 데이터를 다루는 경우라면, 거의 비어있는 테스트용 데이터베이스나, 수많은 데이터가 들어 있는 아주 큰 데이터베이스를 이용하여 테스트를 진행해보는 것도 방법입니다.
사진은 높이와 너비가 있는데, 때떄로 시스템이 미리 정해진 높이와 너비에 맞추려고 이미지 비율을 변경하거나 이미지의 일정 부분을 잘라내기도 합니다. 때문에 높이와 너비가 다른 여러 파일 및 크기가 다른 여러 파일을 가지고 탐험을 해봅시다.
하드웨어인 하드 디스크나 메모리 크기도 문제를 야기할 수 있습니다. 설치 프로그램들은 대부분 설치를 시작하기 전에 디스크 드라이브 크기를 먼저 확인합니다. 어떤 프로그램들은 메모리 사용 가능량을 확인하기도 합니다. 어떤 경우에는 컴퓨터에 추가 메모리가 설치되어있는 경우에만 발생하는 버그가 있을 수 있습니다.
대다수 소프트웨어는 받아들일 수 있는 크기의 최대치를 정할 때, 보통 2의 제곱을 많이 사용합니다. 예를 들어, 보통 텍스트 필드에 입력할 수 있는 최대 문자 수는 2의 8제곱인 256문자입니다. 크기에 관해 탐험을 할 떄에는 2의 제곱 근처를 탐험해보는 것도 좋은 방법입니다.
깊이
계층과 관련이 있는 것들은 깊이 depth 라는 특성이 있습니다. XML 데이터 요소는 얼마든지 더 깊은 노드로 사용하는 것이 가능하고, 파일 시스템에서 파일도 디렉터리를 만들어 더 깊은 곳에 저장할 수 있습니다. 심지어 수식과 괄호를 사용하여 단계가 더 깊어지도록 할 수도 있습니다.
동굴을 탐험하는 것처럼 더 많고 깊은 단계를 만들어 탐험을 하면 예상하지 못했던 것들이나 어떤 경우에는 에러도 발견할 수 있습니다.
특정 버전의 엑셀 프로그램도 부동 소수점을 가지는 숫자를 계산할 때, 괄호가 세 개 또는 네 개로 중첩되어있는 경우에만 수식을 잘못 계산하는 버그가 있기도 했습니다.
타이밍, 빈도, 지속시간
타이밍과 사용자행동은 항상 변할 수 밖에 없습니다. 타이밍과 사용자 행동이 계속 변하기 때문에 시간 초과, 인터럽션, 에러 같은 결과를 야기하기도 합니다.
사실 빈도도 타이밍의 한 측면입니다. 어떤 동작을 자주 그리고 반복적으로 해봅시다. 예를 들어 트위터에서는 새로고침을 일정 횟수 이상, 반복적으로 수행하면 정상페이지 대신에 에러페이지를 보여줍니다. 트위터의 동작은 예상된 결과이지만, 트위터와 연동하는 애플리케이션들 중에는 이러한 트위터의 동작에 대해 대응하지 못하는 애플리케이션이 있을 수 있습니다.
지속시간 또한 타이밍의 또 다른 측면으로 볼 수 있다. 파일이나 윈도우를 오랜 시간 동안 열어놓는 것 처럼, 어떤 동작의 지속 시간을 바꿔가면서 테스트를 해봅시다. 퇴근 전에 프로그램을 켜놓은 채로 퇴근하고, 다음날 출근해서 확인해보는 것도 하나의 방법일 것 입니다.
입력과 사용법
심지어는 데이터를 입력하는 방법이나 소프트웨어를 다루는 방법도 문제를 일으킬 수 있는 변수가 될 수 있습니다. 그래픽 사용자 인터페이스를 가지고 있는 소프트웨어를 테스트하고 있다면, 데이터를 직접 입력해보기도 하고, 복사와 붙여넣기 또는 드래그 앤 드롭을 통해 테스트를 진행해볼 수 있습니다.
이렇게 여러 가지 방법을 가지고 동일한 입력 테스트를 진행하는 것이 큰 의미가 없어 보이겠지만, 떄로는 차이를 발견하기도 합니다.. 입력값에 대한 유효성 검사를 하는 경우에 어떤 방법에서는 입력값에 대한 유효성 검사가 정확하게 실행되는 반면, 또 다른 방법의 입력에서는 유효성 검사를 하지 않고 넘어가는 경우도 있습니다.
소프트웨어를 사용할 때 단축키를 사용하는 사용자나 혹은 마우스를 사용하는 사용자간에 차이가 있을 수도 있습니다. 데이터를 입력할 때 사용하는 방법에 따라 그 결과가 달라질 수 있는 것 처럼, 소프트웨어를 사용하는 방법에 따라 소프트웨어 동작이 달라질 수 있고, 이것이 큰 차이를 만들기도 합니다.
ref
- 엘리자베스 헨드릭슨, 『탐험적 테스팅 : 배우고 통찰하며 개선하는 소프트웨어 테스트』, 오광신 옮김, 인사이트(2014)
