개발자를 열받게 하는 말들 : 이거 버근가요?

 

안녕하세요, 김개발자입니다.

개발자로 일을 하다보면 그중에 가장 실력이 떨어지는 개발자가 있을 수 있습니다.
대장이 "아 저놈에게는 개발보다는 테스트나 시켜야겠다" 하는 경우인데요.
네 저였습니다.

신제품을 테스트를 하다 보면 가장 버그같은 것을 발견하는 것은
뭐 평범한 일상입니다. 하지만 난감한 것은 바로 이런 경우입니다.

“이건 기능 오류일까, 아니면 명세서가 잘못된 걸까?”

버그처럼 보이지만 사실은 명세서에 누락된 내용이고,
고객이 알려준 명세에 맞게 작동하고 있는데 실제 사용자는 ‘이상하다’고 느끼는 경우가 있습니다.
이 모호한 회색 지대는 소프트웨어 테스터가 가장 자주 마주하는 판단의 순간입니다.

자 저 같은 경우에는 두가지 생각이 먼저 듭니다.
- 와씨 이런것을 발견하다는 역시 나는 대단해
- 이거 고객사에 말하면 수정해달라고 할 것 같은데, 그러면 그 수정에 따른 모든 로직이
   꼬일수도 있다. 그러면 나는 역적이 될 텐데 어떻게 하지?

---

애매한 테스트 상황, 실무 예시

사례 1: 버튼 클릭 시 반응 없음

"저장 버튼을 눌렀는데 아무 반응이 없습니다."

명세서에는 ‘저장 버튼 클릭 시 성공 메시지를 띄운다’는 문구가 없다고 가정할께요.
고객이 이런것을 해달라고 말을 안했으니, 개발자들은 굳이 이걸 추가할 필요는 없습니다.
그런데 로직상 실제 데이터는 저장되고 있다는 말이죠?
버그로 봐야 하나? 하지만 버튼 클릭하면 저장은 이상없이 잘 됩니다.
그런데 UX 관점에선 문제가 조금 있어 보이는 거죠.

사례 2: 입력값 검증 기준 불일치

"전화번호에 하이픈(-)을 넣으면 입력이 막혀요."

명세서에는 집안의 거실의 온도를 적는 이 칸에 숫자만 입력 가능이라고 적어줬습니다.
그런데 실제 서비스에서는 1000이 넘는 숫자도 들어간다는 말이죠?
실제 거실의 온도가 1000도가 넘는 경우는 존재하지 않을 뿐더러
거실의 온도가 1000도가 넘는다면 이 시스템에 값을 입력하는 게 아니고, 빨리 도망을 쳐야 합니다.
사용자 입장에서는 존재하지 않는 숫자도 입력되는 ‘버그’, 개발자 입장에서는 ‘명세대로 한 것’이 되겠습니다.

---

테스트 시 판단 기준이 흔들릴 때

이런 상황에서 테스터로서 고민되는 건 단 하나,
이걸 버그로 리포트해야 할까? 입니다.

• 단순히 “동작이 이상하다”만써봐야 일 제대로 하라고 혼나기만 할겁니다.
• 그렇다고 명세서에 없으니 “그대로 두자”라고 하기도 뭔가 애매합니다. 나중에 문제가 생겼을때, 너 테스트할 때 이거 못보고 뭐했냐는 핀잔을 듣기 딱 좋습니다. (뭐 이렇게 방패막이로 쓰려고 테스터를 따로 두기도 합니다만, 그래서 더 민감하고 독하고 확인하게 됩니다.)

이런 모호한 경우가 반복되면 테스터와 개발자 간의 오해도 쌓이기 쉽습니다.
“QA는 왜 자꾸 사소한 걸 문제 삼지?”
“개발은 왜 이렇게 대충 명세를 짰지?”
문제는 코드보다 기준입니다.

---

대응 전략 1: "의도"를 추정하고 명확히 질문하자

버그냐 아니냐를 따지기 전에, 기획 의도가 무엇인지 먼저 확인하는 것이 중요합니다.
다음과 같은 방식으로 커뮤니케이션을 시도할 수 있습니다:

“현재 사양서에는 A라고 되어 있지만, 실제 사용자 경험에선 B일 수 있어 보입니다.
이 동작이 맞는지 확인 부탁드립니다.”

버그로 단정 짓기 전에 기획자나 PM과 이야기를 나누면 많은 혼란이 줄어듭니다.
생각보다 개발자나 테스터가 컴퓨터 앞에만 앉아 있는 것은 아닙니다.
계속해서 편한 분위기에서 사람들끼리 이야기를 하고 소통해야
서로의 생각을 잘 이해하고, 그 이해가 반영된 좋은 결과물이 나오게 됩니다.

---

대응 전략 2: "불분명한 명세"도 이슈로 다뤄야 한다

명세서에 아무 설명이 없다면,
그 자체가 명세 미비(Missing Requirement)로 리포트해야 합니다.

• Issue Type: 명세 누락
• Description: 특정 상황에서 동작 정의가 없어 판단 어려움
• Suggestion: 사용자의 기대 행동을 기준으로 처리 권장

이렇게 하면 개발자도 "왜 이게 이슈인지"를 이해하고,
기획자도 "어디를 보완해야 하는지"를 정확히 알 수 있습니다.
일단 명세서에는 내용이 없어서 버그는 아니냐, 이런 이슈가 있을 수 있으니, 확인을 해달라는 겁니다.
그러면 기획에서는 다시 고객과 확인을 하는 과정을 거치고,
고객의 신뢰도는 올라가겠죠, 그리고 대부분 고객들고 그 기능을 추가해달라는 일을 (추가비용없이)
요청할 것이고 개발에서는 화를 내고 테스터는 왜 긇어 부스럼을 만드냐고...

---

대응 전략 3: 기준을 문서화하자

팀 내에서 이런 혼란이 반복된다면,
공통적인 판단 기준을 문서화해두는 것이 좋습니다.

예를 들어

• 명세 누락 시 QA의 판단 우선순위
• UX적 불편도 이슈로 기록하는 기준
• 동일한 패턴의 이슈 처리 예시 목록

이런 기준은 새로 들어온 QA나 개발자에게도 큰 도움이 되며,
테스트의 일관성과 신뢰성을 높이는 데 기여합니다.

---

마무리하며

소프트웨어 테스터는 개발자들 중에서도
감정 노동을 조금 더 하게되는 직무인것 같습니다.
하지만 바로 옆 못된 동료의 실수와 헛점을 찾아내는 것이 일인 만큼
발견했을 때의 그 짜릿함을 잊을 수가 없으..

단순히 기능 오류만을 찾는 일이 아니며,
제품이 사용자에게 자연스럽게 작동하는가를 검토하고,
그 과정에서 명세의 불완전함을 발견하는 것도 테스터의 중요한 역할입니다.
다음에 “이거 버그인가요?”라는 질문이 떠오를 때,
조금만 더 생각해보세요.

그건 단순한 결함이 아니라,
옆 사람들 제치고 나 혼자 성공하는 기회일지도 모릅니다.(?)