It's a Bug!

It’s a Bug!

Testing Lessons from Labor Triage

By Robert Sabourin and Anne Sabourine

 

버그를 선별하는 것(Bug triage)은 곧, 소프트웨어 버그의 운명에 대한 결정을 내리는 것을 의미한다: 버그를 그냥 가지고 갈 것인가? 이것을 지금 당장 수정해야만 하는가? 이후에 수정할 수 있을 것인가? 아니면 버그와 함께 출시할 것인가? 우리가 선택할 수 있는 다른 옵션은 어떤 것이 있는가? 다음으로 무엇을 해야 하는가?

나는 1992년 이후부터 내가 수행했던 모든 소프트웨어 프로젝트에서 버그 선별(Bug triage)을 수행해왔다. 버그 선별에 대한 나의 영감은 바로 ‘분만과 진통 간호(Labor and delivery nursing)’에서 유래했는데, 이는 몬트리올의 로얄 빅토리아 병원의 신생아 분만 센터에서 일하고 있는 간호사인 나의 아내 앤으로부터 배운 것이다. 앤은 병원에 도착해 분만이 예상되는 수백 명의 산모들을 대상으로 출산 경험이 있는지에 따라 산모들을 분류하는 일을 해왔다.

분만과 진통 간호는 병원에 도착하는 환자들을 어떤 방법으로 다룰 것인지를 결정하는 방법이다. 앤은 종종 순식간에 이런 행위의 방향을 결정해야 했으며, 자주 최소한의 정보만으로 목숨과 직결되는 결정을 내리곤 했다.

나는 분만과 진통 간호의 기본적인 네 단계를 바로 버그 선별에도 적용해 보았다:

l  사전 평가(Preliminary Assessment)

l  인터뷰(Interview)

l  탐험과 관찰(Exploration and Observation)

l  행동 취하기(Taking Action)

 

사전 평가 – 버그를 두 눈으로 똑똑히 살펴보라!

분만 선별 평가(Labor triage assessment)는 환자의 선별을 담당하는 간호사가 환자를 보자마자 시작된다. 선별 담당 간호사는 환자를 관찰한다: 그녀가 말은 할 수 있는가? 흥분하지는 않았는가? 그녀가 기절하기 직전은 아닌가? 그녀가 흥분하거나, 불안해 하거나, 혹은 어떤 종류의 트라우마^[각주:1]를 겪고 있지는 않은가? 간호사의 첫 번째 판단은 상황이 얼마나 급박한가에 달려 있다. 때때로 심지어는 앤이 그 환자의 이름을 알아내기도 전에, 바로 응급 의학 조치가 필요한 경우도 있다 – 신생아들은 기다려주지 않기 때문이다. 선별을 담당하는 간호사들은 항상 어떤 일이라도 대비하고 있어야 하며 흥분하는 대신 늘 평정을 유지해야 한다. 어떤 경우 선별 담당 간호사가 바로 신생아를 분만해 내기도 한다. TV 드라마에 등장하는 모든 흥분의 요소를 다 가지고 있는 직업이다. 선별 담당 간호사는 무엇을 관찰해야 하는지를 알고 있으며, 심각한 상황에 대해 이를 인식하고 여기에 대처하는 방법을 훈련 받는다.

버그 선별 평가도 버그가 발견되자마자 수행된다. 나는 버그를 충분히 관찰한다: 사용자의 중요한업무가 이로 인해 중지될 것인가? 전염성이 있는 버그인가? 이것이 다른 어떤 것을 파괴할 것인가? 이것이 법규, 규약, 혹은 계약의 의무사항을 위배하는 것인가? 클라이언트 데이터가 손실될 것인가? 우리가 다른 업무를 하는 것을 방해할 것인가? 나의 첫 번째 판단은 상황이 얼마나 위급한 것인가에 달려있다.

버그의 사전 평가 단계에서 나는 이러한 버그들이 즉각적인 조치를 요구하는 것인지를 판단하고 이후 이에 상응하여 요구되는 일련의 조치를 준비한다. 몇몇 프로젝트에서 나는 이것을 버그 필터링(Bug filtering)이라고 불렀다. 나는 일련의 문서 작업이나 관료적인 사무 업무를 가급적 줄이고 버그를 분석하는 일에만 집중했다. 버그에 어떠한 조치가 취해질 필요가 있다면, 나는 그에 상응하는 조치를 취했다.

