경영진이 가장 자주 무시하는 자동화 테스트 조언

"내가 그랬잖아"라는 말을 듣고 싶어하는 사람은 아무도 없지만, 가끔 말하는 사람은 자신이 옳았고 처음부터 알고 있었다고 반복해서 말하면서 엉뚱한 기쁨을 느끼기도 합니다.  

그렇게 행동하라고 말씀드리려는 것은 아니지만, 여러분의 바람은 이해할 만합니다. 테스트 및 QA 팀원들은 종종 제품 팀, 개발자, 그리고 사업 팀원들 사이에서 어려움을 겪습니다. 조직에서 테스터의 역할은 단순히 테스트의 핵심 측면을 넘어섭니다. 테스터는 효과적으로 소통하고 공동의 목표를 위해 팀을 하나로 모을 수 있어야 합니다.  

목표는 빠르고 대규모로 웹 및 모바일 애플리케이션을 제공하는 것입니다. 

QA 리더와 테스트 팀 관리자는 다양한 방법으로 의사소통 기술을 적용해야 합니다.

• 테스트 자동화의 가치를 비즈니스 리더에게 확신시키기
• 사용자 관점을 이해하고 관리의 차이점을 파악합니다.
• 개발자와 협력하여 결함 수정 

그러나 우리가 아는 바와 같이 회사 내에서는 의사소통이 제대로 이루어지지 않는 경우가 많고, QA나 테스트 팀 구성원이 가장 잘 제시한 제안도 무시되는 경우가 많습니다. 

그러면 QA와 테스터가 제공하는 가장 관련성 있는 조언 중 일부를 살펴보겠습니다. 하지만 종종 무시되곤 합니다.

더 자동화된 테스트가 자동으로 더 나은 테스트 계획을 의미하지는 않습니다.

기업 리더들은 이 점을 간과하고 싶어 합니다. 물론 자동화된 테스트는 좋고, 많을수록 더 좋습니다. 하지만 여기에는 더 많은 것이 있습니다. 

자동화 테스트의 이점은 잘 알고 있습니다. 그렇다면 왜 모든 것을 자동화하지 않을까요? 간단히 말해, 자동화는 어려울 뿐만 아니라 불필요하기도 합니다. 과거에는 플랫폼과 사용자 흐름이 일관되고 안정적일 때만 테스트를 자동화했습니다. 이로 인해 테스트 생성 및 유지 관리에 훨씬 더 많은 시간이 소요되었습니다.  

사실 요즘은 새로운 테스트 편집기 기능과 같은 도구를 사용하면 수동으로 테스트를 만들고 검증하는 데 걸리는 시간이 그 어느 때보다 단축되었습니다. 따라서 우리는 원래의 질문, 즉 "왜 모든 것을 자동화하지 않을까?"라는 의문에 직면하게 됩니다. 

최대 80% 자동화를 달성할 수 있지만, 여전히 인간의 개입이 필요한 시나리오가 있습니다. 고객과 비즈니스의 압력이 합쳐져 최대 100% 자동화를 시도하는 데 부담을 줄 수 있지만, 소프트웨어 테스트에는 여전히 인간의 개입이 필요한 부분이 있으며, 이는 반드시 보존해야 합니다.

사업팀은 고객에게 비현실적인 추정과 약속을 합니다.

소프트웨어 테스트를 준비할 때 기업들은 두 가지 주요 문제에 직면합니다. 테스트에 얼마나 오래 걸리고 비용은 얼마나 들까요? 내부 소통이 원활하지 않은 조직에서는 이러한 질문에 대한 답을 비현실적인 추정과 약속으로 제시하는 경우가 많습니다. 문제는 소프트웨어 테스트 추정치를 경영진이 작성하고, 경영진이 지속적인 테스트의 기술적 측면을 항상 이해하지 못한다는 것입니다.  

추정은 테스트 팀이 시간이나 예산을 초과하지 않도록 하는 데 필수적입니다. 또한, 리소스를 할당하고 테스트 활동을 최적화할 수 있는 역량을 제공하므로 테스트 프로젝트 계획에 도움이 됩니다.  

그렇다면 기업 리더들은 테스트 및 QA 팀을 곤란하게 만들지 않고도 어떻게 더 나은 소프트웨어 테스트 추정치를 내릴 수 있을까? 

효과적인 연속 테스트 추정을 위해서는 시간, 자원, 비용, 그리고 기술이라는 네 가지 핵심 요소가 있습니다. 각 요소를 자세히 살펴보겠습니다.  

