요약 - 버그 분류를 사용하여 더 나은 소프트웨어 테스트 설계하기 by Stahl

출처: 웹문서 Using Bug Taxonomy to Design Better Software Tests by Michael Stahl, 2017년 10월

https://www.stickyminds.com/article/using-bug-taxonomy-design-better-software-tests

 

 

---

 

R&D 부서의 일원으로서 우리 팀은 신제품을 개발하는 일을 한다. R&D가 “혁신과 발견”이라는 후광을 가지고 있을지라도, R&D 부서에 근무하시는 분들은 아시겠지만 실제로 새로운 것을 개발하는 업무는 상대적으로 드물다. 뭔가 새로운 것을 개발한다 하더라도, 실제 작업이 시작되면 대부분은 이미 우리가 했던 작업을 다시 하는 것을 의미한다.

 

예를 들어 세계 기아 문제를 해결하는 새로운 임베디드 시스템을 개발한다고 하자. 이 최종 제품은 2.0 버전에서 오존층 파괴 문제를 해결하기 위해 현장 업그레이드가 가능해야 하므로 "FW 업데이트" 기능이 필요하다. 이전에도 이런 일을 해본 적이 있지 않은가? 물론이다! 모든 임베디드 시스템에는 이 기능이 있다. 그래서 우리는 또다시 같은 도전과 (아쉽게도) 같은 버그에 직면하게 된다. 설치 프로그램, 데이터베이스 모듈 등도 마찬가지이다. 우리 팀이 이전에 비슷한 것을 개발한 적이 없다면, 다른 팀이 비슷한 것을 개발하고 테스트 케이스를 개발했을 것이다. 그런데도 우리는 또다시 바퀴를 새롭게 발명하고 있는 셈이다.

 

이것은 중복적이고 비효율적이다. 프로젝트 간, 베테랑 엔지니어와 신입 엔지니어 간, 조직 내 팀 간, 심지어 서로 다른 회사 간에도 축적된 지식을 전달할 수 있는 방법이 있어야 한다.

 

 

버그 분류(Bug Taxonomy)

테스팅에 대한 지식을 공유하는 한 가지 방법은 버그 분류를 활용하는 것이다. 분류라는 용어에서 알 수 있듯이, 일반적인 아이디어는 특징에 대한 카테고리를 정의하고 각 카테고리에서 발생할 수 있는 버그 리스트를 수집하는 것이다.

 

이 리스트는 경험이 많은 테스터에게 무엇을 테스트할지 더 많은 아이디어를 제공하고, 경험이 부족한 테스터에게 테스트가 필요한 항목들을 제공하여 돕는다. 테스트가 필요하다는 것을 인지하지 못했을 수 있는 제품 측면들(예: 성능 및 사용성의 특정 측면들)을 제시하며, 테스트 케이스의 완전성을 평가하는 데 사용될 수 있다.

 

예를 들어, 다음은 Cem Kaner, Hung Q. Nguyen, Jack Falk가 쓴 저서 『Testing Computer Software』에서 발췌한 버그 리스트의 일부이다.

 

성능

• 느린 프로그램(Slow program)
• 느린 에코(Slow echoing)
• 낮은 응답성(Poor responsiveness)
• 미리 입력 기능 없음(No type-ahead)
• 작업 시간이 오래 걸릴 것이라는 경고 없음
• 진행 상황 보고가 없음(No progress reports)
• 시간 초과 문제(Problems with time-outs)

 

이 항목들 중 일부는 테스트가 필요한 명백한 기능이지만, 다른 일부는 우리가 테스트 과정에서 놓쳤을 수 있는 테스트 아이디어를 떠올리게 할 수 있다.

 

예를 들어, "작업에 오랜 시간이 걸릴 것이라는 경고가 없음"이라는 버그는 여러 가지 검증 아이디어를 촉발한다. 우리 제품에 시간이 오래 걸릴 수 있는 기능이 있는가? 어떤 조건에서 그런가? 우리가 진행 상황 추적 기능을 제공하는가? 이 추적이 정확한가? 이는 또한 비슷한 기능에 대한 생각도 촉발한다. 매우 짧은 시간이 걸리는 것들에 대한 진행 상황 추적을 제공하는가? 윈도우창이 잠깐 나타났다 빠르게 사라지면서 사용자가 방금 무슨 일이 일어났는지 궁금해하는 경우가 있는가?

 

또 다른 흥미로운 점은 이 리스트에 있는 아이디어 중 일부에는 만료일이 있다는 것이다. 예를 들어, 미리 입력 기능은 1세대 컴퓨터 애플리케이션에 필수 기능이었는 데, 당시에는 타이핑 속도가 빠른 사람이 화면 업데이트 속도를 쉽게 넘어설 수 있었다. 하지만 최신 CPU에서는 일반적으로 이러한 문제가 발생하지 않는다.

 

 

나만의 버그 분류 만들기

내가 여러 버그 분류 리스트를 알고 있지만, 실제로 사용해 본 적은 없다. 시도는 했지만 큰 노력은 하지 않았음을 인정한다. 그래서 한편으로는 분류 리스트가 좋은 아이디어라고 생각하지만, 다른 한편으로는 사용하기 불편할 수도 있다고 본다.

 

리스트를 작성한 사람의 사고방식과 생각이 여러분의 그것과 꼭 같은 것은 아니다. 그 결과, 특정 카테고리에 속할 것으로 기대했던 항목이 이해가 되지 않는 카테고리에 표시되기도 한다. 위 리스트의 예를 들어 보겠다. 리스트 개발자는 "진행 상황 보고 없음"을 "성능(Performance)" 카테고리 아래에 두기로 했다. 저자는 이 항목이 "사용자 경험(User Experience)" 제목 아래에 있을 것으로 예상했다. 짧고 간결해야 하는 리스트의 특성상 리스트 항목들을 설명하는 데 사용되는 언어가 때로는 이해하기 어려울 수 있다.

 

결과적으로 특정 제품 측면에 대한 분류 리스트에서 이득을 얻으려면 리스트의 많은 부분을 읽고 우리 제품과 관련 없는 많은 항목을 걸러내고 일부 항목은 이해하지 못할 것이라는 점을 받아들여야 한다. 즉 좋은 아이디어가 있지만 이것이 사용하기 어려운 방식으로 구현되었다. 그냥 포기해야 할까?

 

나는 그렇게 생각하지 않는다. 저자의 경험상 효과적인 방법 중 하나는 반복적으로 접하는 항목에 대한 리스트를 직접 만드는 것이다. 리스트를 직접 작성했기 때문에 구성이 이해하기 쉽고 언어도 명확할 것이다. 이렇게 하면 프로젝트에서 리스트를 사용할 가능성이 높아진다.

 

이러한 리스트는 시간이 지남에 따라 세부 정보를 수집하여 개발해 나간다. 혼자서 또는 그룹으로 진행할 수 있지만, 그룹으로 진행할 경우 테스터뿐만 아니라 개발자와 제품 관리자도 아이디어를 공유하도록 초대하는 것이 좋다. 이미 공개된 리스트를 검토하며 자신의 상황과 관련된 아이디어를 추출해 볼 수도 있다. 직접 재사용할 수 있는 아이디어를 찾지 못하더라도, 몇 가지 유용한 아이디어를 떠올릴 가능성이 매우 높다.

 

 

아래 예는 로그인 테스트 아이디어 리스트이다.