🦋 Software
오늘.. 개밥 드셨나요?
thumbnail
category
🦋 Software
tags
QA
Docs
summary
🐕 개밥.. 드셔야죠? 🐕 훌륭한 개발자라면 말이에요.
QA 엔지니어와 관련된 글이다.
Eat Your Own Dog Food
너의 개 사료를 먹어봐라!
황당한 말이다.
비슷하게는 DogFooding 이라고도 하는 것 같고..
유래를 뜯어보자.
- 예전에 미국의 한 가축사료 회사에서 CEO가 본인 공장에서 나오는 개 사료를 직접 먹었다는 사례가 있다.
정말 단순하게도 “내가 만든 거, 내가 먹어봐야지.” 라는 취지의 행동이라고 한다.
소프트웨어 관점에서는 🐶
“자신이 개발한 것을 자신이 직접 확인해보자”
라는 의미로 쓴다.
당연한 일들이 흘러가는 과정은 결코 당연하지 않다.
일상에서도 당연하다고 생각되는 것들을 자세히 보면 당연한 일이 아니다.
누군가 하고 있거나, 대부분이 지키고 있어서 자연스러워 보이는 것 뿐이다.
당연함의 소중함이나 고마움을 놓치는 순간, 그 보다 더 많은 것들을 같이 놓치게 된다.
개발에서도 마찬가지다.
본인이 개발한건데, 당연히 테스트 돌려봤겠지
그렇지 않다.
정말 정말 정말 놀랍게도 생각보다 적지 않은 개발자들이 본인의 코드와 로직을 테스트하지 않는다. 🤬
이유는 간단하다.
이미 내 머릿속에선 모두 시뮬레이션 했기 때문에 더 할 필요가 없다.
즉, 자만과 게으름이 기본을 망치고 있다. 🔨
그럼 개발자들이 열심히 테스트만 해봐주면 끝날까?
아쉽게도 아니다.
Eat your own dog food 라는 문장에서 your 의 대상은 우리 모두다.
당신이 기획한 서비스고, 당신이 디자인한 서비스이며, 당신이 개발한 화면이고, 당신이 개발한 로직이다.
IT기업에서 어느 누가 “나는 QA로부터 자유롭다”고 말할 수 있을까.
이 무거운 책임감은 모두가 나눠져야 하는 것이다.
특히 QA엔지니어가 따로 없다면 이 무게는 배가 된다. 🏋🏽♀️
구체적으로 QA라는 작업은 QA엔지니어가 존재한다면 그 분이 작업해주실 영역이니까 크게 신경쓰지 않아도 된다 (신경을 끄라는 얘기는 아니다)
그러나 작은 기업일 수록 QA 엔지니어라는 직군은 사치에 가깝다. 💸
때문에 나는 작은 기업에서 만큼은 모두가 QA에 대해 신경쓰길 원한다.
개발자 수준의 테스트
한 글에서 발췌한 내용이다.
- Q. 개발자들이 테스트하면 되지 않을까요?
- 네, 정말 일부 훌륭한 개발자들이 만든 SW의 경우는 소스코드의 완벽함과 형상관리를 위한 단위테스트까지 프로그래밍 코드로 직접 또는 자동으로 검증하고 본인이 여러가지로 검증해보면서 이상적인 코드가 나옵니다만, 그런 훌륭한 개발자는 여러분의 회사에서 일하지 않을 가능성이 큽니다.
- 대부분의 일반적인 개발자들이 만든 코드는 대부분 간신히 돌아가는데 맞춰져있고, 개발자들이 하는 테스트 역시 일반적으로 사용하는 형태에 대해서만 테스트 되어 있을 가능성이 큽니다. 현장에 적용되면 반드시 사고 납니다.
실제로 이 글을 쓴 사람의 이야기를 들어보면 (과거의 일화이긴 하지만)
“잘쓰던 전기도 갑자기 벼락 맞아 정전되어 문서를 날려먹고 평생 써도 다 못쓴다는 하드 디스크가 모자라고, 몇 명 안쓰겠지 생각했던 웹에 귀인이 나타나 폭발적인 접속이 이뤄지기도 했으며, 10000건 정도만 입력해서 쓰라고 했더니 클라이언트는 듣지 않은 채 1억 건의 데이터를 넣고 작동하지 않는다며 화를 내었다.”
이 외에도 고객 경험 측면에서 “이것 조차 안돼?” 라는 인상을 남기는 순간, 제품이 어떻게 될지는 관련 종사자라면 모두가 알 것이다.
이런 이유로 개발자 수준의 테스트란 미친 짓이다.
제품이 너덜너덜해지도록 온갖 경우를 가정하고 제품이 어떻게 움직이는 지 봐야한다.
개밥먹기의 장점
- 제품 관계자만 테스트하면 매너리즘에 빠질 수 있기에 다양한 시각으로 보는 관점에도 영향을 끼친다.
- 사내 직원을 통해 진행됨으로 전사적으로 제품을 이해하고 관심을 갖게 할 수 있다.
- 신입 사원에게 제품을 이해시키는 데에 아주 탁월하다.
실제 업무 상황에서도 고객의 불편 사항을 단순히 고객 탓으로 넘기거나 우선순위를 뒤로 미루는 것보단, 직접 사용하고 불편함을 느꼈을 때 적절한 우선순위를 두고 개선하여 추후 제품을 수정하거나 개발하는 데 있어서 좋은 영향을 줄 수 있을 것이다.
단적인 예로 게임 제작자들은 유저와 소통하는 것을 다른 IT업계보다도 중요히 여기는데, 사소한 건의사항이라도 최소한의 관심을 쏟고 있다거나 해결해준다면 그 유저가 나의 게임에 갖게 될 로열티는 감히 계산할 수 없다.
품질증명에 대해서
문제는 HOW 에 있다. 어떻게 QA를 할 것인가.
베스트 케이스는 당연히 QA 엔지니어 채용인 것 같다.
기획 전반적으로 빈틈을 채워줄 것이며, 요즘엔 개발지식도 쌓으시는 분들이 많다고 들었는데 서비스의 규모가 커질 수록 그들이 제공해주는 자동화 덕분에 빠르면서도 정확한 QA가 이뤄질 것이다.
카카오의 서비스품질파트에서 일하시는 분들의 생각과 행동을 보면 QA가 절대 가볍게 볼 영역이 아니라는 걸 알 수 있다.
이런 딥한 내용까지 QA엔지니어가 없는 조직이 수행하긴 어려운게 사실이다.
그래서 우리는 모여야한다.
모여서 할 일
지극히 개발관점에서 테스트에 도움을 줄 수 있는게 뭐가 있을까?
테스트 코드!
테스트 코드가 갖춘 힘은 매우 크다.
특히 TDD 또는 BDD와 같이 테스트 코드에 대한 이론까지 접목시키면 좋고.
먼저 테스트 케이스를 짜보면서 예외처리에 대해 더 고민할 수 있고 실제로 놓치고 있던 걸 문득 생각하게 되는 순간이 있다.
게다가 비즈니스 로직을 더 깔끔하게 정리할 수도 있으며, 하다못해 변수명과 메소드명 같은 사소하지만 시간 잡아먹는 일들도 여기서 모두 줄일 수 있다.
말 그대로 모든 내 머릿속의 시뮬레이션을 실패와 성공 케이스로 해보는 것이다.
여기까지가 테스트 코드를 장려하기 위한 빌드업이었다..!
개 밥먹기는 당연하고, 훌륭한 개발자가 되어보자.
내 서비스에 대한 책임감은 내 코드를 이해하는 것에서부터 출발해야 한다.