‘테스트 너머의 QA 엔지니어링’ 책 리뷰

ℹ️ 책 정보

 

테스트 너머의 QA 엔지니어링

저자 : 김명관
제목 : 테스트 너머의 QA 엔지니어링
출판사 : 제이펍
출판 연도 : 2025년 1월 2일

* 해당 글은 책에서 감명 깊었던 부분을 정리하고 제 의견을 덧붙인 공부 및 회고 목적의 비상업적 기록입니다. *

📌 해당 책을 추천할 만한 대상

해당 책은 훌륭한 QA 엔지니어가 되기 위해 어떤 툴을 사용할 줄 알아야 하는지, 어떤 로드맵과 기술적인 스킬을 갖춰야 하는지에 대한 내용보다는 훌륭한 테스터, QA 엔지니어가 되기 위해 갖춰야 할 마음가짐, 행동에 관한 저자의 개인적인 이야기를 담은 책이다. 따라서 QA 엔지니어 직무를 희망하는 취준생, 현업자들이 가볍게 읽을 수 있는 책인 것 같다. 부록으로 QA 직무에서 자주 사용하는 툴, QA를 위한 커뮤니티에 대한 내용을 담고 있다. 이 또한 본인에게 많은 도움이 되었다.

📌 소프트웨어 테스터와 QA 엔지니어의 차이

소프트웨어 테스터
~> 소프트웨어 품질 보장을 위해 전문적으로 테스트를 수행하는 자
~> 테스터로서 성장에 한계는 없다. 만약 작성된 TC를 수행하는 단순한 기능 테스터로 머문다면 성장에 금방 한계가 찾아온다.
QA 엔지니어
~> 좀 더 넓은 영역에서 품질 업무를 수행하는 자로, 테스트를 통해 버그를 발견하는 것을 넘어 품질을 위협하는 요소를 사전에 예방하는 자
~> 품질을 위한 목적으로 개발 지식을 익혔을 때 더 좋은 대우를 받는다.
~> 현재 자동화 테스트는 설정해 둔 체크포인트가 정상작동을 하고 있는지 확인하는, 수통 테스트를 비롯한 QA 업무를 도와주는 도구 정도로 활용되는 것이 대부분이므로 테스트 자동화를 할 줄 몰라도 좋은 QA 엔지니어가 될 수 있다.
~> 기억과 고객의 입장을 동시에 대변할 수 있는 사람이 되는 것이 QA 엔지니어가 나아가야 할 목표다.

소프트웨어 테스터와 QA 엔지니어는 연차나 숙련도에 따라 단계적으로 나아가는 직무, 상하관계를 가지지 않는다. 단지 어떤 자세로 품질 업무에 임하는가에 차이가 있다. 따라서 스스로가 가진 성향, 어떤 방향의 업무를 전문적으로 하고 싶은지 아는 것이 중요하다.

📌 QA 엔지니어로서 가져야 할 마음가짐과 행동

훌륭한 QA 엔지니어로 성장하기 위해서는 적극성, 호기심, 틀에 얽매이지 않는 사고, 테스팅 외 다양한 방면에서 제품을 바라보는 시각, 수많은 요소들에 대한 의문점을 가지는 태도, 문제에 대한 원인을 객관적으로 분석하는 기술, 인간과 업무에 대한 깊은 통찰력이 필요하다. 또한 테스트의 대상은 제품의 기능만이 아니며, 제품의 리스크는 반드시 기능 테스트로만 줄일 수 있는 것이 아님을 명심해야 하며, 가장 중요한 것은 본인의 직무에서 즐거움을 찾고 발전할 수 있는 노력을 게을리하지 않는 것이다.

완성도와 품질은 QA 혼자만의 몫이 아니며, 모든 구성원들이 함께 노력하며 달성해야 하는 공동의 목표다. 품질에 있어서 QA 엔지니어 모든 것을 알 수 없고 완벽할 수 없기 때문에 다양한 사람들로부터 피드백을 받아 제품의 약점을 채워나가야 한다. 즉, QA 엔지니어에게 다른 구성원들의 전문적인 지식과 협조가 반드시 필요하다. 이때 품질을 위해 한 치의 양보도 하지 않는 태도는 오히려 품질을 악화시키는 결과를 가져온다. 따라서 반드시 모든 프로세스를 100% 지킬 것을 요구하는 완고한 태도는 구성원들의 반감을 사게 되어 오히려 테스트의 효율이 떨어진다는 것을 명심하자.

