100% 테스트 자동화가 바람직할 수 있지만, 실용적일까요?

Jonny Steiner, 제품 마케팅 관리자

 

만약 제가 타임머신이나, 제가 방금 만들어낸 마법의 시간 망원경을 손에 넣는다면, 저는 그것들로 많은 것을 할 수 있을 겁니다. 하지만 이 블로그 글의 목적상, 저는 제 시간 망원경을 사용하여 미래를 살펴보고 싶습니다. 구체적으로, 지속적 테스트에서 100% 자동화에 도달할 수 있을지 확인해 보고 싶습니다.

100% 자동화된 테스트는 불가능할 수도 있습니다

모두가 원하는 것입니다. 지속적인 테스트를 100% 자동화하는 것은 모든 QA 및 테스트 팀원의 꿈입니다. 하지만 어떤 면에서는 이는 정말 어려운 과제입니다. 우선, 어떤 코드는 자동화 테스트를 작성하기에는 너무 복잡할 수 있습니다. 반대로, 어떤 코드는 자동화 테스트가 필요할 만큼 중요하지 않을 수도 있습니다. 위험 기반 테스트 자동화를 사용하면 특정 소프트웨어의 가장 중요한 부분에 집중할 수 있습니다.

일부 전문가들은 100% 자동화 목표를 포기하라고 조언합니다. 끊임없이 변화하는 소프트웨어 개발 프로세스에서 완전한 자동화를 이룰 시간은 없다고 그들은 말합니다. ROI와 비즈니스 리더와 이해관계자를 만족시키는 것에 집중해야 한다고 그들은 강조합니다.

어떤 경우?

지속적인 테스트를 100% 자동화하는 것이 가능하다고 가정해 보겠습니다. 일부 조직에서는 이미 이를 시도하고 있다는 징후가 있습니다. 코드리스 개발과 자율 테스트 솔루션의 성장으로, 애플리케이션 개발 후 완전히 자동화된 테스트 프로세스를 거치는 미래의 기반이 마련되었습니다. 새로운 빌드가 준비되거나 결함이 완화될 때 각 테스트 실행을 다시 시작하는 것만이 사람이 개입하는 유일한 상호작용이 됩니다.

자동화 테스트의 장점은 출시 속도를 더욱 높이는 동시에 사람의 개입 없이 프로세스 초기에 버그를 제거할 수 있다는 것입니다. 하지만 앞으로 살펴보겠지만, 자동화 테스트는 가치를 창출하지만 항상 기대하는 방식으로 이루어지지는 않습니다.

테스트 자동화의 "가치"

자동화된 테스트 프로세스는 다음과 같습니다. 테스트는 시작 위치, 변경 사항, 그리고 예상 결과를 사용하여 실행됩니다. 테스트 실행이 완료되면 자동화는 실행되었지만 테스트 대상 기능은 아직 완료되지 않았음을 의미합니다. 즉, 점검이 실행될 때까지는 완료되지 않습니다. 테스트/수정/재테스트 프로세스에서 가치가 창출됩니다. 이 프로세스를 통해 오류 수정 방법에 대한 명확한 지침을 얻을 수 있습니다.

자동화된 검사가 생성되면 초기 테스트 실행이 완료되고, 변경 사항이 구현되고, 테스트가 다시 실행되며, 예상 결과가 올바르지 않을 경우 테스트에서 결함을 감지한다는 점을 이해하는 것이 중요합니다.

지속적인 테스트 분야에서는 "한 번의 소프트웨어 변경으로 테스트 자동화가 변경 감지로 전환된다"는 오래된 속담이 있습니다.

모든 문제의 시작은 자동화입니다

간단히 말해, 지속적인 테스트는 더 큰 문제로 이어질 수 있습니다. 개발 중인 애플리케이션에 변경 사항이 발생하는 순간, 자동화된 테스트 스위트는 구식이 됩니다. 종종 간과되는 테스트 유지 관리 또한 필수적입니다. 일부 조직이 겪는 문제는 기존 테스트 유지 관리에 대한 감독 부족과 오래된 테스트 삭제로, 이로 인해 테스트 부채가 발생합니다.

