프론트로서 취준하는건 어떠신가요?
•
부트캠프를 수료하고 커리어지원을 기다리는 중이에요. 하지만 부트캠프가 큰 도움이 되지는 않는 것 같고, 실질적인 지원도 부족한 것 같아요.
QA로서의 직무란?
•
개발자와 소통할때 어려움이 있었나요?
◦
지금까지 약 100명 정도의 개발자들과 일해봤는데, 다행히 의사소통에서 큰 어려움은 없었어요. QA 전용 스터디를 찾기는 어려웠지만, 항상 스펙이나 버그에 대한 근거를 가지고 업무에 임했기 때문에 충돌을 방지할 수 있었어요.
•
QA동료들에게는 트러블이 없었나요?
◦
심각도를 잡을때 크리티컬 이외에 애매한 사항들은 동료들과 얘기를 나누는 편입니다. 주변에 개발자들이 다수이고 주변에 QA는 없어 소통하는겸 참석을 했습니다. 가끔 있는 갈등 상황은 대부분 의견 충돌에서 비롯되는 것 같아요.
•
사전 조건들을 명확하게 재현해야 개발자들이 더 쉽게 버그와 원인을 찾아 해결할 수 있는 것 같아요. 특히 디바이스별로 특수한 상황일 때는 더욱 세밀한 커뮤니케이션이 필요하죠.
•
기획 문서를 먼저 확인하고 TC를 작성해요. 근거가 될 만한 문서를 만들고 재현 조건들을 티켓으로 등록하고 있어요. 개발자들에게 받기보다는 전달하는 경우가 더 많은데, 제품 출시 전에는 피그마를 참조하고 출시 후에는 TC를 개선하며 업데이트하고 있어요.
•
제품 출시 이전에도 tc를 작성하시는군요
◦
개발자들이 먼저 tc를 전달해주신적도 있었고, 기획서를 먼저 참조해서 작성해본 적도 있었어요.
•
백엔드 개발자들은 qa에게 어떤 걸 전달하나요?
◦
먼저 staging 서버를 기반으로 전 tc를 작성해요. 버그면 해결해주고 애매하면 소통을 통해 해결하려해요. 되려 문제를 일으키는 사람들이 아니라, 제품의 문제를 먼저 찾아주는 고마운 사람들이라 트러블은 없었어요. 고객들에게 직접 컴플레인이 들어오는 것 보다 사전 방지를 하는편이 훨씬 좋습니다. 새벽에 문제 터지는 것 보다는 나아요.
◦
QA분들이 있고 없고 차이가 명확하게 느껴졌어요. 좀 더 제품 보완이 탄탄해지는 듯 합니다.
•
자동화 툴이 있나요?
◦
자동화 스크립트를 짜시는 분들고 계신다. 10년차 이상되면 기한서 작성해서 테스트 자동화를 만들 수 있는 환경을 구축해서 물품 구비, 라이선스를 구매하는 등 준비했던 것 같아요.
◦
우대사항에 자동화에 대한 니즈가 있긴 했는데, 필수 사항이나 매우 활성화 되어 있지는 않은 기술인 것 같아요. 필요성은 있다고 느낍니다.
◦
구글 플레이스토어 자동화로 돌렸을때 안되면 떨어지는 경우도 보긴 했어요.
•
자동화되면 어떤 업무로서의 효과가 있나요?
◦
인력 감축 효과는 있을 수 있지만, 현실적으로는 한계가 있어요. 개발자가 테스트 코드를 아무리 꼼꼼하게 작성해도 찾지 못하는 버그가 있기 마련이에요. 특히 본인이 작성한 코드는 예상 시나리오로만 테스트하게 되고, 자동화는 단순한 부분만 가능해요. 실제 사용자들은 예상치 못한 방식으로 제품을 사용하기 때문에 결국 수동 테스트가 필요해요. 완벽한 제품은 없다고 봐요.
•
디자인 QA는 어떻게 관리하시나요?
◦
디자인 관련된 건 별도 티켓으로 관리하고 있어요. 피그마와 실제 제품을 비교해서 작성하는데, 픽셀 단위까지는 확인하지 않고 있어요.
•
QA를 전문으로 하는 전공이 있나요?
◦
컴퓨터공학과는 대부분 개발자 위주로 교육하고 있어요. 저는 개인적으로 버그를 찾는 일이 매우 흥미롭더라고요.
•
국내에는 QA의 인식이 아직은 낮은 것 같아요. 채용 직무는 QA인데 정작하는일이 테스터인 경우도 있었어요.
국내 교육과정에서 코딩 교육이 보편화된 것에 대해 어떻게 생각하시나요?
•
직업체험 수준의 맛보기 정도라고 생각해요. 개발자의 수가 적다기보다는 실력 있는 개발자가 부족한 것 같아요. 일반 사무직들은 개발 비용을 이해하지 못하는 경우가 많고, 기존 시스템의 변화도 꺼리는 것 같아요.
연구소의 인력 변동이 많은 이유는 무엇일까요?
•
회사마다, 사람마다 다르고 개발자들만의 특성도 있죠. HR의 채용 방식에 따라서도 많이 달라지는 것 같아요. 일반 사무직 채용과 같은 시스템으로 개발자를 뽑다 보니 이직을 꺼리는 경우도 있어요.
일정 지연 시 QA는 어떻게 진행하시나요?
•
QA도 계획된 일정에 맞춰 진행해요. 크리티컬한 이슈가 발견되면 개발팀에 반드시 전달하고, 일정 지연이나 작업 범위는 팀장급에서 결정하고 있어요.
UX 관련 피드백도 QA 범위에 포함되나요?
•
사람마다 다르지만, QA 역할에 포함된다고 봐요. 조금이라도 이상하다 싶은 부분은 티켓으로 기록해두고, 우선순위에 따라 백로그로 관리하고 있어요.
개선사항의 근거는 어디서 얻으시나요?
•
정책 문서나 피그마를 참고하면서 보완하려고 해요. PM들이 많이 제안하기도 하지만, 경력을 바탕으로 설득하려고 해요. 로그를 분석해서 이탈률을 측정하거나 지표를 활용해서 설득하기도 하죠.
기술적 난이도 차이로 인한 마찰은 어떻게 해결하시나요?
•
주로 PM이 조율하지만, 개인의 설득 능력에 따라 달라져요. 유사한 서비스 사례를 근거로 설득하는 경우가 많은데, PM이 대신 조율하는 경우가 많아요. 참고할 레퍼런스가 없으면 합의가 어려울 수 있어요.
연봉 협상은 어떻게 진행하시나요?
•
보통 CTO와 먼저 협의한 후 HR과 협상을 진행해요. 특히 백엔드는 시각적으로 성과를 보여주기 어려워서 협상이 더 힘들어요. 비용 절감 측면에서 접근하려 해도, 단순 리뉴얼만 했다면 설득이 쉽지 않은 것 같아요.