[QA-TIL] 엔지니어와 개발자

이 주제는 QA엔지니어에게도 개발자에게도

조금은 민감한 주제가 될 수 있다.

일부 개발자들은 QA-엔지니어라는 명칭으로

거창하게 이야기 하는 것 자체를 싫어한다.

 

왜?

"QA와 개발자는 자주 싸움이 나기 때문이다."

사실 이부분은 굉장히

자연스러운 일이라고 할 수 있다.

 

QA와 개발자는 같은 목표인

제품의 좋은 품질을 지향하지만,

역할과 그 접근 방식자체가 다르기 때문에

의견의 대립이나 충돌이 생길 수 있기 때문이다.

 

그래서

보통 QA-엔지니어 면접을 볼때

가장 중요하게 보는 부분이

갈등 상황에 대한 대처이다.

 

물론, 개발자도 갈등 상황에 대한 대처를

생각보다 크게 점수를 준다.

 

QA-엔지니어가 개발자의 실수나

어떠한 결함을 지적하는 역할을 하다보니

개발자 입장에서는 자연스럽게

방어적인 태도가 나올 수 있다.

 

그래서

QA가 결함을 발견하면, 

개발자는 책임을 지게 되는

큰 압박감을 느낄 수 밖에 없으며

개발자 입장에서는 당연하게도

QA가 아주 사소한 결함 조차도 과하게 부풀린다거나

현실적으로 기한을 고려하지 않고 요구한다거나 등등

이런식으로 느낄 수밖에 없기 때문에 개발자의 입장에선

아무래도 QA가 아니꼽게 느껴질 수 있다는 것이다.

 

그렇다고 해서

모든 개발자가 그렇게 느끼는건 아니다.

 

QA가 기술적이고 엔지니어라는

이 언어적인 접근을 강조할 때

일부 개발자들은 "테스트와 개발은 다르다." 라며

엔지니어 라는 용어를 과장된 표현으로 여길 수 있다.

 

게다가

QA가 기술적인 자동화나 성능 테스트보단

기본적인 메뉴얼 테스트만 수행한다고 느껴지면

이런 반발심이 더욱커질 수 있다는것이다.

---

"QA와 개발자와의 갈등은 어떻게 풀어나가는가?"

이 주제의 가장 중요한 부분이다.

첫번째로 공동의 목표를 생각해보는것이다.

QA와 개발자 모두 제품의 성공을 기원하고 있다.

공동의 목표가 있으니 이걸 항상 기억하는게 좋다.

 

두번째로 커뮤니케이션을 좀더 강화하는거다.

QA는 결함을 보고 하면 보다 명확하게 설명하고

재현 가능한 단계를 제공을 해야하는거다.

 

개발자는 결함 보고를 가능하다면

방어적인 태도로 받아들이지 말고,

되도록 건설적인 피드백을 요청하는 태도를

가질 필요가 있다.

 

세번째로 협업 도구를 사용하는거다.

QA의 협업 도구는 많은데,

필자는 "Jira"를 주로 사용했다.

 

이 외에도 협업 툴로는

"Jira", "Trello", "Asana" 등과 같은 협업 도구를

효율적으로 활용해서 결함과 문제를

조금 더 투명하게 관리하면,

책임 소재와 우선순위 갈등을

최대한 줄여볼 수 있다는 것이다.

 

네번째로는 QA의 기술력을 더욱 강화시키는 거다.

QA가 단순하게 결함을 발견하는것 뿐만 아니라

자동화 테스트를 진행하거나

성능테스트를 진행한다거나

코드를 이해해서 기술적인 관여도를

높이게 된다면 생각보다 개발자들에게서도

조금은 인정을 받을 수도 있다.