테스트를 하면서 우리는 여러가지 버그들을 경험하게 됩니다. 버그를 확인하게 되면 개발자 혹은 기획자에게 리포트를 하게 될텐데, 리포트의 내용에는 버그에 대한 정보뿐만 아니라 기대결과까지 기재하는 것이 대부분입니다.
요구사항과 다른 동작을 하는 내용에 대해서는 반드시 수정해야하지만, 이슈의 내용에 따라서는 꼭 수정하지 않아도 됩니다.
이번 포스트에서는 이슈를 처리하는, 이슈를 대하는 방향에 대해 기재해봅니다.
이슈를 처리하는 방법
이슈가 발생한 원인에 대해 수정하기
버그가 확인되어 리포트하면, 무조건 해당 버그가 발생한 원인에 대해 수정해야하는 경우가 있습니다. 사실 대부분의 이슈들은 수정되어야할 이슈이며, 많은 경우에는 아래와 같은 이유일 것입니다.
- 요구사항과 맞지 않은 동작인 경우
- 단순히 기능에 대한 요구사항일 수도 있으며,
- 기능을 넘어 비즈니스적 요구사항을 달성하지 못하는 동작인 경우도 해당.
- 유저가 이용할 수 없는 중대한 이슈가 발생하는 경우
- 이용중 앱에서 크래시가 발생한다던지
- 유저가 사용함에 있어서 영향이 발생할만한 이슈인 경우
수정하지 않고 내비두기
그런데 버그중에는 수정하지 않는 경우도 있습니다. 이런 경우라면, 발생한 버그/이슈들은 어떻게하면 될까요?
기획서를 수정하는 방향
기획서 및 상세 설계서와는 조금 다르나, 테스트 담당자가 판단했을때 현재의 구현이 요구사항에 대해 좀 더 부합하는 경우에는 이슈를 수정하지않고 오히려 기획서를 수정하는 방향으로, 기획자 혹은 프로덕트 오너에게 제안할 수도 있습니다.
이 경우라면, 기획서의 문장을 수정하여 이슈였지만, 이슈가 아니게되는 경우입니다.
추가 구현으로 이슈를 회피하기
어떠한 이슈에 대해 대응은 해야겠으나, 수정 코스트가 생각보다 많이 드는경우 혹은 수정이 어려운 경우에 대해서는 다른 방법으로 해당 이슈를 회피하는 방법을 제안해볼 수 있을 것입니다.
이슈중에는 특정조건이 만족되어 발현하는 이슈도 있습니다. 예를 들어 A 팝업과 B팝업이 있고, 동시에 노출되지 않는 팝업이라고 가정해봅시다. 이 때, A팝업이 떠야하는 상황에 B팝업이 노출되었는데, 이 B팝업에 문제가 있다면, A팝업이 노출되도록 A팝업에 대한 이슈를 수정하므로써 B팝업에 대한 이슈를 회피할 수 있을 것입니다.
Known-issue로 가져가는 방향
발생한 이슈에 대해 그냥 무시하는 경우입니다. 이 경우에는
- 이슈 인지는 하였지만 유저에 대한 영향도가 낮아, 이용에 문제가 없는 경우
- 비즈니스 요구사항에 대해서는 충족하고 있는 마이너한 이슈
- 대응해야하는 우선순위가 낮고, 리소스의 제한으로 다음 패치/배포때 대응하기로 결정된 이슈
의 경우라면, 알려진/알고있는 이슈 (Known-issue) 취급을 하게되고, 팀 내에서 리소스적 여유가 있을 때 대응하게 됩니다.
이슈에 대해 수정하지 않는 방향에 대해 결정하려면?
이슈가 발생했는데, 이것을 수정하지 않는 것에 대해서는 테스트담당자 독단으로 결정하고, 판단하는 경우는 거의 없습니다.
어찌되었던간 프로덕트는 많은 이해관계자들이 다같이 만들어나가기 때문이고, 특히 안건을 발의한 프로덕트 오너라던지, 요구사항을 정의한 이해관계자라면, 이슈에 대해서 무조건 수정해야하는건 아니냐는 생각을 할 수 있기 떄문입니다.
관계자들에게 테스트담당자로써의 의견을 전개하고, 이슈에 대한 수정방향을 제안하여 이해관계자들간의 인식을 맞추어야합니다.
이슈에 대해 수정하지 않는 것으로 결정되었다면, 이러한 결정에 대한 기록을 리포트, 티켓 혹은 문서의 형태로 남겨, 다른 사람들도 인지할 수 있도록 히스토리를 만들어놓아야겠습니다.