나는 선별 평가 기법을 연마하기 위해 버그에 대해 많은 것을 공부해야만 했다. 나는 내가 “늑대와 양치기”처럼 거짓말을 하는 사람을 피하고 싶으며, 개발자들로 하여금 문제를 수정하게 만드는 것은 단지 재촉한다고 해서 될 일이 아니다. 버그 분류학을 공부하는 것으로부터 모아지는 지식들은 훌륭한 정보 자료가 된다. 나는 항상 유사한 프로젝트들에서 실질적으로 만날 수 있는 버그들에 대해서도 공부한다. 문제의 심각함을 정확하게 파악하기 위해, 나는 이 문제를 바로 수정하지 않았을 경우 최종 사용자가 겪게 될 영향을 이해하려고 노력한다.

사전 평가는 버그 리뷰 미팅을 소집하거나 더 많은 테스팅이 수행되기 전에 즉각적인 행동을 취할 수 있는 계기를 마련해준다. 무슨 일이 일어날지, 그리고 어떻게 완료될지에 대한 복합적인 지식을 가지고 사전 평가를 대비해야 한다. 나는 프로젝트 매니저, 개발 리더, 그리고 모든 팀의 이해 당사자들이 내가 사전 평가를 수행하고 있다는 것을 인지하도록 함으로써, 위급한 경우가 발생했을 때 관료적인 업무 구조를 피해갈 수 있었다.

 

인터뷰 – 정황 이해하기

분만 선별 평가에 필요한 정황은 모든 것들이다. 서로 다른 정황에서 같은 조건이 관찰된다고 하더라도, 결과적으로는 극적으로 매우 다른 결과가 나올 수 있다. 예를 들어 진통 주기(Labor contraction timing)가 그러하다. 산모가 선별 담당 간호사에게 전화를 해서 90분 간격으로 약 60초에서 90초간 이어지는 낮은 강도의 산통을 호소하는 상황을 가정해보자. 만약 당신이 산모가 최근 교통 사고를 당한 경험이 있다는 것을 안다면, 지체하지 않고 그녀를 살펴보길 원할 것이다. 만약 당신이 산모가 단지 TV의 연속극을 보면서 기다리고 있다는 것을 안다면, 그녀에게 몇 시간 안에 다시 전화해 줄 것을 부탁하고 일을 쉽게 풀어갈 수 있을 것이다.

선별 담당 간호사는 정황을 파악하기 위해 환자와 인터뷰한다. 그녀는 산모가 분만 과정 중 어떤 상황에 처해있는지를 파악하기 위해 질문을 던진다. 환자에 대한 가장 기본적인 정보 몇 가지가 수집된다: 이름, 나이, 태아 연령과 담당 의사, 그리고 임신 경험, 그리고 임신 동안 어떤 일이 발생했었는지 등에 대해 정보를 수집한다. 여기에 더해, 임신에 관한 몇 가지 추가적인 정보들이 수집되는데, 여기에는 특정한 조건, 초음파 검진 결과, 그리고 임신 기간 동안 취해진 모든 의학적 행위에 대한 정보 등이 포함된다. 환자의 실제 상황에 대한 정보도 수집된다: 진통 주기, “양수(Water)”가 터졌는지의 여부, 진통 외의 특별한 통증이 있었는지 여부와 특별한 예후가 있었는지 등에 대한 정보가 수집된다. 인터뷰는 단지 몇 분 안에 수행되며, 환자가 입원해야 하는지, 몇 시간에 걸쳐 관찰되어져야 하는지, 혹은 다른 부서로 보내져야 하는지를 결정하는 데 필요한 정보를 제공해 준다.

버그 선별에 필요한 정황도 모든 것들이다. 같은 버그가 하나의 정황 하에서 긴급한 조치를 요구할 수도 있고, 그러한 조치들이 쉽게 보류되거나 혹은 다른 정황에 맞게 작업될 수도 있다.