좋은 QA 엔지니어가 되기 위해서는 제품 및 개발자와 완벽한 거리를 유지해야 한다. 즉, 품질 강화 활동은 제품에서만 이뤄지는 것이 아니라 사람 관계에서도 이뤄질 수 있다는 것을 명심해야 한다. 이는 QA 엔지니어로서 본분을 다한다는 마음을 가지면 더 쉽게 달성할 수 있을 것이다.

품질 관리를 위해서는 제품 개발 과정 안에서 함께하되, 동시에 프로젝트를 객관적으로 바라볼 수 있는 눈이 필요하다. 따라서 QA 엔지니어는 소수의 지식을 깊게 아는 것보다 방대한 지식을 얕게 알되 언제든 그것을 파고들어 적용할 수 있는 기술이 필요하다. 또한 QA 엔지니어는 제품 및 테스팅에 관한 지식뿐만 아니라 품질을 저해하는 요소들에 대해 넓은 시야를 가질 필요가 있다. 더 나아가 다양한 분야에 대한 학습이 필요할 수도 있다. 이를 통해 평소에 하던 기능 테스트, 비기능 테스트는 꽤나 좁은 범위의 품질 강화 활동임을 알 수 있다.

QA 엔지니어는 기업 내에 존재하는 또 다른 고객이다. 기업 내에 존재하는 고객이 되기 위해서는 기업, 동료, 고객 세 집단의 이해관계 사이에서 모든 대상에게 최고의 만족을 제공해야 한다. 이를 위한 생산성과 완성도 사이에서 적당한 교차점을 찾는 것이 QA 엔지니어가 취해야 하는 태도에 해당한다.

버그를 예방하기 위한 마인드셋의 시작은 ‘테스트 단계에서 많은 버그를 찾아내겠다‘라는 목표에서 벗어나 ’테스트가 시작되기 전까지 리스크에 기반하여 치명적인 버그를 미리 제거하겠다‘는 목표를 가지는 것에서 시작한다. 또한 ‘버그가 이미 발생한 뒤에 버그를 많이 발견하려 하는 것’이 아닌, ‘버그가 어디서, 어떻게, 왜 발생하는가‘와 같이 더욱 근본적인 원인과 해결책에 대해 고민해야 한다.

자신의 경험을 공유하는 것은 자신의 경험과 역량을 알리는 것에 있어 의미도 있지만, 제품 품질 향상도를 알려주는 하나의 장치가 되기도 한다. 유독 QA 엔지니어에게 성과에 대한 고민이 생기는데, 이는 좋은 QA 엔지니어가 되기 위해 어떤 종류의 목표와 성과를 측정해야 하는지에 대해 명확하게 알지 못하는 것이 이유에 해당한다. QA 엔지니어로서의 성과를 나타낼 때 단순히 ‘QA 수행’이라고 기술한다면 어떤 성과를 이뤄냈는지 알 수 없다. 따라서 QA 엔지니어는 자신의 성과를 입증하기 위해 더 많은 데이터를 활용해야 하는데, 단순히 버그의 개수를 지표로 삼기보다는 얼마나 치명적인 버그를 어떻게 발견하였는지 설명하거나, TC를 개선한 사례로부터 테스트가 얼마나 효율적으로 개선되었는지 데이터를 도출하여 좋은 인사이트를 공유하는 것이 더 매력적으로 보일 것이다. 이 외에도 자신이 보유하고 있는 역량에 대해 소개할 때는 해당 역량이 품질 관점에서 어떤 도움을 줄 수 있기에 갖추게 되었는지, 실제로 얼마만큼의 개선을 이뤄낼 수 있었는지를 중점으로 작성해야 한다. 이는 제품의 품질 향상에 깊은 연관이 없는 역량은 QA 엔지니어에게 큰 의미가 없기 때문이다. 이때 성공이나 실패 사례만을 늘어놓기보다 다양한 시도로부터 내가 무엇을 배웠는지 정리하는 것도 중요한 포인트에 해당한다.

📌 기록해두고 싶은 지식

Test Case
~> TC는 처음 보는 사람이라도 누구나 쉽게 따라 할 수 있도록 상세하게 작성하는 것이 좋다.
체크리스트
~> 체크리스트는 Test Case와 목적이 다르다는 것을 명심해야 한다.
~> 체크리스트는 간단하고 빠르게 수행할 수 있도록 작성하는 것이 좋다.
~> 체크해야 할 항목의 목적과 기대 결과를 간단한 한 줄로도 알아볼 수 있게 작성해야 한다.
~> 가장 중요한 체크포인트와 기대 결과는 반드시 포함되어야 한다.

