커리어 초창기에는 요구사항 분석, 테스트 설계, 테스트 수행, 테스트 결과 보고의 정형화된 프로세스와 산출물을 ISTQB, ISO 29119 지식을 기반으로 현업에 적용하는 시도가 많았다. 정기 수시 핫픽스가 동시 다발적으로 진행되는 서로 다른 유형의 다수의 프로젝트에서 10명 이상의 파트원분들이 진행하는 테스트 활동을 모니터링하고 제어하다 보면 아무도 알아주지 않지만 테스트 리더로서 해야 할 것들이 많았다. 모니터링 그리고 제어 활동과 마찬가지로 초록색 UI가 정말 초록색으로 나타나는지 눈으로 한번 더 확인하고 때로는 만져도 보고 귀로도 듣고. 테스터 분들께서 진행하는 테스트 수행 활동에도 아무도 알아주지 않지만 해야 하는 것들이 많았다.
테스트 자동화도 과거 매뉴얼 테스트 기반의 QA 경험과 비교했을 때 비슷한 점이 많다. 한 개의 테스트 시나리오가 상시 테스트로 운영되기까지의 과정들. 직접 해보지 않으면 모르는 고충들. 그냥 하면 되는 것이 아닌 지속 가능한 운영을 위해 고민하고 예상 필요한 것들. 테스트 자동화는 특별한 무언가가 아니라 그저 많고 많은 테스트 방법 중 하나이기 때문에 아무도 알아주지 않지만 보이는 것들과 해야 할 것들의 경계에 똑같이 놓여있다. 문제 해결 방식에 있어서 사용자 관점에 엔지니어 관점이 추가되었을 뿐이다.
현재는 Mocha 프레임워크를 사용 중이지만 만약 BDD 기반의 Cucumber를 사용하는 조직이라면 Given 단계에 해당하는 테스트 코드 중 페이지 열기에 해당하는 로직은 웹 자동화라면 공통된 테스트 로직 중 하나이므로 새롭게 정의하여 재사용 가능토록 상속 관계에 있는 부모 클래스에서 이미 정의된 메서드를 자식 클래스에서 재정의 하는 과정이 필요하다. 페이지 클래스의 로직은 URL마다 새롭게 구현 필요하지만 테스트 로직에서는 Given 단계에 자연어로 작성되는 부분을 매번 변경하지 않고도 동일한 동작 수행이 가능토록 할 수 있다. 테스트 자동화 실무자 입장에서는 위와 같은 방법이 유지 관리에 보다 수월하지만 BDD 사용의 목적과 프레임워크 철학의 관점에서는 실무자가 약간 더 수고스럽지만 전체 구조에 크게 영향이 없다면 각 단계별 시나리오를 한눈에 파악할 수 있게 구현하는 것이 적절한 방향이라 생각한다.
이러한 사항들처럼 테스트 자동화도 기술적으로 보이는 것들과 해야 하는 것들의 경계 속에서 누군가는 결정을 해야 하고 운영이 되어야 한다. 각 시나리오의 공통적인 일부 동작에 수십 라인이 작성되고 테스트 데이터만 바뀌는 로직을 재사용 가능한 구조로 만들지 않는 것도 문제지만, 개발자가 아닌 분들께서 무엇을 테스트하는지 파악하기 어렵게 만드는, 서비스 규모나 시점 대비 과한 리팩토링 또한 문제가 아닐까.
테스트 자동화 엔지니어는 일이 진행되는 방향에서 너무 과하지 않게 테스트 자동화로 진정 얻고자 하는 가치에 대해, 오늘도 내일도 아무도 알아주지 않는 경계 속에서 가치 있는 방향을 묵묵히 찾아가고 증명해야 한다.