테스터는 항상 버그를 인터뷰해야 한다. 테스터는 어떤 버그가 수정되어야 하며 어떤 버그가 유지되어야 하는가를 결정하기 위해 많은 정보를 수집해야 한다. 그들은 버그 트래킹 시스템으로부터 기본적인 정보를 수집한다: 언제 발생했는가? 어떤 버전의 소프트웨어가 사용되었는가? OS는 무엇인가? 빌드, 로케일, 데이터베이스의 상태, 그리고 시스템의 상태는 어떠했는가? 동시에 진행되고 있는 것은 어떤 것이 있는가? 테스터들은 문제를 노출할 수 있는 특성들에 대해서도 질문을 던져야 한다: 항상 일어나는가? 재현하기 위한 단계는 무엇인가? 문제와 관련되어 있는 다른 테스트들 중 어떤 것들이 완료되었으며 그 결과는 무엇인가? 버그의 상태에 관련된 다른 질문들도 있다: 중요도(Severity)는 어느 정도인가? 문제를 수정하지 않았을 경우 그 결과는 어떠한가? 버그로 인해 발생하는 손실은 어느 정도인가?

나는 어떠한 행동을 취하기 전에 버그의 정황 정보에 대한 다음 세 가지 요소를 고려한다:

사업적 정황(Business context): 왜 버그가 우리의 사업에 있어서 중요한 의미를 가지는가? 만약 버그가 수정되지 않는다면 그 영향은 어떠할 것인가? 수정 방법(혹은 회피 방법; Workaround)이 받아들여 질것인가?

기술적 정황(Technical context): 버그와 관련되어 있는 특별한 기술적인 요소가 있는가? 그것이 우리의 코드 안에 있는가? 써드 파티에 의존해야 하는가? 어떤 다른 것을 파괴해서 이 버그를 수정할 수 있을 것인가?

조직적 정황(Organization context): 이슈가 테스팅 담당 파트에서 보고된 것인가 그렇지 않으면 필드에서 발생한 것인가? 더 낮은 레벨의 테스팅이 필요한가? 클라이언트 배포 이후에 세련된 방식으로 업데이트 할 수 있는가? 수정할 수 있는 개발자에게 접촉할 수 있는가?

 

탐험과 관찰 – 더 많은 것을 배워라

인터뷰를 수행하고 나서 선별 담당 간호사는 환자의 상태를 더 잘 파악하기 위해 몇 가지 의학적인 테스트를 수행한다. 선별 담당 간호사는 체온, 혈압, 그리고 태아의 심장박동 등을 체크하고 몇 가지 간단한 혈액과 체액에 대한 테스트를 수행한다. 이러한 테스트 결과는 인터뷰 및 사전 평가의 데이터와 조합되어 의사 결정에 도움을 준다. 여러 조건들이 명확히 구분되지 않는다면, 선별 담당 간호사는 몇 시간에 걸쳐 환자를 관찰하게 된다. 모니터링은 초음파와 같은 서로 다른 의학적 테스팅 기법을 사용해 수행되며, 이는 절차에 따라 정상적인 의료 행위가 수행되기 전에 응급 조치를 취하는데 도움을 준다.

때때로 버그에 대해 어떤 행동을 취해야 할지 결정하기 전에 더 많은 정보가 필요할 때도 있다. 테스터에게 이 문제에 대해 더 많은 조사를 하도록 할당할 수도 있고, 버그를 더 잘 이해하기 위해 개발자에게 직접 조사 작업을 하도록 할당할 수도 있다. 의사 결정을 위해 필요한 추가적인 데이터를 모으기 위해, 문제가 발생한 영역에 대한 탐험적 테스팅(Exploratory testing)이 사용될 수 있다. 버그를 재현하기 위한 다른 방법은 없을까? 문제와 연관되어 있는 다른 응급 조치는 없을까?