• 시간: 테스트는 팀 관리자가 테스트 프로젝트의 각 단계에 소요되는 최적의 시간을 계산하는 것에서 시작됩니다. 그런 다음, 설정된 매개변수 내에서 테스트가 실행되도록 일정을 수립할 수 있습니다. 이러한 팀의 성공은 마감일을 준수하는 능력에 따라 결정됩니다.
• 자료 : 여기에는 인프라, 도구, 전문가와 같은 팀 요구 사항이 포함됩니다. 팀이 성공적인 테스트 실행에 필요한 항목을 갖추지 못하면 테스트가 제때 완료되지 않습니다.  
• 비용 : 이 내용은 리소스 섹션에 부분적으로 포함되어 있습니다. 성공적인 테스트 견적은 팀이 필요한 사항을 이해하고 그에 따라 예산을 준비하는 데 도움이 됩니다. 이상적인 상황은 예산이 사전에 설정되고 테스트 프로젝트가 예산에 맞춰 진행되는 것입니다.
• 기술: 이는 팀원의 기술적, 전문적 역량을 의미합니다. 이러한 역량이 부족하거나 부족하면 전체 테스트 프로세스가 지연됩니다.

Shift-Left를 구현하고 테스트 중심으로 전환

시프트-레프트(Shift-Left) 방식의 목적은 개발 파이프라인에서 결함을 최대한 빨리 발견하는 것입니다. 즉, 프로세스 초기에 테스트를 진행해야 하므로 팀 간의 협업과 소통이 더욱 원활해집니다.  

경영진은 프로세스 구현에 드는 시간과 비용 부담 때문에 이러한 방법 도입에 반대하고 있습니다. 그들은 여전히 ​​테스트를 SDLC의 마지막 단계로 여기고 있으며, 이로 인해 문제가 발생합니다. 가장 우려되는 점은 테스트가 소프트웨어 제공 속도를 높이려는 팀의 시간을 지연시키는 병목 현상이 되기 시작한다는 것입니다.  

왼쪽으로 이동한다는 것은 사이클 마지막 단계에서도 테스트를 수행할 수 있다는 의미이지만, 이미 미리 테스트를 수행했다는 것은 실행 규모가 더 작고 빠르다는 것을 의미합니다. 그런 의미에서 왼쪽으로 이동한다는 것은 테스트를 사이클 시작 부분에 더 가깝게 이동시키는 것이 아니라, 전체 개발 프로세스에 걸쳐 양념을 뿌리는 것과 같습니다.  

QA가 많아진다고 해서 결함이 많아지는 것은 아닙니다.

일부 기업 리더들은 QA를 필요악으로 여깁니다. QA가 고품질 소프트웨어 출시와 관련된 프로세스를 구현해야 한다는 것을 알고 있지만, 이 프로세스는 종종 출시 주기 후반부에 발생하여 병목 현상처럼 느껴질 수 있습니다. QA가 많아질수록 결함 발견이 늘어나 출시가 지연될 것이라는 잘못된 믿음을 가지고 있기 때문입니다.  

테스터가 결함과 오류를 파악하는 반면, QA는 기술적인 측면조차 고려하지 않는 사용성 문제를 더 많이 살펴봅니다. 따라서 QA와 지연이라는 감정이 생깁니다. 버그 영역 밖의 결함도 고려합니다. QA는 최종 사용자 경험과 부실한 탐색 기능이나 느린 로딩 속도와 같은 성능 관련 문제에 더 집중합니다.  

따라서 QA를 더 많이 실시하면 사용자 경험이 향상된 더 나은 앱이 탄생하지만, 테스트 팀이 이미 발견한 것보다 앱이 더 문제가 있다는 것을 의미하지는 않습니다.  

결론

기업 리더들이 조언을 무시하는 것에 대해 이야기할 때, 결국 권력과 직관에 사로잡힌 것처럼 보입니다. 한편으로는 회사 프로세스에 대한 자신의 권력과 주인의식을 유지하고 싶어 합니다. 다른 한편으로는 결정을 내릴 때 직감을 지나치게 신뢰하기도 하는데, 리더가 권력의 자리에 오르게 된 것은 대개 직감 덕분입니다. 

소프트웨어 테스팅과 QA에 있어 테스트 횟수 증가나 QA 확대라는 개념은 SDLC(소프트웨어 개발 수명 주기) 지연으로 이어질 수 있기 때문에 종종 의아해합니다. 기업은 비즈니스 팀과 솔직하게 소통하는 것 외에도, 개발 프로세스 초기에 테스트를 진행할 수 있는 방안을 마련해야 할 뿐만 아니라, 소프트웨어 테스팅 프로세스의 실행 가능성에 대한 실증적 증거를 제공하고 논의를 활성화하는 데 도움이 되는 보고 도구를 찾아야 합니다.

전단지에 포함된 링크에 대해 더 알아보기 Digital.ai Continuous Testing 해결책 여기에서 확인하세요.