QA에서 받은 목록에는 버튼 간격, 빈 상태 문구, 로그인 복귀, 날짜 표시처럼 서로 달라 보이는 항목이 많았다. 처음에는 위에서부터 하나씩 고치면 된다고 생각했다. 몇 건을 처리하자 같은 원인이 다른 화면에서 반복되고 있다는 게 보였다.
버그 목록은 실패 사례의 모음이면서 문서에 적히지 않은 제품 규칙을 보여주는 자료였다.
증상보다 기대 규칙을 적었다
“화면 A에서 버튼이 보인다”를 그대로 수정하면 화면 B에서 같은 문제가 남았다. 각 항목을 현재 동작, 기대 동작, 적용 범위로 바꿔 적었다.
증상: 계좌가 없는데 주문 버튼이 활성화됨
규칙: 주문 가능한 계좌가 없으면 모든 진입점 비활성
범위: 메인, 차트, 빠른 주문 팝업
규칙으로 바꾸니 함께 확인해야 할 화면과 코드 경계가 생겼다.
공통 원인과 개별 예외를 구분했다
다국어 레이아웃 문제 여러 건은 공통 버튼 컴포넌트에서 해결할 수 있었다. 반면 같은 빈 상태라도 계좌 없음과 조회 결과 없음은 다음 행동이 달랐다. 무리하게 한 문구와 동작으로 합치지 않았다.
수정 전에는 관련 항목을 묶고, 공통 파일을 바꿀 때는 목록에 없던 기존 화면 회귀도 확인했다.
같은 증상이더라도 원인이 다른 항목은 억지로 한 수정에 넣지 않았다. 예를 들어 버튼 비활성은 권한 규칙 문제일 수도 있고 화면 초기화 순서 문제일 수도 있었다. 재현 조건과 로그가 다른 경우에는 별도 원인으로 남겼다. 목록을 예쁘게 묶는 것보다 수정 범위를 정확히 잡는 편이 중요했다.
재현 조건을 테스트로 남겼다
환경, 계정 상태, 화면 진입 경로, 동작 순서, 기대 결과를 짧게 정리했다.
조건: 활성 계좌 0개
경로: 로그인 -> 메인 -> 빠른 주문
기대: 주문 버튼 비활성, 계좌 생성 안내
확인: 재로그인·언어 변경 뒤에도 동일
수정 직후 한 번 성공하는 것보다 상태가 바뀐 뒤에도 규칙이 유지되는지 봤다.
검증 결과에는 통과 여부만 쓰지 않고 어떤 빌드와 조건에서 확인했는지를 남겼다. 자동화하기 쉬운 데이터 변환은 테스트로 옮기고, 화면 크기나 문구 균형처럼 사람이 봐야 하는 부분은 대표 조합을 정했다. 같은 항목이 다시 들어왔을 때 과거 수정의 증거를 찾을 수 있었다.
QA는 개발 뒤의 검사가 아니었다
예전에는 구현이 끝난 뒤 잘못된 부분을 찾는 단계로만 생각했다. 여러 항목을 분석하면서 QA 사례가 요구사항의 빈틈과 코드 경계의 약한 부분을 알려준다는 걸 배웠다.
그 뒤 버그를 고칠 때 해당 줄만 바꾸지 않고 어떤 규칙이 깨졌는지 먼저 말로 적는다. 규칙을 이해하면 비슷한 문제를 한꺼번에 막을 수 있고, 예외가 필요한 곳도 더 분명해졌다.