QA 엔지니어

확인을 손으로 하는 사람을 두던 시절이 있었습니다. 배포 전날 목록을 받아 화면을 차례로 눌러 보고, 어긋난 것을 적어 넘기는 일입니다. 기능이 스무 개일 때는 이 방식으로 충분합니다.

기능이 쌓이면 이 방식이 먼저 무너집니다. 확인할 목록은 기능 수에 비례해 늘어나는데 사람이 쓸 수 있는 시간은 늘지 않습니다. 목록이 200개가 되면 한 바퀴에 이틀이 걸리고, 주 두 번 배포하는 팀에서는 확인이 배포 주기보다 길어집니다. 그때부터 사람은 목록을 줄이는 쪽으로 움직이고, 줄인 목록에서 빠진 자리가 사고로 돌아옵니다.

QA 엔지니어는 그 확인을 사람에서 코드로 옮기려고 생긴 역할입니다. 매번 같은 것을 눌러 보는 대신 눌러 보는 절차를 코드로 써 두고, 그 코드가 배포마다 저절로 돌게 만듭니다. 검증하는 사람이 아니라 검증 체계를 만드는 엔지니어라는 점이 이 자리의 성격을 정합니다.

하루가 밤에 돈 결과를 읽는 일, 새로 만드는 것의 확인 목록을 짜는 일, 그 확인을 코드로 옮기는 일로 채워집니다.

1. 아침에 지난밤 자동으로 돈 결과를 봅니다. 실패한 항목을 두 갈래로 가릅니다. 하나는 진짜 결함이고 다른 하나는 같은 코드에서 성공과 실패를 오가는 플레이키 테스트입니다. 뒤쪽을 방치하면 실패 알림을 아무도 믿지 않게 되므로, 이 분류가 하루의 첫 일이 됩니다. 스무 개가 실패했는데 열일곱 개가 불안정한 항목이면 남은 셋도 함께 무시됩니다.
2. 이번에 만드는 기능의 확인 목록을 짭니다. 정상 경로는 만드는 사람이 이미 밟아 보므로, 이 자리에서 적는 것은 주로 경계와 실패 경로입니다. 빈 값을 넣었을 때, 권한이 없는 계정으로 열었을 때, 중간에 연결이 끊겼을 때가 그런 자리입니다. 사용자 이름에 이모지가 들어갔을 때처럼 아무도 예상하지 않는 입력도 여기서 나옵니다.
3. 확인을 코드로 옮깁니다. 브라우저를 띄워 사용자가 하는 대로 밟아 보는 E2E 테스트를 쓰는데, 자주 확인하고 오래 살아 있을 경로만 옮깁니다. 화면 문구가 자주 바뀌는 자리를 코드로 옮기면 그 코드를 고치는 데 시간을 다 씁니다. 가입과 결제처럼 몇 년째 모양이 같은 흐름이 먼저 옮길 대상입니다.
4. 발견한 것을 등록하고 따라갑니다. 재현 절차와 기대한 동작과 실제 동작을 적고, 서비스에 끼치는 영향의 크기인 심각도를 붙입니다. 재현 절차가 비어 있으면 그 항목은 고쳐지지 않고 목록에 남습니다. 무엇을 눌렀고 무엇이 나왔는지를 순서대로 적는 일이 이 자리의 기본기입니다.
5. 주 단위로 체계를 봅니다. 테스트가 훑은 코드의 비율인 테스트 커버리지를 확인하고, 지난주에 나간 사고를 되짚어 어느 목록에 그 경로가 빠져 있었는지 찾습니다.

만드는 사람과 다르게 이 자리는 성공을 눈에 보이게 만들기 어렵습니다. 잘하면 아무 일도 일어나지 않고, 못하면 사고로 드러납니다. 그래서 막은 것의 수가 아니라 확인에 드는 시간과 사고 건수의 변화로 이 자리의 일을 봅니다.