나는 테스터들에게 테스트 대상인 소프트웨어의 데이터를 캡쳐하고, 소프트웨어가 구동되고 있는 환경을 관찰할 것을 권장한다. 테스트 중인 애플리케이션이 얼마나 많은 CPU 점유율을 차지하는지 측정하는 것은 무척 중요할 수 있다. 요청에 대한 애플리케이션의 반응은 얼마나 빠른가? 기본적인 데이터 완전성(Data integrity)는 준수하고 있는가? 시스템 리소스는 어떻게 소비되고 있는가?

나는 또한 애플리케이션의 다른 부분들이 전형적인 트랜잭션을 충분히 핸들링 할 수 있을 정도로 원활하게 작동하고 있다는 것이 확인되길 원한다. 소프트웨어의 일부 영역에서 버그가 나타났을 때, 다른 파트의 코드나 데이터가 여전히 정상적으로 작동하고 있는지를 신속하게 확인하는 것은 무척이나 중요하다.

 

행동 취하기 – 일 마무리하기

분만 선별로부터 세 가지의 결과가 도출될 수 있다: 산모가 입원하거나, 관찰 받거나, 혹은 집으로 돌려보내 지는 것이다.

선별 담당 간호사는 선별 평가, 인터뷰 그리고 임상적인 조사 기간 동안 수집된 데이터를 기반으로 적합한 행동을 취하기 위해 작성되어 있는 메디컬 프로토콜을 따라야 한다. 프로토콜은 한 페이지의 뚜렷한 포맷으로 작성되어야 하며, 여기에는 상황(Condition), 핵심적인 정황 결정 요소들(Key context drivers), 그리고 그 상황에 맞게 추천되는 일련의 조치 방법들이 기술되어 있어야 한다. 선별 담당 간호사는 매일매일 실제로 발생하는 분만 선별 업무에서 단지 프로토콜 매뉴얼만을 의지하지는 않는다. 그녀는 매우 중요한 위치에 처해 있으며 그녀가 접하는 실제적인 상황에 맞추어 대응해야 한다. 그녀는 조치를 취해야만 한다. 그녀는 끊임없이 자신의 지식과 경험을 조합해야 한다.

나는 세 가지 가능한 결론 중 하나를 결정하기 위해 버그를 선별한다: 지금 바로 수정하거나, 나중에 수정하거나, 혹은 수정하지 않는 것이 그것이다.

나는 모든 버그 선별의 결정이 사업적, 기술적, 그리고 테스팅의 요소들로부터 영향을 받는다는 것을 잘 알고있다. 나는 분만 선별에 사용되는 것과 같은 명확한 일련의 프로토콜을 만들어 낼 수가 없었다. 나는 소규모의 이해 당사자들이 버그 우선순위를 결정하고 있다는 것을 믿어 의심치 않는다. 나는 이러한 그룹에 고객의 입장을 대변하는 프로덕트 매니저, 제품의 기술적인 위험을 인지하고 있는 개발 리더, 그리고 제품의 초기 단계 테스팅을 주도하는 테스트 리더를 포함시키고 싶다. 일반적으로 테스트 리더는 사전 평가, 인터뷰, 그리고 탐색적인 단계에서 버그에 대한 객관적인 정보를 제공해 준다. 이러한 팀은 버그에 대한 결정을 내리기 위해 사업적이고 기술적인 관계 요소들을 평가할 것이다.

이 최종 결정은 지금까지 모아온 모든 정보에 달려있다. 나는 버그 선별 팀이 프로젝트의 목적과 100% 일치되었을 때 최고의 업무를 수행한다는 것을 발견했다. 왜 우리가 이 프로젝트를 수행하는가? 핵심적인 사업적인 이슈는 무엇인가? 기술적인 도전 요소는 무엇인가? 이 프로젝트가 어떤 가치를 제공하며 누구를 위해 제공하는가? 팀 구성원들의 “가치가 동조(Value sync)” 된다면, 어려운 의사 결정도 더 쉽게 내릴 수 있다.

나는 늘 팀에게 각각의 버그에 대해 다음과 같은 중요한 질문들을 고려해볼 것을 권장한다: 버그를 수정함으로써 얻게 되는 이익은 무엇인가? 버그를 수정하지 않았을 경우의 결과는 무엇인가? 나는 이와 함께, 그 반대의 질문도 항상 고려해야 함을 확신한다: 버그 수정의 결과는 무엇인가? 버그를 수정하지 않을 경우 얻게 되는 이익은 무엇인가? 팀은 버그를 수정할지, 혹은 그냥 그 상태로 내버려둘지와 관계된 저울질을 해볼 필요가 있다. 

  

