안녕하세요. 멘토님. SW QA 쪽에 관심을 가지고 취직을 준비하는 취준생입니다. 현재는 SW QA 직무를 알아가고 있고, 어떤 일은 하는지 어떤 문제가 있고 어떻게 해결해 나가는지 알고 싶어서 검색해서 정리하고 있습니다. 

공부를 하다 보니 ‘문제가 발생했을 때 SW QA 쪽은 문제를 어떻게 해결하고 있는지는 찾기가 어려워서 현직자분들은 어떻게 해결하고 계실지 궁금해서 질문드립니다.

 ©️Austin Distel

제가 찾아보고, 상상해 본 QA 직무에서 발생할 수 있는 문제는

1. 사용자가 제품에 대한 치명적인 버그같은 것을 발견했을 경우, 또는 시스템상 버그를 개선하기 어려운 일이 발생했을 경우 QA 현직자분들은 어떻게 대처하나요?

2. 기획팀과 개발팀, 경영진(?)과의 커뮤니케이션 문제가 발생할 때는 어떻게 해결하는지도 궁금합니다. QA에 대한 선입견(잘 모르면서 이것저것 들쑤시고 다닌다 같은..)이나 개발팀에서 결함의 시작적 차이(비기능, 사용성, 신뢰성 같은)등 과같이 커뮤니케이션 문제가 발생할 경우는 어떻게 해결하고 계신가요?

제가 적은 것 외에도 현업에서 발생하는 문제점이 있다면 알려주시면 감사하겠습니다. 부족한 질문 읽어주셔서 감사합니다. 

안녕하세요. 멘티님. 흥미로우면서 난도 높은 질문을 주셔서 제가 바로 답변을 드리지 못했네요. 이미 QA 직무에 대해 여러모로 고민하시고 어느 정도 정리가 되신 것 같아, 질의 주신 내용에 바로 답변을 달아 보겠습니다. 

사용자가 치명적인 버그를 발견했을 때 대처법은?

치명적인 버그라는 것은 산업도 메인 및 서비스에 따라 그 유형과 특징이 차이가 있습니다. 그리고 대책도 각양각색이지요. 몇 가지 예를 들어 보겠습니다. 

[CASE 1] 금융업 + B2C

본인은 금융권 여신 관련 시스템 개발 QA를 맡게 되었다고 가정합니다.  Live환경에서 여신 상품 기능 중 신용등급을 조회하여 적정 대출한도를 알려주는 기능이 있는데 신용등급이 최하위인데도 대출한도가 Max로 측정이 된다면 Critical 이슈가 되겠지요. 

이럴 경우엔 바로 내부적으로 이슈를 공유하고 운영팀에 즉각 상품 실행 중지를 시켜야 합니다. 개발팀에선 기능개선에 대한 안내문을 웹에 띄워야 하고요. 밤을 새워서라도 즉각 버그를 수정하여 운영환경에 반영해야 합니다. 

요즘 최신 시스템 아키텍처상으론 마이크로서비스 및 데브옵스란 것으로 구축 및 운영을 하게 되는데 이런 인프라가 있을 경우엔 더욱 유연하게 대응 가능합니다. 예로 위 사례와 같이 전체 시스템 운영을 중지할 필요 없이 관련 서비스 모듈만 중지를 시키고 버그 픽스 후 반영하면 되겠습니다. 보통은 서비스 기능별로 도커라는 가상의 서버를 운영하게 됩니다. 

[CASE 2] 제조업 + B2C

본인은 S 전자 무선 단말 개발팀 소속에 SQE로 입사하였다고 가정합시다. 내년도 출시 예정인 하이브리드 급 스마트폰 테스트 시 영하 10℃ 미만의 경우 액정에 결로가 생기면서 전원이 자동 오프되는 문제가 발생합니다. 이럴 경우 HW 신뢰성 문제로 Critical 이슈로 확인되면, QA는 제일 먼저 해당 상황에 대해 이슈리포트를 하게 됩니다. 

이슈는 1선으로 HW 설계팀으로 가게 되고 원인 분석 후 장애처리를 하게 됩니다. 만약 이런 이슈가 필드(사용자 단)에서 발견된 경우라면 공식적인 리콜 프로세스를 타게 되겠습니다. 그 책임은 QA를 비롯하여 개발팀 전체가 물게 되겠지요. 그렇기 때문에 대기업 같은 경우 매우 혹독한 신뢰성 테스트를 장시간에 걸쳐 진행하게 됩니다. 별도의 고온, 냉온, 먼지, 충격 테스트 등을 할 수 있는 랩실을 운영하고 있습니다. 

[CASE 3]  ERP + B2B

본인은 C사 ERP 전문업체 QA 소속이라고 가정합시다. 2020년 신규 ERP 솔루션을 구축형으로 납품을 진행했습니다. 그런데 고객사 중 Legacy 데이터베이스 중 호환이 되지 않는 시스템을 사용하여 연동이 되지 않는 문제가 발생했습니다. 이럴 경우 납품 자체가 취소 될 수 있는 심각한 이슈일 수 있으며 실제 필드에서 자주 발생할 수 있는 사례라고 볼 수 있습니다. 

해당 이슈가 필드에서 발생되지 않게 하기 위해서 물론 QA관점에서 다양한 DB환경을 고려하여 테스트 해보는 방법도 있겠지만 현실적으로 일정과 투입공수를 따져보면 막대한 투자를 해야되기에 불가능에 가깝습니다. 그래서 이런 문제는 사전에 사양(SPEC)정의를 메뉴얼과 홈페이지 상에 명확히 하는 것이 첫번째이며 개발팀에서 우리 솔루션의 확장성을 높이기 위한 연계모듈의 추가 개발이 지속적으로 뒷받침되어야 합니다. 

 ©️ThisisEngineering RAEng

기획팀과 개발팀, 경영진과의 커뮤니케이션 문제 처리법은?

QA는 어쩌면 개발의 방향성과 품질 수준을 제시하고 안내하는 조직내 컨설턴트의 역할을 포함한다고 볼수 있습니다. 초급 QA라면 어려운 숙제이겠지만 전문가로 성장하기 위해선 개발자들을 리딩할 수 있는 리더십을 스스로 길러내야 하겠습니다. 

더불어 중요한 스킬 중 하나가 커뮤니케이션입니다. 더 구체적으론 대면 대화 능력, 메일 작성능력, 이슈 식별 및 대응책 마련 능력, 고객가치 발굴 능력, 더 나은 기획/UX 방향 제시 능력, 결함 분석 및 보고 능력 등을 포괄 한다고 볼수 있습니다. 이외, 개발자들은 품질 특성에 대해 잘 이해를 못 하기 때문에 이런 부분을 안내 할 수 있는 교육능력까지 겸비한다면 좋겠지요. 단숨에 되지 않을뿐더러 조직에선 초보 QA에게 많은 것을 기대하지 않으니 너무 부담을 갖지 않으셨으면 해요.

질문에 답변이 됐을까요? 추가적인 문의 사항은 아래 메일로 문의 주세요. 감사합니다

답변을 굉장히 상세하게 해주셔서 정말 감사합니다. 여쭤보고 나서 직무를 시작도 안 한 상태로 해도 되는 질문인가 싶었는데 친절히 답변해 주셔서 감사합니다.