대부분의 사람들은 SDET라는 직함이 매뉴얼 테스터보다 자동으로 더 가치 있다는 것을 의미한다고 생각합니다.

SDET는 Playwright 스크립트를 작성합니다. SDET는 CI 파이프라인을 구성합니다. SDET는 페이지 오브젝트 (Page Objects)와 재시도 전략 (Retry Strategies)에 대해 이야기합니다. 매뉴얼 테스터는 화면을 클릭하며 버그 리포트를 작성합니다.

여러 팀에서 제가 목격한 진실은 다음과 같습니다. SQL Join을 작성할 줄 아는 매뉴얼 테스터는 SQL Join을 작성하지 못하는 SDET를 지속적으로 능가할 것입니다.

SQL이 마법이기 때문이 아닙니다. SQL은 UI가 보여주는 것이 아니라, 시스템이 실제로 무엇을 저장하고 있는지를 이해하는 가장 짧은 경로이기 때문입니다.

자동화 우선 사고방식의 문제점

저는 SDET들이 모든 버튼, 모든 드롭다운, 모든 에러 토스트 (Error Toast)를 검증하는 테스트 스위트 (Test Suite)를 구축하는 데 3번의 스프린트를 소비하는 것을 보았습니다. 그 스위트는 CI에서 통과합니다. 그 스위트는 스테이징 (Staging)에서 통과합니다. 그 스위트는 프로덕션 (Production)에서 통과합니다.

하지만 버그는 여전히 배포됩니다.

왜일까요? 테스트가 UI가 올바르게 렌더링되었는지는 확인했기 때문입니다. 데이터베이스가 실제로 올바른 레코드를 저장했는지는 전혀 확인하지 않았습니다. SDET는 데이터가 아닌 DOM 요소에 대해 어설션 (Assertions)을 작성했습니다.

반면, 매뉴얼 테스터는 간단한 쿼리 (Query)를 실행했습니다. 주문 상태가 'confirmed'여야 하는데 'pending'으로 되어 있는 것을 발견했습니다. 문제를 증명하는 정확한 SQL과 함께 버그를 보고했습니다. 개발자는 10분 만에 이를 수정했습니다.

이것은 매뉴얼 대 자동화에 대한 이야기가 아닙니다. 이것은 데이터 리터러시 (Data Literacy) 대 UI 집착에 대한 이야기입니다.

로케이터 (Locator)가 절대 줄 수 없는 SQL Join의 가치

Playwright 로케이터는 무언가가 화면에 있다는 것을 알려줍니다. SQL Join은 무언가가 사실이라는 것을 알려줍니다.

page.getByText('Order confirmed')를 작성할 때, 당신은 프론트엔드가 해당 단어를 표시하는지를 테스트하고 있는 것입니다. 백엔드가 실제로 주문을 확정했는지를 테스트하는 것이 아닙니다. 결제 게이트웨이 (Payment Gateway)가 성공을 반환했는지 테스트하는 것이 아닙니다. 재고가 감소했는지 테스트하는 것도 아닙니다.

SQL Join은 그 점들을 연결합니다.

SELECT o.id, o.status, p.status AS payment_status, i.quantity AS remaining_stock
FROM orders o
JOIN payments p ON o.id = p.order_id
...

단 하나의 쿼리가 당신에게 알려줍니다: 주문이 존재하고, 결제가 완료되었으며, 재고가 감소했다는 사실을 말이죠. 이것이 바로 완전한 엔드 투 엔드 단언 (end-to-end assertion) 입니다. UI는 필요 없습니다.

해당 쿼리를 작성할 줄 아는 매뉴얼 테스터는, 5분 동안 테스트 스위트 (test suite) 가 초록색으로 뜨는 것을 지켜본 SDET보다 5초 만에 시스템의 상태에 대해 더 많은 것을 알고 있습니다.

진정한 기술 격차는 자동화 대 매뉴얼의 차이가 아닙니다

그것은 데이터 문해력 (data literacy) 대 도구 유창성 (tool fluency) 의 차이입니다.

저는 Playwright 테스트를 단 하나도 작성하지 못하지만, 금융 대조 (financial reconciliation) 작업이 정확히 어떻게 작동해야 하는지 완벽하게 설명할 수 있는 테스터들을 코칭해 왔습니다. 그들은 어떤 테이블이 진실의 원천 (source of truth) 을 보유하고 있는지 알고 있었습니다. 어떤 조인 (join) 이 불일치를 드러낼지도 알고 있었습니다. 그들은 누군가 자동화 코드를 한 줄이라도 쓰기 전에 버그가 존재한다는 것을 증명할 수 있었습니다.

반대로, 저는 세 개의 브라우저에서 병렬 테스트 스위트 (test suite) 를 구축할 수는 있지만, 외래 키 제약 조건 (foreign key constraint) 이 무엇을 하는지는 말하지 못하는 SDET들과도 일해 보았습니다. 그들은 UI가 제대로 보인다는 이유로 통과되는 테스트를 작성했습니다. 그 아래의 데이터는 틀려 있었습니다.

결제 시스템이라면 어떤 사람을 원하시겠습니까? 의료 플랫폼이라면요? 픽셀 정렬보다 정확성이 더 중요한 곳이라면 어떤 쪽을 선택하시겠습니까?