ad hoc 테스트
~> 공식적인 테스트 준비 작업 없이 공인된 테스트 설계 기법을 적용하지 않고, 예상 결과를 사전에 정의하지 않고, 자의적이고 임의적으로 실행하는 비공식 테스트의 한 기법
탐색적 테스트
~> 테스트 설계를 능동적으로 제어하고, 새롭게 더 나은 테스트를 설계하기 위해 테스트를 수행하는 동안 얻은 정보를 활용하는 비공식적인 테스트 설계 기법

📌 QA 직무가 저평가받는 이유

QA 직무를 희망하는 취준생에게 주위에서 만류했던 것과, 현재 QA 직무에서 일을 하고 있는 현업자가 본인의 직무를 스스로 의심했던 것은 QA가 어떤 직무인지 명확히 알지 못했기 때문이라고 생각한다. 이는 QA 엔지니어의 역할이 추상적으로 느껴질뿐더러, QA 엔지니어의 역할에 대해 체계적인 학습 경험이 없다는 사실과, QA 엔지니어끼리의 정보 교류가 활발하지 않은 것이 주요한 이유 중 하나일 것이다. 이러한 사실로 인해 기존에 QA 직무에서 일을 하고 있는 현업자들은 편향된 사고에 갇혀 자신의 주위에서 일어나는 현상으로만 QA 직무를 판단하게 되고, 버그를 조기에 발견하여 제품의 리스크를 줄이는 목적을 갖는 테스트가 QA 직무를 잘 모르는 사람들에게는 테스트가 그저 ‘제품이나 기능을 잘 만들었나 확인하는 활동’ 정도로 인식된다.

따라서 테스트를 설계하는 것과 기능, 비기능 테스트를 수행하는 것만이 품질을 개선하는 일이 아니라는 사실을 전달하여, 모든 구성원이 품질에 대한 책임을 가지고 있으며, 누구나 품질을 위한 활동을 할 수 있다는 사실을 널리 퍼뜨려야 한다. 가장 손쉽게 시작할 수 있는 활동은 품질에 대한 의지를 가진 구성원들에게 품질과 테스트에 대한 가벼운 지식을 전파하여 각자의 팀 내에서 해당 지식이 계속해서 전파되는 것을 기대할 수 있다. 이러한 선순환을 통해 더 많은 사람이 품질에 관심을 갖게 되고, QA 엔지니어는 더 많은 사람에게 테스트와 품질에 대해 알려줄 기회가 올 것이다. 이를 통해 많은 구성원을 대상으로 세미나 또는 세션을 진행할 수 있고, 나아가서는 기능 테스트에 조금씩 동참시킬 수도 있을 것이다.

가장 분명한 사실은 자신의 직무에 대한 높은 자부심을 갖는 것인데, 이러한 이유는 자부심은 곧 적극적인 활동을 할 수 있는 기반이 되기 때문이다. QA 현업자들이 직무에서 가치를 찾지 못하고 방황하는 이유는 개발된 제품을 테스트만 하기에도 바쁜 현실과 주위 테스터, QA 엔지니어에 대한 잘못된 인식이 자신의 직무에 대해 스스로 오해하도록 만들기 때문이다. 많은 신입, 1인 테스터, QA 엔지니어의 고민을 통해 이들에게 가장 절실하게 필요하다고 느낀 것은 본인 스스로가 테스터와 QA 엔지니어에 대한 명확한 인식과 소신을 가지는 것이다.

💡 감명 깊었던 문구

“우리는 일을 하며 비단 버그뿐만 아니라 많은 실수를 한다. 그것에 매몰되어 계속 자책하고 괴로워한다면 스스로에게 하나의 장애물을 설치하는 것과 같다. 실수에 괴로워하지 말고 오히려 반대로 생각해 자신이 성장할 수 있는 수단으로 이용하자.”
~> 본인에게 가장 필요한 마음가짐이다. 사람은 완벽할 수 없다. 실수는 성장을 위한 하나의 단계이며, 실수에 얽매이지 말고 이를 이용하자.

“내가 나를 알리지 않는다면 누구도 나를 알아주기 어렵다는 것을 명심해야 한다.“
~> 내가 한 성과를 알리지 않고, 기록하지 않는다면 그 누구도 알아주지 않는다. 인간은 생각보다 타인에게 관심이 없으며, 인간의 기억력은 생각보다 좋지 않다는 사실을 기억하자. 그렇기 때문에 본인의 가치를 알리기 위해 적극적으로 알리고, 기록하고, 소통하고, 끊임없이 탐구하고, 공부하자.