테스트 커버리지는 자동화 테스트에서도 중요합니다. 모든 시나리오를 다루어야 하며, 그렇지 않으면 '통과'된 테스트라도 생각만큼 정확하지 않을 수 있습니다. 물론 테스트를 100% 통과했을 수도 있지만, 놓친 시나리오는 어떻게 될까요? 테스트에 포함되지 않습니다.

그리고 실패한 검사 문제도 있습니다. 이 모든 것에 대한 조사가 필요합니다. 상황을 더욱 어렵게 만드는 것은 기술적인 이유가 아닌 환경적인 이유로 검사가 실패하는 경우가 있다는 것입니다. 1분 1초라도 아껴야 하는 세상에서 '거짓 음성' 검사는 매우 중요합니다.

각 테스트 실패는 조사가 필요하므로 고려해야 할 사항도 있습니다. 일부 테스트는 '거짓 음성'입니다. 예를 들어 환경 문제로 인해 어떤 이유로든 테스트가 종료되는 경우가 있습니다. 이는 시간을 절약하기는커녕 낭비하는 결과를 초래합니다.

테스트 자동화의 마지막 과제는 테스트가 스스로 생각하지 않는다는 것입니다. 테스트는 정해진 경로와 코딩된 목적을 따릅니다. 이는 사람이 애플리케이션과 상호작용하는 방식이 아닙니다. 우리는 주의가 산만해지고, 다른 일에 주의를 빼앗기고, 때로는 잘못된 것을 클릭하기도 합니다. 자동화된 테스트는 사용자가 미리 선택한 동작만 처리합니다.

얼마나 많은 자동화가 충분할까?

비즈니스 리더와 임원부터 개발자와 QA에 이르기까지, 사람들은 애플리케이션을 사용하거나 탐색할 때 끊임없이 테스트하고 탐구할 아이디어를 떠올립니다. 제대로 작동하는지 확인하기 위해 한 번만 시도해 볼 수도 있습니다. 하지만 이러한 모든 작은 시나리오에 대한 테스트를 개발하는 것은 여러분이 하지 않을 것이고, 누구도 해서는 안 될 일입니다.

아직 테스트 도구에 요구 사항을 입력하고 예상 결과를 기다리는 수준은 아닙니다. 하지만 테스터들이 클릭 한 번으로 테스트를 실행하고 결과를 얻을 수 있기를 원하는 시점에 도달했습니다. 테스트를 100% 자동화한다고 하면, 실행이 통과되면 소프트웨어가 추가 분석 없이 바로 운영 환경에 투입될 수 있다는 것을 의미합니다.

다행히 방금 자동화된 회귀 테스트에 대해 설명했습니다. 여기에는 성능 및 보안 테스트는 포함되지 않지만, 테스트를 격리된 환경에서 수행하고 테스트를 통과하면 앱을 프로덕션 환경에 푸시할 수 있습니다.

진실과 함께 사는 것

그러니 100% 테스트 자동화는 불가능할지도 모릅니다. 좋은 아이디어이긴 하지만 가장 실용적인 방법은 아닙니다. 자동화된 테스트를 작성하기 너무 어려운 코드는 항상 존재할 것입니다. 읽기 어려울 수도 있지만, 때로는 자동화할 만큼 중요하지 않은 코드도 있습니다. 제가 여기서 주장하는 위험 기반 접근법은 소프트웨어의 가장 중요한 부분에 초점을 맞춥니다.

투자 수익률(ROI) 측면에서 생각하는 것이 더 나을 수 있습니다. 기업에 실제로 필요한 보장 수준을 생각해 보세요. 임원진과 리더들의 반응을 살펴보고 개발 중인 소프트웨어에 대한 위험 감수 성향을 파악해 보세요.

모든 버그가 동일하지 않다는 점을 기억하세요. 따라서 모든 테스트를 자동화할 필요는 없습니다.