개발자와 QA엔지니어와의 협력

프로젝트가 시작되고, 막바지에 이르게 되면 정신없이 마감일에 맞추다 보니, 그동안 못 보던 버그들이 생성된다.
생성된 버그들을 수정하는 과정에서 품질을 향상시키려는 QA엔지니어와 프로젝트 기간내내 지쳐버린 개발자사이의 보이지 않는 갈등이 존재할 가능성이 높다.


QA업무는 품질을 향상시키고, 고객에게 보다 나은 양질의 소프트웨어를 만드는 것에만 책임지는 것이 아니라, 소프트웨어의 버그를 미리 발견하여 유지보수를 최대한 적게 하는데 목표를 두고 있다.
이 과정에서 자연스럽게 개발자에게 품질의 생산성 및 성능을 체크하고 그 결과를 보내며 스트레스를 줄 수 있는 여지가 있다. 또한, 테스트를 진행하기 위해서 개발자에게 일을 더 주기 위해서가 아니라 (over burden), 나중의 일을 덜 하게 하기 위해서 QA를 하고 있음을 자주 인지시켜야 한다.


특히, 자존심이 강한 개발자는 white box 테스트를 위해서 필요한  자신의 코드를 주지 않으려 하는 경향이 있다.
이 때는 개발자에게 생산된 코드는 개개인의 소유가 아니라 회사의 소유임을 알려주고 미리 문제를 발견하기 위함이라는 것을 밝혀야 한다.


문제의 소지를 줄여서 최대한 개발자의 자존심을 상처를 주는 행위가 있어서는 안되며, 소프트웨어 공학적인 추가적인 교육이 절실히 필요하다. 개발자는 자신의 코드를 형상관리가 가능하도록 할 수 있도록 툴을 가져야 한다. 오픈소스(opensource) 형상관리 툴 혹은 웹을 이용하여, 소스를 항상 팀원 혹은 QA개발자가 항상 볼 수 있도록 하여야 하며, 릴리지를 할 떄는 반드시 형상관리가 가능하도록 해야 한다.


일부 개발자들은 자신의 코드가 완벽하다라는 환상을 가지고 있으며, 언제든지 문제가 일어 날 수 있는 코드임에도 불구하고 남에게 문제의 소지를 넘기는 경우가 있다. 이럴 경우의 QA엔지니어는 재현 가능한 시나리오 혹은 로그를 통해서 개발자들에게 문제를 알리고 해결이 가능하도록 알려줘야 한다.


개발자들 특성상 자신이 생성한 코드가 아니면, 나 몰라라하는 경향이 있다. QA엔지니어는 정확하게 문제가 어디서 일어나는지를 파악할 수 있도록 한다.


임베디드 자바프로그래밍을 하는 A 개발자는 그동안 써왔던 코드의 품질이 없다고 생각하고 있었다. 항상 써왔던 코드를 복사 하고 붙이기 (copy & paste)를 하고 개발하였다. 이후 QA엔지니어가 NullPointerException의 영향으로 메모리 릭이 생겼음을 발생하고 리포트를 하였지만, 로그를 볼 줄 모르는 A개발자는 문제를 풀지 못하고 있었다. 즉, pc환경에서의 에뮬레이터에서는 문제가 없었다고 생각했지만, 실제 임베디드 시스템내에서의 특정 시나리오에서는 문제가 생기는 것을 발견하고, 자신의 잘못을 인정하고 코드를 수정하였다.


개발자의 코드는 개발자가 창조한 물품(product)이며, 회사 소유의 자산이다. 이 품질을 높이기 위해서 추가적인 혹은 변경한 코드를 QA엔지니어가 요구할 수 있다.
이런 의사소통(feedback) 과정을 통해서 회사 소유의 자산의 품질을 높여야 하며, 보다 견고한 품질 향상을 위해서 같이 개발자와 QA엔지니어가 협력해야 할 것이다.