구체적인 예시: 환불 흐름 (refund flow) 테스트

여기 흔한 시나리오가 있습니다. 사용자가 환불을 요청합니다. UI에는 "환불 처리됨"이라고 표시됩니다. Playwright 테스트는 환불 버튼을 클릭하고, 토스트 (toast) 메시지를 기다린 뒤 통과합니다.

하지만 환불은 실제로 결제 게이트웨이 (payment gateway) 에 도달하지 않았습니다. 데이터베이스에는 refund_status = 'failed'라고 표시되어 있습니다. 프론트엔드가 API 호출이 성공했다고 가정했기 때문에 UI는 단지 성공 메시지를 표시했을 뿐입니다.

UI만 테스트하는 SDET는 그 버그를 그대로 배포할 것입니다. 하지만 이 쿼리를 실행하는 매뉴얼 테스터는 이를 잡아낼 것입니다:

SELECT r.id, r.status, r.amount, r.error_message
FROM refunds r
WHERE r.order_id = 12345 AND r.created_at > NOW() - INTERVAL '5 minutes';

error_message 컬럼이 모든 것을 말해주고 있었습니다. UI는 이를 결코 보여주지 않았습니다. 테스트는 이를 결코 확인하지 않았습니다. 하지만 데이터는 결코 거짓말을 하지 않았습니다.

DBA가 되지 않고도 데이터 리터러시 (Data Literacy)를 구축하는 방법

데이터베이스 관리자 (DBA)가 될 필요는 없습니다. 세 가지만 있으면 됩니다.

첫째, 스키마 (Schema)를 읽는 법을 배우세요. 데이터베이스 클라이언트를 여세요. 테이블들을 살펴보세요. 어떤 컬럼이 외래 키 (Foreign Key)인지 이해하세요. 그것이 당신의 시스템이 어떻게 연결되어 있는지를 보여주는 지도입니다.

둘째, 세 가지 SQL 패턴을 배우세요. WHERE 절을 포함한 SELECT. 두 테이블 간의 JOIN. HAVING 절을 포함한 GROUP BY. 이것만으로 테스터로서 필요한 일의 90%를 커버할 수 있습니다.

셋째, 모든 UI 액션 이후에 데이터베이스를 쿼리 (Query)하는 테스트를 작성하세요. 다음은 정확히 그 작업을 수행하는 TypeScript 기반의 최소한의 Playwright 예시입니다:

import { test, expect } from '@playwright/test';
import { Pool } from 'pg';

...

복잡하지 않습니다. 하나의 어설션 (Assertion) 뒤에 하나의 쿼리를 실행하는 것뿐입니다. 이것은 환불 버그, 결제 버그, 재고 버그를 잡아냅니다. UI 테스트만으로는 이 중 그 어떤 것도 잡아낼 수 없습니다.

이것이 커리어 성장(Career Growth)에 대해 가르쳐 주는 것

시장은 무언가를 증명할 수 있는 사람에게 보상합니다. 단순히 클릭을 할 줄 아는 사람이 아닙니다. 가장 우아한 Playwright 페이지 오브젝트 (Page Object)를 작성할 줄 아는 사람도 아닙니다.

SQL 조인 (Join)을 작성하는 매뉴얼 테스터는 버그가 존재한다는 것을 증명합니다. UI 어설션만 작성하는 SDET는 버튼이 렌더링되었다는 것만을 증명합니다. 실제 제품을 출시하는 비즈니스에는 후자보다 전자가 훨씬 더 가치 있습니다.

저는 테스터들이 기존 테스트 스위트 (Test Suite)에 데이터베이스 쿼리 하나를 추가함으로써 한 분기 만에 영향력을 두 배로 늘리는 것을 목격해 왔습니다. 그들은 새로운 프레임워크를 배우지 않았습니다. 강의를 구매하지도 않았습니다. 그저 데이터베이스에 무슨 일이 일어났는지 묻는 법을 배웠을 뿐입니다.

그렇게 하지 못하는 SDET는 취약한 기반 위에 커리어를 쌓고 있는 것입니다. 프레임워크는 변합니다. 로케이터 (Locator)는 깨집니다. 브라우저는 업데이트됩니다. 하지만 데이터는 그 모든 것보다 오래 지속됩니다.

당신의 선택

만약 당신이 매뉴얼 테스터라면, 오늘 바로 데이터베이스 클라이언트를 여세요. orders 테이블을 찾으세요. payments 테이블과 조인 (Join)을 작성해 보세요. 무엇을 배울 수 있는지 직접 확인해 보시기 바랍니다.

만약 당신이 SDET라면, 다음 테스트에 데이터베이스 검증 (assertion)을 하나만 추가해 보세요. UI 체크가 아닌 데이터 체크 (data check) 말입니다. 당신의 로케이터 (locator)가 놓친 버그를 얼마나 많이 잡아낼 수 있는지 직접 확인해 보시기 바랍니다.

이력서에 적힌 직함이 당신의 가치를 결정하지 않습니다. 시스템에 대해 당신이 답변할 수 있는 질문들이 당신의 가치를 결정합니다.

UI 테스트가 완전히 놓쳤던 버그 중, 데이터베이스를 확인하여 찾아냈던 버그는 무엇인가요? 그 이야기를 듣고 싶습니다.