가장 붙어 있는 상대는 개발자입니다. 경계 조건을 물어보고, 실패한 항목이 어디서 깨졌는지 함께 좁힙니다. 재현 절차를 적는 일은 이쪽이 하고 원인을 찾는 일은 그쪽이 하는데, 절차가 정확할수록 뒤쪽이 짧아집니다.

요구를 적은 프로덕트 매니저와는 확인 목록의 첫 칸을 맞춥니다. 이번에 하기로 한 범위가 어디까지인지를 모르면 무엇이 결함이고 무엇이 아직 만들지 않은 것인지 가릴 수 없습니다. 디자이너와는 구현이 시안과 맞는지 보는 검수를 나눠 맡습니다.

배포를 자동으로 돌리는 쪽과도 붙습니다. 써 둔 테스트가 배포 과정 안에서 자동으로 돌게 붙이는 일은 이 두 자리가 함께 정합니다. 어느 테스트가 실패하면 배포를 멈출지, 어느 것은 알림만 띄울지가 그 결정입니다. 전부 멈추게 걸어 두면 불안정한 항목 하나가 팀 전체를 세웁니다.

고객 지원과는 사고가 난 뒤에 만납니다. 사용자가 겪은 상황을 다시 만들어 보는 일이 원인 찾기의 시작이고, 그 재현이 되면 같은 항목이 확인 목록에 들어갑니다. 문의 한 건이 목록 한 줄로 바뀌는 경로가 이 자리를 지나갑니다.

"이 실패는 플레이키예요. 세 번 중 한 번만 깨집니다."

결함이 아니라 테스트 자체가 불안정하다는 판정입니다.

"이건 코드로 옮길 만큼 자주 확인하는 경로예요."

손으로 볼 것과 자동으로 돌릴 것을 가른 판단입니다.

"재현 절차가 없으면 고칠 수 없습니다."

등록만으로는 일이 넘어가지 않는다는 지적입니다.

페이지덱에서 확인 목록이 210개까지 늘어난 분기에 이 자리가 생겼습니다. 태오가 배포 전날마다 이틀을 확인에 쓰고 있었고, 그 시간이 새 기능을 만드는 시간을 먹고 있었습니다.

새로 들어온 담당자가 첫 두 달 동안 한 일은 목록을 자동으로 옮기는 것이었습니다. 210개 중 가입과 결제와 공유에 걸린 60개를 코드로 옮겨 배포마다 자동으로 돌게 했고, 나머지는 사람이 보는 목록으로 남겼습니다. 배포 전 확인에 드는 시간은 이틀에서 세 시간으로 줄었습니다. 사람이 보는 목록이 짧아진 만큼 그 목록을 꼼꼼히 보게 된 것도 함께 얻은 결과였습니다.

개발을 못 해서 맡는 자리로 보는 경우가 가장 많습니다. 화면을 눌러 보는 일이 겉으로 드러나니 그렇게 읽힙니다. 하지만 이 자리의 산출물 대부분은 코드입니다. 브라우저를 자동으로 조작하는 테스트를 쓰고, 그 테스트가 배포 과정에서 돌게 붙이고, 불안정한 항목을 찾아 고칩니다. 손으로 눌러 보는 부분만 보고 이 자리를 낮게 다루는 조직에서는 자동화가 진행되지 않고, 확인 시간이 계속 늘어납니다.

품질의 책임이 이 자리에 있다고 보는 것도 흔합니다. 이름에 품질이 들어가니 자연스러운 오해입니다. 그런데 이 자리가 할 수 있는 일은 이미 만들어진 것에서 어긋난 것을 찾아내는 것까지입니다. 사고가 났을 때 왜 못 잡았느냐고 묻는 조직에서는 목록이 방어적으로 길어지고 배포가 느려집니다. 물어야 하는 것은 그 경로가 왜 목록에 없었는지이고, 그 답은 대개 요구를 적는 단계나 설계 단계에 있습니다.