FUNDAMENTAL TESTING

소프트웨어 엔지니어링에 있어서 테스트는 AI 시대에 더욱 중요한 가치가 되었다.

테스트는 시스템 품질에 대한 지속 가능한 신뢰를 구축하는 소프트웨어 엔지니어링 활동이다.

AI 로 인해 코드 작성 비용은 줄어들고, AI 가 작성한 코드 구조와 품질, 의도를 이해하기 위한 이해 부채(Comprehension Debt) 를 해결하는 비용과 작성한 코드가 올바르게 동작하는지 검증(Verification & Validation) 하는 비용이 훨씬 커졌다.

Verification(e.g Unit Test, Integration Test, Contract Test) 은 설계 명세서, 요구사항, 스펙대로 구현이 되었는지를 내부적으로 검증하는 활동이고, Validation(e.g Beta Test, A/B Test 등) 은 최종 사용자의 실제 요구와 기대치를 충족하는지 평가하는 활동이다.

과거에는 많은 조직이 프로덕션 코드의 품질에 집중했다면, 오늘날에는 어떤 테스트 전략과 검증 체계를 팀에 적용할 것인지, 그리고 이를 지속 가능하게 운영하기 위한 테스트 전략과 테스트 아키텍처(Test Strategy & Testing Architecture)를 구축하는 것이 훨씬 중요해지고 있다.

특히, 새롭게 추가한 코드나 버그 픽스등의 작업이 회귀(Regression) 를 일으키진 않는지, 하위 호환성을 보장하는지는 필수로 검증되어야 한다.

Building a Sustainable Testing Culture

테스트 문화를 만들고 정착시키는 것은 정말 어렵다.

특히 조직의 인력난, 업무 일정 등을 고려하고 이해하다보면 테스트가 가장 먼저 희생된다. 따라서 조직의 상황에 맞는 테스트 전략, 아키텍처를 먼저 만든 다음 문화를 발전 시키는 것도 방법이다. 즉, 시스템을 먼저 강제하고 문화를 발전 시키는 것이 때로는 특정 조직에 있어서 올바른 방법일 수 있다.

예를 들어, 회사에 QA 엔지니어가 있는 팀이라면 SonarQube 등을 통한 단위 테스트 커버리지를 60% 이상으로 맞춰야 한다는 등의 정책이 전사적으로 내려올 수 있다. 이는 각 팀의 상황을 고려하지 않고 내려오는 경우가 있다. 이렇게 시스템을 먼저 강제하게 되면 자연스럽게 따라올 수 밖에 없는 상황이 된다.

하지만 이러한 접근은 부작용도 존재한다. 조직의 상황과 성숙도를 고려하지 않고 시스템을 먼저 강제하는 방법은 저품질 테스트와 다양한 Test Smell 을 만들어낸다. 테스트 전략 없이 AI 로 테스트를 대량 생성하다 보면 Mock 남발, 지나친 fixture 의존, 리팩토링을 방해하는 테스트, 단순 커버리지 채우기용 테스트 등이 증가하게 된다.

또한 조직 성숙도보다 앞선 프로세스는 반발을 만든다. 예를 들어 주니어 개발자 중심이고 빠른 MVP 를 만들어내야 하는 단계인데 E2E Test, contract test 의무화 등 좋아 보이는 다양한 테스트 전략을 강제화 하면 결과적으로 개발 속도 급감, 테스트에 대한 반발감 등이 생겨 조직에 악영향을 끼치게 된다.

테스트 문화를 정착시키고 싶어도 설계 품질(Testability) 이 좋지 않아서 테스트를 작성하기 힘든 상황이 있을 수 있다. 예를 들어 테스트하기 어려운 설계(e.g God Service, Infra Coupling, Hidden Side Effect 등) 가 적용된 경우이다. 이런 경우엔 테스트 가능한 구조(Testability) 를 먼저 만드는 것이 필요할 수 있다.

결국 지속 가능한 테스트 문화는 단순히 테스트를 많이 작성한다고 만들어지는 것이 아니라, 테스트 가능한 구조(Testability)를 설계할 수 있는 엔지니어링 역량 위에서 형성된다고 생각한다. 그리고 이러한 역량은 소프트웨어 엔지니어링 고전들을 통해 깊게 학습할 수 있다.