맺는 말

짐 맥카시(Jim McCarthy)는 그의 저서 『소프트웨어 개발의 역학 관계(Dynamics of Software Development)』에서, 프로젝트 팀은 제품을 다듬기 위해 모든 결정에 대해 “냉혹하게 선별”해야 한다 라고 제안했다. 비록 그 분야가 무척이나 다르기는 하지만, 분만 선별은 우리가 소프트웨어 테스팅 프로젝트에 반영할 수 있는 다양한 가치 있는 교훈을 제공해 준다. 테스터들은 선별 담당 간호사가 결정을 내리기 위해 사용하는 각 단계와 행위들에 기반해, 그들의 일부 워크플로우를 모델링 할 수도 있을 것이다.

분만 선별 담당 간호사가 언제 환자를 집으로 돌려보내고, 언제 치료를 시작하고, 언제 더 많은 지식이 필요한지를 알아야 하는 것처럼, 테스트 역시 어떤 버그가 수정되어야 하며, 어떤 버그가 유지되고, 의사 결정하기 전에 언제 더 많은 정보가 필요한지에 대해서 배워야만 한다. 분만 선별법은 테스터들에게 우리의 테스팅 프로젝트에 있어 중요한 정황 결정 요소들을 받아들이고 그것에 대응하도록 도와주며, 차별화할 수 있는 가치를 만드는데 집중할 수 있도록 도와줄 것이다.  

 

초진 간호 노트(Triage Nursing Notes)

초진 간호에 사용되는 법칙은 “만약 당신이 이것을 서면으로 확인하지 못한다면, 그것은 종료된 것이 아니다”이다. 노트 테이킹(Note taking)^[각주:2]은 초진 간호에서 무척이나 중요한 기술 중의 하나이다. 이 경우에 포함되는 대부분의 의료 전문직 종사자들은 간호 노트를 참조할 것이다. 초진 노트는 각각의, 그리고 모든 이벤트의 시작, 상호작용, 관찰, 테스트 종료, 그리고 테스트 결과를 포함하고 있다. 또한 노트는 자주 묻는 질문, 질문에 대해 주어진 대답, 간호사가 취해야 할 행동들도 포함하고 있다. 각각의 기록에는 이벤트가 발생한 당시의 시간과 날짜가 포함된다.

초진 간호사는 임상학적 조치를 모든 테스트 결과 및 관찰 결과와 함께 자세하게 기록해야 한다. 경험이 풍부한 사람들은 간결하고, 명백하게 그들의 기록을 남긴다. 그들은 노트를 작성하기 위해 템플릿 양식을 사용하고, 이는 관찰과 행동에 초점이 맞추어져 있으며 주관적인 평가를 포함하지는 않는다 – 프라이데이 경사(Sergeant Friday)^[각주:3]의 대사처럼 “단지 사실만을(Just the facts)” 기록해야 한다.

 

테스팅 분야의 노트 만들기(Note taking in Testing)

나는 수년 동안에 걸쳐 테스팅에 있어 커뮤니케이션이 가장 중요한 기술 중의 하나임을 배워왔다. 버그 리포트를 작성할 때 이를 볼 관객들을 상상하라: 우리는 다른 테스터, 테스트 리더, 개발 리더, 핼프 데스크의 스탭들, 개발자, 프로덕트 매니저, 테크니컬 라이터, 프로젝트 매니저, 그리고 각기 다양한 제품 관련 이해 당사자들에게 문서를 작성한다. 테스터들에게 있어 이런 다양한 관객들을 대상으로 어떤 정보를 너무 간단하거나, 헷갈리거나, 혹은 너무 복잡하게 전달하지 않으면서도 충분히 그 뜻이 전달되도록 의사소통 하는 것이 무척이나 중요하다. 소프트웨어 테스팅 세션의 기록과 버그 리포트는 초진 간호 노트와 동일한 수준의 정밀도를 기준으로 작성되어야 한다.

 

