들어가며
안녕하세요. LINE Technology Vietnam에서 일하고 있는 Thi입니다. 이번 글에서는 테스트를 최적화해야 하는 이유를 알아보고 테스트를 최적화하는 몇 가지 방법에 대해 살펴보겠습니다. 글은 아래와 같은 순서로 진행됩니다.
테스트를 최적화해야 하는 이유
먼저 아래 질문들을 함께 살펴보며 테스트를 최적화해야 하는 이유를 생각해 보겠습니다.
- 사용자는 무엇을 원하는가
- 우리는 무엇을 하고 있는가
- 우리는 무엇을 할 수 있는가
사용자는 무엇을 원하는가
사용자는 무엇을 원할까요. 답은 간단합니다. 사용자는 완벽한 앱을 원합니다. 사용자는 앱에서 작은 실수만 발견해도 바로 떠나버립니다. 이 글을 읽고 계신 분들도 맞춤법 오류를 발견했거나 성능이 좋지 않았거나 사용하기 불편해서 다시 사용하고 싶지 않았던 앱이 하나쯤은 있었을 겁니다.
반면 앱을 개발하는 입장에서는 사용자들이 가능한 한 오랫동안 우리 앱을 사용해 주기를 바랍니다. 그러기 위해서 우리는 완벽한 앱을 만들어야 합니다.
우리는 무엇을 하고 있는가
우리는 사용자의 기대를 충족시키기 위해, 사용자가 떠나가지 않게 하기 위해 많은 것을 해야 합니다. 가능한 한 많은 기기를 지원해야 하고 서로 많은 것이 다른 여러 OS의 각기 다른 브라우저를 지원해야 합니다. 그런데 테스터 인원은 한정돼 있고 출시일은 정해져 있기 때문에 늘 시간이 부족합니다.
여기에 작업을 시작할 때 몇 가지 불편한 조건이 추가됩니다. 예를 들어, 배포는 정해진 시작 일자에 되어 있지 않거나 그날 자정 즈음에나 진행됩니다. 예상했던 것보다 훨씬 많은 버그가 나타나기도 하고, 그 많은 버그들이 처리해도 다시 나타나고, 또 처리해도 다시 나타나고, 여러 번 다시 나타나기도 합니다. 이런 악조건들은 테스트하고 확인하고 회귀 테스트를 진행하는 데에 많은 시간이 걸리게 만듭니다. 이렇듯 늘 할 일은 많고 여러 악조건이 겹치지만, 우리는 이를 극복해야 합니다.
우리는 무엇을 할 수 있는가
제한된 자원과 촉박한 일정 속에서 가능한 한 최상의 품질을 달성하기 위해서 우리는 무엇을 할 수 있을까요. 프로젝트 관점에서 보면 스펙과 코드는 물론 프로세스에서 테스트까지 모든 것을 최적화할 수 있는데요. 이번 글에서는 테스트를 최적화하는 것에 집중하겠습니다. 다들 알고 계시겠지만, 테스트에 필요한 자원의 대부분은 테스트 케이스를 준비하고 테스트를 실행하는 데에 들어갑니다. 여기서 테스트 실행에 소요되는 자원과 시간은 테스트 케이스의 질과 양에 좌우되기 때문에 테스트 케이스를 최적화하면 자연스럽게 테스트 실행을 최적화할 수 있습니다.
이제 테스트 케이스를 최적화할 수 있는 몇 가지 방법에 대해 살펴보려는데요. 먼저 테스트 설계에 대해 살펴본 뒤, 테스트 설계만으로는 채울 수 없는 부분을 보완하기 위해 LINE에서 적용하고 있는 세 가지 방안을 공유하겠습니다.
테스트 설계
테스트 설계에 대해 살펴보기 전에 왜 테스트를 설계해야 하는지 먼저 알아보겠습니다.
왜 테스트를 설계해야 하는가
테스트 케이스를 만드는 방식에는 두 가지가 있습니다. 첫 번째는 각자의 경험에 기반해서 만드는 방식입니다. 이 방식은 테스터가 보유한 시스템과 도메인에 대한 지식과 테스트 케이스를 작성하는 스킬에 의존합니다. 두 번째는 테스트 케이스 설계 기법에 기반한 방식입니다. 설계 기법에는 각 개인보다 훨씬 많은 사람들의 경험이 집약돼 있어서 설계 기법을 적용해 테스트 케이스를 작성하면 각자의 경험에 기반한 것보다 더 많은 도메인과 프로젝트에 적용할 수 있습니다. 같은 노력으로 더 큰 영역을 커버할 수 있는 것입니다. 따라서 각자의 제한된 경험에 의지하지 않고 설계 기법을 적용하면 테스트 케이스를 좀 더 효율적으로 작성할 수 있습니다.
건축을 예로 들어 보겠습니다. 아래 이미지 속 두 건물은 몇몇이 그들만의 경험에 기반해 직접 지은 건물입니다. 이런 집을 스스로 지은 사람은 훌륭한 건축가임에 분명합니다만, 이런 작업은 아무나 할 수 있는 것은 아닙니다. 또한 몇몇 가족 정도가 살기에 적합해 보이는 이 집을 짓기까지는 6년이라는 상당히 긴 시간이 걸렸다고 합니다.
이번엔 다른 건물을 보겠습니다. 아래 이미지의 왼쪽 건물은 현재까지 베트남에서 가장 높은 빌딩입니다. 오른쪽 건물은 왼쪽같이 크고 높지는 않지만 아주 근사한 외관을 갖추었습니다.
위와 같은 건물은 우리 자신의 경험만으로는 지을 수 없습니다. 기술적으로, 또한 예술적으로 완벽한 설계가 필요합니다. 더 크거나 높은 빌딩을 지어야 할 때, 외관을 좀 더 근사하게 만들면서 건물의 기능을 최적화해야 할 때, 그러면서 그 작업을 짧은 시간 내에 끝내야 할 때는 우리 자신의 경험만으로는 부족합니다. 제한적인 경험으로는 그런 건물을 지을 수 없습니다.
소프트웨어도 마찬가지입니다. 아주 간단한 소프트웨어를 시간 제약 없이 만드는 것은 소수의 경험만으로도 가능하겠지만, 복잡한 기능을 갖추고 성능에도 신경 써야 하는 소프트웨어를 제한된 시간 내에 만들어야 할 때에는 설계가 필요합니다. 이런 설계는 개발할 때뿐 아니라 유지하고 관리할 때도 필요합니다. 버그를 수정하거나 기능을 변경할 때 해당 소프트웨어에 기반이 되는 설계가 없다면 변경 영향을 예측하고 버그를 다시 확인하고 회귀 테스트를 수행하는 데에 훨씬 많은 시간이 필요하고 이는 자원과 시간의 낭비로 연결될 것입니다. 테스트 케이스도 마찬가지입니다. 테스트 케이스에 설계가 없다면 이해하기 어렵고 유지 관리가 어려우며, 이 역시 시간과 자원의 낭비로 연결될 것입니다. 적절한 설계가 없다면 아무리 테스트 케이스가 많다고 하더라도 실제로 커버리지가 얼마나 되는지 쉽게 알 수 없으며, 설계가 적용된 더 적은 수의 테스트 케이스보다 오히려 커버리지가 낮을 수도 있습니다. 이런 이유로 우리는 설계에 기반한 테스트 케이스 최적화에 대해 진지하게 고민하고 시도해 봐야 합니다.
언제, 어떤 설계 기법을 적용할 것인가
적절한 설계 기법을 효율적으로 적용하는 것은 쉬운 일이 아닙니다. 언제, 어떤 설계 기법을 적용할 것인가에 대해서 아직 저희도 '이것이 정답이다'라고 할 만한 답을 발견하지는 못했지만 여러 프로젝트를 경험하며 쌓아 온 실무 사례를 몇 가지 소개하겠습니다.
EP-BVA 적용 사례
저희는 입력값이 많지 않은 간단한 페이지에는 EP-BVA1 기법을 적용하고 있습니다. 아래 왼쪽 화면을 보시겠습니다. 댓글과 닉네임을 입력할 수 있고 1부터 5까지 별점을 매길 수 있는 아주 간단한 화면입니다.
이 화면에 EP-BVA 기법을 적용하면 9개의 테스트 케이스가 나옵니다. 만약 이 페이지에서 가능한 모든 조합을 테스트한다면 100개의 테스트 케이스 조합이 나올 수 있는데요. 그렇게 되면 테스트하는 데 시간이 많이 걸려서 다른 중요한 화면이나 기능을 놓칠 수 있습니다. 현재 간단한 페이지에는 BVA를 사용하고 있고 그것으로 충분하다고 생각합니다.
페어와이즈 적용 사례
입력과 출력이 많은 페이지를 테스트할 때는 페어와이즈(pairwise)2 기법을 사용했습니다. 관련해서 두 가지 사례를 소개하겠습니다.
Fortune 프로젝트
먼저 Fortune 프로젝트(LINE 占い(일본어))입니다. LINE 占い는 점술가와 사용자를 연결해 주는 서비스로 사용자는 전문가를 선택해 운세를 확인할 수 있습니다.
Fortune 시스템의 아웃풋은 여러 조건과 값에 영향을 받습니다. 예를 들어 사용자들의 순위(기본, 백금, 골드, 다이아몬드)는 가격에 영향을 미칩니다. 사용자는 프로모션 패널을 통해 무료 티켓을 받을 수도 있고 이후 티켓을 더 구매하거나 티켓을 구매하는 대신 신용 카드로 비용을 지불할 수도 있습니다. 사용자는 점술가에게 컨설팅을 받은 후 리뷰를 남길 수도 있고 그렇지 않을 수도 있습니다. 컨설팅 시간은 10분 이내가 될 수도 있고 그 이상으로 매우 긴 시간이 될 수도 있습니다. 이런 조건을 생각해 볼 때 만약 설계 없이 테스트 케이스를 작성한다면 얼마나 많은 케이스가 도출될지 예측할 수 없습니다. 가능한 모든 조합을 계산해 보면 총 테스트 케이스는 1000개가 넘는데요. 페어와이즈 기법을 적용하니 20개 정도로 줄일 수 있었습니다. 무려 1000개를 줄인 것입니다. 또한 단순히 숫자만 줄인 것이 아니라 테스트 커버리지도 높았고 추적하기도 쉬웠습니다.
HOP 프로젝트
페어와이즈 기법을 사용한 두 번째 사례는 HOP 프로젝트입니다. HOP(일본어)은 LINE의 소셜 그래프를 이용해 파트너를 찾아 매칭해 주는 앱입니다.
HOP 프로젝트에서는 LINE OA 메시지를 확인할 필요가 있었습니다. OA 메시지는 대상 사용자와 메시지 유형 등 여러 설정에 따라 서로 다른 콘텐츠가 포함되며 각기 다르게 표시될 수 있는데요. 이 프로젝트 역시 테스트 케이스에 설계를 적용하지 않았다면 얼마나 많은 테스트 케이스가 도출될지 알 수 없었습니다. 모든 조합을 고려한다면 252개의 테스트 케이스를 도출할 수 있었는데요. 페어와이즈 기법을 적용하니 30개의 테스트 케이스로 커버할 수 있었습니다.
상태 전이(state transition) 적용 사례
시스템의 흐름을 테스트할 때는 상태 전이 기법3을 사용했습니다. 보유한 테스트 역량으로 감당하기 어려운 긴 비즈니스 흐름이나 이벤트 배열을 테스트할 때 사용하는 기법인데요. 이 기법을 적용한 'Support Plan' 프로젝트 사례를 소개하겠습니다.
Support Plan 프로젝트는 LINE Fortune 프로젝트의 서브 프로젝트로, 점술가가 좀 더 효과적으로 고객을 만날 수 있도록 매달 구입할 수 있는 마케팅 플랜을 제공하는 것이 목표입니다. 예를 들어 마케팅 플랜을 구입하려는 점술가가 있다고 가정해 보겠습니다. 점술가는 프로모션 패널을 통해 정상 가격보다 저렴한 가격으로 마케팅 플랜을 구입할 수 있습니다. 이 가격은 6개월 동안 유지되며, 그 이후부터는 다시 정상 가격이 적용됩니다. 점술가는 수동으로 결제를 취소할 수 있고, 만약 구입할 때 사용한 신용 카드에 문제가 발생하면 자동으로 결제가 취소됩니다.
이와 같은 프로젝트의 테스트 케이스를 작성하면서 설계 기법을 적용하지 않는다면 도출된 테스트 케이스의 커버리지를 예측하는 것이 매우 어렵습니다. 그렇다고 모든 조합을 테스트하려면 테스트하는 데에만 2주 이상이 걸릴 수 있는데요. 상태 전이 기법을 적용해서 문제를 해결할 수 있었습니다.
아래는 Support Plan 프로젝트에 상태 전이 기법을 적용해 도출한 테스트 케이스입니다. 처음엔 아래 이미지의 첫 번째 표와 같이 6개의 테스트 케이스를 도출했고, 이를 개선해 제한된 시간 내에 복잡한 프로젝트의 로직을 테스트하기에 적당하다고 판단한 17개의 테스트 케이스를 도출해 사용했습니다.
테스트 설계와 함께 적용하면 좋은 세 가지
지금까지 테스트를 설계하는 것에 대해 살펴보았는데요. 사실 좋은 테스트 케이스를 만들려면 설계하는 것만으로는 충분하지 않습니다. 그것만으로는 달성할 수 없는 측면이 있습니다. 이에 LINE에서는 설계하는 것과 더불어 공통 테스트 케이스를 만들어 재사용하고, 테스트 케이스를 구조화하며, 테스트 케이스를 분할하고 있는데요. 각각에 대해 좀 더 자세하게 말씀드리겠습니다.
공통 테스트 케이스 재사용
현재 저희는 다른 프로젝트에 재사용할 수 있는 공통 테스트 케이스를 약 800개 정도 정리해 놓고 있습니다. 이와 같이 공통 테스트 케이스를 정리해 놓으면 테스트 케이스를 리뷰하고 자가 테스트하고 체크 리스트를 생성하는 데 필요한 시간을 절약할 수 있습니다.
아래 왼쪽은 '푸시 알림'에 대한 일반적인 테스트 케이스를 정리해 놓은 것인데요. 새로운 프로젝트에서 푸시 알림에 대해 테스트할 필요가 있으면 이 테스트 케이스를 가져가 사용하고 있습니다. 또한 오른쪽은 'CSV 내보내기(export)'에 대한 공통 테스트 케이스입니다. 역시 'CSV 내보내기'에 대한 테스트가 필요할 때는 이것을 가져가 사용하면 됩니다.
저희는 공통 테스트 케이스 목록을 지속적으로 관리하며 새로운 테스트 케이스가 도출되면 꾸준히 목록을 업데이트하고 있습니다.
테스트 케이스 구조화
두 번째로 말씀드리고 싶은 것은 전체 테스트 케이스를 구조화하는 것입니다. 테스트 케이스를 구조화하면 리뷰 시간을 절약할 수 있고 테스트 케이스를 업데이트하는 시간도 줄일 수 있습니다.
예를 들어, 먼저 일반적으로 사용자가 UI에서 겪을 수 있는 중대한 불편함이 없는지 확인하기 위한 테스트 케이스를 모아 놓고, 다음으로 주요 기능을 확인하기 위한 테스트 케이스, 그다음 내비게이션이나 UX 혹은 특정 요구 사항을 검증하기 위한 테스트 케이스, 마지막으로 경험에 비춰볼 때 위험한 부분이나 버그를 일으킬 것으로 예상되는 테스트 케이스를 묶어서 배치하는 것입니다.
이와 같이 테스트 케이스를 구조화해놓으면 리뷰어가 전체 테스트 케이스의 설계 구조와 아이디어를 더 잘 이해할 수 있어서 리뷰 시간을 단축할 수 있습니다. 또한 테스터가 업데이트해야 할 위치와 업데이트 대상을 빠르게 파악할 수 있어서 테스트 케이스를 업데이트하는 데 걸리는 시간도 줄어들고 테스트를 실행하는 데 걸리는 시간도 절약할 수 있습니다. 아래는 저희가 만든 테스트 케이스 구조의 예시입니다.
테스트 케이스 분할
마지막으로 테스트 케이스를 분할하는 것입니다. 간혹 시간을 절약하기 위해 작은 테스트 케이스를 큰 테스트 케이스에 결합해야겠다고 생각할 수 있는데요. 그렇게 결합하면 처음에는 진행 속도가 빠른 듯 보이지만 결국 나중에 문제가 발생하게 됩니다. 예를 들어 몇몇 테스트 케이스에서 테스터가 검증해야 할 여러 시나리오를 전부 확인하지 못할 수도 있고, 아주 작은 첫 번째 단계의 실패가 전체 테스트 케이스의 실패로 이어지기 때문에 버그를 확인하기 위해 아주 긴 케이스를 다시 실행해야 하는 경우가 발생할 수도 있습니다. 또한 회귀 테스트를 진행할 때 실제 위험이 되는 건 몇몇 단계일 뿐일 때도 긴 테스트 케이스를 전부 실행해야 할 수도 있습니다. 테스트 케이스를 분할하면 이런 문제가 발생하는 것을 방지할 수 있을 뿐만 아니라 테스트 보고서의 데이터도 더욱 명확해지며 결과를 추정하기에도 더 좋습니다.
마치며
지금까지 테스트를 최적화하는 방법에 대해 공유드렸습니다. 간략히 요약하자면, 첫 번째는 테스트 케이스를 작성할 때 적절한 설계 기법을 사용하는 것이고, 두 번째는 공통 테스트 케이스를 재사용하는 것이며, 세 번째는 테스트 케이스 구조를 관리하는 것이고, 마지막으로 테스트 케이스를 적절히 분류하는 것입니다.
테스트를 최적화하면 제한된 자원과 시간으로도 최고의 소프트웨어 품질을 얻을 수 있습니다. 테스트 케이스와 관련해 어려움을 겪고 계시다면 이번 글에서 소개 드린 방법을 한 번 고려해 보시기를 바라며, 이만 글을 마치겠습니다. 긴 글 읽어주셔서 감사합니다.
- EP-BVA: EP는 동등 분할(Equivalence Partitioning) 기법으로 프로그램의 입력값과 출력값이 특정 그룹으로 돼 있고 분류된 그룹의 값들을 시스템에서 동일하게 취급한다는 특성을 이용한 테스트 기법입니다. BVA는 경곗값 분석(Boundary Value Analysis) 기법으로 동등 분할의 확장 형태입니다.
- 페어와이즈(pairwise): 가능한 모든 입력값의 조합을 테스트하는 대신 짝들의 조합으로 테스트하는 방법입니다.
- 상태 전이(state transition): 어떤 이벤트가 발생했을 때 테스트 대상이 다른 상태로 전이되는 경우의 수를 테스트하는 방법입니다.