개발자와 테스터는 엉덩이가 무거운 세스코와 같다
21세기 들어서 사람들의 두뇌 회로가 디지털화(....)가 되고 있는 요즘, 학교나 실무에서 프로그래밍 언어를 배우시는 분들이 점점 많아지는 것 같습니다.
그도 그럴 것이 워낙 다방면 하게 쓰이기 때문이죠.
관련 종사자 분들은 아마도 요구사항, 분석, 설계, 구현, 테스트 무한 반복하고 계실 겁니다.
영업, 디자인하시는 분들 보면 대체로 밝은 분들이 계신 반면에 개발, SI, 아키텍처, 테스팅을 주로 하시는 분들 보면 좀 많이 지쳐 보이기도 합니다. 귀신 보는 거 같아요
시력도 나빠지고 건강은 안 좋아지고, 주로 에러 잡는데만 엄청난 에너지를 소비하신다고 합니다. 에러가 참 얄궂네요
대부분 버그가 왜 버그라고 불리게 되었는지 어렴풋이 알고 계실 겁니다.
버그 즉, 컴퓨터의 오작동이 처음 발견된 사례는 말 그대로 회로에 나방이 끼어있었기 때문이었죠?
이를 계기로 버그라는 용어가 탄생했다는 유래는 많이들 아실 겁니다.
지금은 버그의 범위가 워낙 넓어져서 위와 같은 물리적인 오작동을 제외한 논리적인 오류로 인해 발생하는 사소한 상황들 또한 버그라고 하죠.
갑자기 왜 이런 글을 쓰냐구요? 엑셀 작업하다가 튕겨서 조금 날렸거든요...하.....ㅠㅠ
저만 이런 적 있는 거 아니죠? 彡(-_-;)彡
튕기는 현상 같은 건 버그 같기도 하고 결함 같기도 하네요..... 버그라는 단어 자체가 사람들이 이해하기 쉽고 빠르게 소통할 수 있다 보니까 용어를 혼재해서 쓰는 경우가 많이 있더라구요.
다만 위 같은 현상은 따지자면 결함에 좀 더 가깝습니다. 튕기는 현상은 예외 처리로 개발자가 준비해 놓은 장치일 수도 있거든요. 다만 튕긴 당시에 사용자가 원하는 기능은 아니니까 결함은 맞다고 볼 수 있습니다.
품질활동 시 테스팅을 통해 발견할 수 있는 버그가 있고, 결함이 있겠지요? 둘이 유사한 부분이 있지만 살짝 다르게 보셔야 합니다.
또 다른 건 의도적으로 프로그램 변조나 사용자 정보를 위조해서 만들어내는 게임 버그판 같은 것들도 버그라는 단어를 쓰지요. 대표적으로 쿠키런 버그판 다들 아시죠?
사실 이건 버그라는 단어보다는 핵(hack)이나 치트(cheat)라고 표현하는 게 좀 더 정확한데, 소프트웨어에 내부에서 우발된 문제가 아니라 허용되지 않는 외부의 접근 방식이라고 보시면 됩니다.
이런 경우는 많지 않겠지만, 실제로 다른 사람이 오작동이라고 생각되는 부분도 프로그램을 설계한 사람이 일부러 기믹을 집어넣어 의도한 것일 수 있습니다. 이것은 결함이 아니죠. 프로그램은 요구사항대로 정상 동작 했으니까요!
사실 버그를 잡는다는 건 디버깅이라는 표현이 좀 더 어울립니다. 테스팅은 버그나 결함을 찾아내는 과정이니까요. 발견된 결함에 대해 수정 작업을 거치는 디버깅은 개발자분들이 진행하시는데, 그럼에도 불구하고 결함은 계속 등장합니다....
이것이 어떻게 보면 개발자에게 테스팅 업무를 몰아주면 안 되는 이유입니다. 너무 귀찮..... 아니, 관점의 차이가 생기기 때문이죠 ㅎㅎ
테스트 과정의 범주가 워낙 넓기에, 개별적으로 프로그래밍 언어로 작성된 코드의 실시간 분석을 실행하는 것도 테스트 과정으로 볼 수 있습니다.
하지만 전문 테스팅이라 하면 보통은 실행 빈도가 많고 분기나 조건마다 꼼꼼한 서류 작업을 거쳐 심사하는 테스트를 의미합니다. 프로그램이 돌아가냐 안 돌아가냐 차원의 업무가 아니죠. 이는 프로젝트 진행 과정 중 필수로 들어가야 합니다. 많이 복잡하죠?
동작을 실행하여 결과를 관찰해 보면 정말 의도한 결과대로 시스템이 동작하는지 꼼꼼히 평가해야 하기에 업무가 좀 더 진화해 버린 것이죠.
프로젝트 하나 제대로 진행하기 많이 힘드네요. 각자의 영역에서 최선을 다하고 계시는 엔지니어 분들이 참 존경스럽습니다 :)