통증 정량화하기(Quantifying Pain)

초진 간호사는 한편으로는 표현하기 무척 까다로운 임신과 관련된 요소들을 정량화할 수 있도록 도와주는 다양한 흥미로운 방법들을 가지고 있다. 그 중의 하나가 색깔로 표시되는 통증 지표로,   이는 밝은 적색에서부터 아주 어두운 다크 레드로 표시되는 명암차를 가진 붉은 색을 가지고 있다. 이러한 컬러 시스템은 환자들에게 그들이 어느 정도의 통증을 느끼고 있는지 표현해 달라고 요구할 때 사용된다. 비록 이 시스템이 절대적인 척도를 제공하는 것은 아니지만, 시간의 경과나 서로 다른 의학적 조치의 결과로 통증 수준이 증가하거나 경감할 때, 환자가 이를 표현하도록 도와주는 데에는 무척 효과적이다.

 

중요도 정량화하기(Quantifying Severity)

내게 가장 어려운 문제 중의 하나는 버그의 중요도를 결정하는 합리적인 방법을 찾는 것이다. 버그가 야기하는 손해는 어느 정도인가? 나는 몇 년 동안 다양한 방법을 사용해봤고, 최근의 프로젝트에는 선별 분류 통증 척도 방법을 고객의 사이트에 적용해 보았다. 개발자, 테스터, 그리고 프로덕트 매니저들은 버그의 우선순위를 표현하기 위해, 이와 관련된 붉은 색의 명암을 표시했다. 이는 우리에게 즉각적으로 프로젝트의 이해 당사자들이 서로 다른 생각을 가지고 있음을 보여주었고, 결과적으로는 서로를 더 잘 이해할 수 있도록 이끌어 주었다. 우리는 또한 서로 다른 버그들의 상대적인 중요도도 관찰할 수 있었다. 중요도를 색깔로 표시하는 이런 방법은 주관적으로 보일 수도 있지만, 우리가 좀 더 효과적으로 집중하고 커뮤니케이션 할 수 있도록 도와준다는 것은 명백하다.

 

초진 간호사들의 환자 대변하기(Patient advocacy in triage nursing)

모든 산모들이 동일한 혈액 테스트, 응급 조치 그리고 의학적 조치가 필요한 것은 아니다. 초진 담당 간호사가 바로 프로세스를 시작하는 것은 아니다. 초진 담당 간호사는 능동적으로 환자의 입장을 대변해 다른 의료진에게 전화를 걸어 도움을 얻거나 그 상황에 맞는 조치를 취할지를 물어본다. 초진 간호사는 다른 의료진들에게 다음 의료 행위에 매우 세심한 주의가 필요하다고 전달할 수도 있다. 초진 간호사는 환자의 상황이 상대적으로 얼마나 긴급한지에 대해 커뮤니케이션하고, 모든 사람들이 무엇이 필요한지를 확실하게 인지할 수 있도록 한다. 초진 간호사는 다양한 방법으로 진료 과정에 포함된 모든 의료진들에 의해 요구되는 작업들을 인지하고 있어야 한다. 잘못된 커뮤니케이션은 생명과 관련된 심각하고 중요한 문제를 야기할 수도 있다. 초진 간호사는 어떤 케이스에 더 많은 관심을 집중시키기 위해 상황을 과장해서는 안 된다. 초진 간호사로 성공하기 위해서는 믿을 수 있어야 한다. 지속적으로 케이스의 중요도와 우선순위를 객관적으로 파악함으로써 이러한 신뢰를 얻을 수 있는 것이다. 이렇게 확보된 신뢰로 인해, 초진 간호사의 요청에 기반해 다른 사람들이 조치를 준비하고 행동을 취할 수 있도록 하는 것이다. 신뢰를 확보하지 못한 초진 간호사는 아무런 쓸모도 없는데, 이는 아무도 그녀의 말을 들으려 하지 않기 때문이다.   

 

테스팅에서의 버그 대변하기(Bug advocacy in Testing)

