우아한 형제들에서 운영하는 기술블로그 = 우아한 기술블로그 에서 QA란 무었인가에 대한 글을 보고 작성한 내용이다.
QA != 통합테스트
필자는 QA란 통합테스트가 아니다! 라는 말로 글을 시작한다. 나도 인턴을 하기 전에는 QA = 테스트 와 동일상에 놓고 생각을 했었다. 학교에서 배운 기능테스트, 비기능테스트, 단위, 통합 ... 이런 테스트들이 QA란 말을 들으면 가장 먼저 생각나는 내용들이었다.
실제로 첫 인턴을 했던 회사에서(품질경영실) 테스트케이스를 작성하고 이를 테스트하는 일을 하시는 분은 본적이 없었다.
다만, 내 책임님이 대외 프로젝트를 담당하시는 분이었기에 품질점검 체크리스드를 가지고 대외에서 하는 프로젝트를 검수하는 외근을 나가시는것을 보았었다. 체크리스트들의 내용들은 산출물들이 잘 작성되어있나, 파일들이 올바른 위치에 존재하나,... 등과 같이 실제 소프트웨어의 기능에 직결되는 내용들보단, 프로젝트 자체의 신뢰도를 높이기 위한 점검내용들이 주였던것 같다.
그렇기에 필자가 말하는 QA != 통합테스트 라는 말이 와닿았던것 같다.
유관부서의 QA에 대한 몰이해
상황 1. (한 달도 넘게 진행된 프로젝트 내용을 미리 공유받지 못한 상황에서) "다음주 오픈 예정인데 일주일만 QA해주세요."
기능테스트만 하더라도 몇일은 테스트 대상과 범위를 분석하는데 거의 모든 시간을 소모하게 된다.
(상황1 +) 상황2. "QA했는데 왜 운영 이슈가 계속 나와요? (QA한 거 맞나요?)"
짧은 기간 안에 파악한 내용으로는 정말 어떻게 동작하는게 맞는 방향인지 알기 어려워 국지적으로 확인만 하는 체커(Checker)에 지나지 않을 수 밖에 없다.
상황 3. QA담당자가 프로젝트 킥오프 회의와 회고 회의들에서 누락되는 상황.
킥 오프 회의에서 이번 프로젝트가 어땠는지에 대해 듣지 못한다면, 다음 어떤 활동을 할 지 발전이 없을수 있다.
QA가 사용하는 기술적 지식들
- Appium
- Selenium
- SiteSpeed.io(+yslow)
- postman-newman