Software Quality

소프트웨어 엔지니어는 좋은 품질의 서비스를 제공해야하는 책임이 있다. 그리고 좋은 기업일수록 소프트웨어 품질을 높이기 위한 다양한 제도적 장치(e.g Security Review, Cloud Operability Review, 자주 검증, 테스트 커버리지, 성능 테스트 등)를 마련해 놓는다.

고객은 더 신뢰할 수 있는 제품으로 빠르게 이동하기 때문에, 품질에 신경쓰지 않으면 한 순간에 경쟁 업체에게 트래픽을 빼앗길 수 있다. 즉, 소프트웨어 품질은 타협할 수 없는 기준이다. 때로는 품질보다 출시일정을 고려해야하는 상황이 있을 수 있으며 이 경우 기술 부채가 생기게된다.

소프트웨어 품질은 사용자 관점에서는 사용성, 디자인, 보안성, 빠른 응답 속도, 장애 없는 서비스로 요약할 수 있다. 기업 관점에서는 투자 수익률, 실시간 분석이 가능한 환경, 무중단 서비스, 확장 가능한 인프라, 데이터 보안, 법률 규정 준수 등이 있다.

이 모든 것이 오늘날 좋은 소프트웨어를 만드는 중요한 요소다.

Shift Left

시프트 레프트(shift left) 는 소프트웨어 개발 초기에 테스트를 수행하는 것이다. 따라서 CI/CD 프로세스에 의존할 수 밖에 없다.

기획자는 User Story 를 정하고, 스토리 킥오프(story kickoff) 또는 기획 리뷰(plan review)를 기획자, 개발자, 테스터와 함께 진행하며 기능을 자세히 검토 한다.
기획자는 UX 디자이너와 협의하여 애플리케이션 설계를 검증하고 개선한다.
개발자는 구현을 하기 전에 각 User Story 및 기획을 바탕으로 테스트 시나리오를 작성한다. 여기서 테스트 시나리오는 BDD Style 로 작성할 수 있다.
테스트 시나리오는 팀 리뷰를 통해서 적절한 도메인 용어가 반영 되었는지, RESTFul 을 준수하였는지, 누락된 테스트 케이스는 없는지 등을 같이 검토한다.
테스트 시나리오 리뷰가 끝나면 개발자는 Unit Test 를 작성하고 CI 에 통합한다. 또한 정적 코드 분석을 위한 도구를 CI 에 통합하여 지속적인 피드백을 받는다.
UI 테스트는 클라이언트 개발자 또는 테스터가 작성한다. 개발자가 작성하는 경우 CI 에 통합해야 한다.
첫 번째 피드백은 커밋을 하기 전 개발자의 로컬 환경에서 실행되는 자동화된 테스트를 통해 받는다.
두 번째 피드백은 커밋 후 CI 에서 실행되는 자동화된 테스트에서 받는다.
세 번째 피드백은 Devbox 테스트 를 통해 받는다.

Devbox 테스트란 개발자가 기능 구현 후 자신의 PC에서 실행, 에뮬레이터/실차/IVI 장비 연결 후 동작 확인, API 호출 직접 테스트, 모바일 앱에서 버튼 클릭 흐름 확인 등을 의미한다. 즉, 개발자나 테스터가 직접 수행한다.

시프트 레프트 테스트는 빠른 피드백(fast feedback)을 받는 것이 핵심이다. 테스트를 초기 단계로 이동시킴으로써 기능의 작동을 검증하는 것 외에도 다양한 품질 측면에서 사용자 스토리를 충분히 탐색할 기회를 얻는다. 또한 여러번의 피드백을 통해 결함을 초기에 발견할 수 있다는 장점이 있다.

익스트림 프로그래밍(eXtreme Programming, XP) 은 시프트 레프트 테스트를 통합한 애자일 소프트웨어 개발 프레임워크다.

시프트 레프트는 소프트웨어 개발의 모든 단계에서 다양한 역할의 구성원이 품질 검사에 참여하기 때문에 '품질은 팀 전체의 책임이다'를 강조한다.

References

Full Stack Testing / Gayathri Mohan