신뢰를 확보하지 못한 테스터들은 프로젝트에 영향을 끼치기가 힘들다는 것이 발견된다. 테스터들은 다양한 방법으로 신뢰를 확보한다. 테스터들은 중요한 영향을 끼칠 수 있는 버그를 과장해서는 안되며, 그렇다고 해서 버그를 사소한 것으로 폄하해서도 안 된다. 테스터는 기술해야 할 이슈에 대해 시종일관 명백하고 객관적인 입력값을 제공함으로써, 효과적으로 버그를 대변할 수 있다. 테스터는 개발팀의 모든 구성원들이 필요로 하는 정보의 형태에 집중해야 한다. 단지 버그가 존재한다는 것을 보여주는 것만으로는 불충분하다. 테스터는 문제가 수정되지 않았을 경우 사용자 커뮤니티에 끼치는 영향과 같은, 버그의 중요도를 평가하는데 유용하게 사용될 수 있는 정보를 제공해야 한다. 또한 테스터는 애플리케이션의 기술적인 상태와 버그가 관찰되기 이전에 발생했던 액션과 같은, 개발자에게 유용한 정보를 제공해야 한다. 아울러 테스터는 헬프 데스크나 고객 지원팀 으로부터 전달될 수 있는 질문의 유형에 집중해야 한다. 테스터는 기술적인 분야가 아닌 이해 당사자들이, 문제와 관련되어 있는 것들의 본질을 이해할 수 있도록 버그에 대한 간결한 요약을 제공할 수 있어야 한다.

 

  

통증 지표(Pain Scale)

통증 지표는 분만 선별에 사용되며 밝은 부분에서 어두운 부분으로 끊김없이 이어지는 흐름으로 구성된다. 어두운 적색은 가장 강한 통증을 나타내며 밝은 적색은 가장 약한 통증을 나타낸다.

 

선별 담당 간호사는 이를 통해 산모가 상당한 통증과 불편함을 감내하고 있는지 알 수 있으며, 고통을 설명하기 힘든 정도의 상태일 때와 가장 적합한 단어를 찾기 힘든 상태에서도 환자의 상태를 파악할 수 있고, 고통의 정도를 유추할 수 있다.

 

한 번 환자의 고통 정도가 표시되고 나면, 환자는 이후에 이어지는 통증이 이보다 낮다면 더 밝은 색의 적색을 가리키면 되고, 만약 통증이 더 심해졌다면 더 어두운 적색을 가리키면 되는 것이다.

 

지표는 초진 간호사가 통증의 상대적인 변화를 가치의 정량화나 환자와의 대화를 거치지 않고서도 평가할 수 있도록 도와준다.

통증의 숫자 척도 역시 사용되기는 하지만 경험으로 보았을 때 컬러값이 환자가 경험한 실제의 통증을 더 잘 나타내준다. 적색의 명함차를 문서화하려고 할 때, 간호사는 통증 측정 지표의 반대편에 있는 숫자로 된 값을 읽음으로써 이를 가능하게 할 수 있다. 이것은 윈-윈 시나리오인데 왜냐하면 숫자값은 명백한 기록인 반면 컬러값은 커뮤니케이션에 효과적으로 사용될 수 있기 때문이다.

1. 외상후 스트레스 장애(外傷後─障碍, post traumatic stress disorder): 신체적인 손상 및 생명을 위협하는 심각한 상황에 직면한 후 나타나는 정신적인 장애가 1개월 이상 지속되는 질병. [본문으로]
2. 역자 주: 노트 테이킹(Note taking)은 어떤 내용을 들으면서 간략한 내용을 메모하는 것을 말한다. [본문으로]
3. 역자 주: 프라이데이 경사는 조 프라이데이(Joe Friday)라는 캐릭터의 이름이다. 미국의 라디오와 텔레비전의 드라마인 “Dragnet”의 주연 캐릭터이며, 그가 남긴 유명한 대사로는 “My name is a Friday – I’m a cop”과 “Just the facts, Ma’am”등이 있다. 댄 애크로이드가 조 프라이데이 역할을 맡고 톰 행크스가 그의 파트너인 팹 스트리벡 역할을 맡은 동명의 영화가 1987년에 개봉했다. [본문으로]