[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
필자가 국내 핸드폰 소프트웨어 개발 직종에 종사하면서, "이건 아닌데..."라고 생각한 부분이 몇가지 존재하는데, 그 중에 하나가 Test & Debugging Cycle에서의 문제점이다.
필자가 경험한 바로는 Test & Debugging Cycle에서의 업무는 다음과 같이 이루어 진다.
1. Test engineer(이후 TE)가 발견한 버그를 Issue Tracking system에 기록한다.
2. Engineer가 이를 보고 실제 재현을 해 본다.
3.1 문제없이 재현하였다면, 이게 정말로 버그인지 아닌지 확인한다.
3.2 재현에 실패했다면, TE에게 재현 방법을 물어보고, 3.1의 과정으로 간다.
4. 실제 버그가 맞다면, 수정에 들어간다.
그런데, 문제는 위의 과정에서 생산성을 저하시키는 일들이 필요이상으로 많이 발생한다는 것이다. 하나씩 살펴보자.
먼저, 1과 2사이를 보자.
보통의 경우 - 국내 업체 - Product Specification, User Interface Specification(이후 UIS)같은 문서들이 대부분 상당히 부실하게 작성되어 진다. 이 중에서 SW측면에서 보았을때, 특히 중요한 것이 UIS인데, Specification이라는 이름에 걸맞지 않게 허술하게 작성되는 경우가 대부분이다. 필자의 소견으로는, 기업이 이 부분에 크게 투자하지 않는 것 같다. SW를 경시하는 만큼 UIS도 경시하는 듯 하다. 따라서, TE입장에서는 무엇이 버그이고, 무엇이 버그가 아닌지 판단할 수 있는 확고한 근거가 없으므로, 그냥 본인이 이상하다고 생각하면 전부 버그라고 reporting하게 된다.
2와 3 사이의 경우, TE의 reporting미숙에서 오는 overhead가 상당히 크다. 개발자들은 bug report을 보고, 이를 어떻게 재현할 수 있는지 몰라서, TE에게 찾아가거나 혹은 전화로 다시 한번 확인하는 경우가 태반이다. 심지어는 "xxx를 하면 화면이 이상하게 보임." 이라고 기록된 어이없는 reporting을 본 적도 있다. 이는 TE의 역할에 대한 기업의 잘못된 정의가 가장 큰 원인이라고 필자는 본다.
보통 QA를 TE의 역할로 정의하는 업체가 많다. 물론, QA는 TE의 가장 중요한 역할 중 하나이지만, 국내의 경우 그 정도가 지나친 것처럼 보인다. 무슨 말이냐 하면, 오로지 bug를 찾아내는데만 TE의 역할이 집중되어 있다는 뜻이다. 보통의 경우, TE의 임금은 Developer에 비해 저렴하다. 그래서 TE라는 직종이 따로 생겼고 (만약 그렇지 않다면, developer가 TE의 역할을 같이 겸하게 되었을 것이다.) SW의 bug를 찾고 품질을 검증하는 역할이 주어졌다. 그렇다면, 상대적으로 비싼 비용이 드는 Developer의 시간을 절약하고 이 역할을 TE가 해 줄 수 있도록 해야하지 않겠는가? 따라서 debugging을 위해 developer를 support하는 것 역시 TE의 중요한 역할 중 하나가 되어야 하고, TE의 성과 평가 항목에 반드시 이 부분이 반영되어야 한다. 이때, 가장 기본적인 것이 bug reporting이다. TE는 bug를 재현할 수 있는 방법을 명확하게 기술해야 하고, debugging에 도움이 되는 정보를 추가적으로 기록해 줄 필요가 있다. 에를 들면 아래와 같다.
menu -> setting -> time & data -> 24시 format으로, 12:00를 setting하면 phone이 reset됨.
menu -> setting -> time & data -> 12시 format으로 12:00를 setting하면 정상 동작함.
menu -> setting -> time & data -> 24시 format으로, 11:00를 setting하면 정상 동작함.
이런 정도의 reporting은 상대적으로 비싼 비용이 들어가는 Developer의 시간을 상당히 절약시켜 줄 수 있다. 물론, 너무 상세한 reporting으로 인해 쓸데 없이 많은 시간이 소모된다면, 그것 역시 피해야할 것이다.
좋은 TE를 유지하는 일은 상당히 어렵다. TE라는 일 자체가 가지는 특성때문에, 좋은 TE는 빨리 다른 직종으로 이직하고자 하기 때문이다. 따라서, 어떻게 좋은 TE를 유지할 것이냐 또한 심각하게 고민해할 문제이다.
'Essay > Software' 카테고리의 다른 글
[Prog][Debug] irregular bug.... (0) | 2009.06.04 |
---|---|
[Essay] Overly optimistic schedule... (0) | 2009.04.01 |
[Dev] Clear description of outcome - submodule, subproject... (0) | 2009.02.15 |
[Dev] one persone under full responsibility for one time-critical-project (0) | 2009.01.21 |
[Prog] What is "good code"? (0) | 2008.11.22 |