자동화할 것인가, 자동화하지 않을 것인가

왜 아직도 수동 테스트를 고수하고 있나요? 자동화 실패로 인한 비용이 너무 많이 들었나요? 아니면 전자를 경험하고 싶지 않기 때문에 피하고 있습니까? 피하는 이유는 다양합니다. 나는 또한 그들이 합법적인 것에 동의합니다. 주요 내용 중 일부는 다음과 같습니다.

복잡성

전통적인 일명 스크립트 기반 테스트 자동화는 복잡합니다. 모두 ‘코딩’이 필요하기 때문입니다! RFT, QTP, Selenium 또는 테스터가 자동화 도구에 특정한 스크립팅 언어를 배워야 하는 기타 테스트 자동화 도구인지 여부에 관계없이 개발 방식을 적용하여 수동으로 테스트된 테스트 사례의 스크립트를 생성합니다. 테스트 팀이 스크립트를 작성하지 않고도 자동화할 수 있다면 어떨까요 과천지식정보타운?

테스트 자동화는 비용이 많이 든다

자동화 도구에 투자하는 것부터 도구의 모국어를 아는 올바른 리소스에 이르기까지 전통적인 테스트 자동화에는 막대한 투자가 필요합니다. 도구 라이선스 대 사용자 비율은 1:1입니다. 이는 팀에 테스트 자동화 전문가를 한 명 더 추가하더라도 추가 라이선스를 구매해야 함을 의미합니다. 팀 내에서 테스트 자동화 도구 라이선스를 공유할 수 있다면 어떨까요?

기술 집약적

예, 스크립트 기반 테스트 자동화에는 프로그래머가 필요합니다. 종종 예상보다 좋은 프로그래머에게는 대가가 따릅니다. 이로 인해 자동화 비용이 증가합니다. 이러한 리소스를 고용하고 유지하는 데 드는 비용을 포함하는 것을 잊지 마십시오. 또한 스크립팅은 전체 테스트 활동을 다른 팀 구성원(수동 테스터 및 해당 분야 전문가)과 분리합니다. 이는 의도적인 것이 아니라 테스트 자동화의 부작용입니다. 테스트 사례 생성에 모든 수준의 경험, 도메인 및 기술 지식이 협력한다면 어떻게 될까요?

시간 집약적

전통적인 테스트 자동화는 스크립팅을 의미합니다. 스크립트를 작성하고, 테스트하고, 작동하게 하려면 상당한 시간이 필요합니다. 그리고 시간은 문자 그대로 더 많은 비용을 의미합니다. 이 시간을 단축하면서도 자동화를 보장할 수 있다면 어떨까요?

앞서 언급한 이유가 사실임에도 불구하고 자신이 무엇을 놓치고 있는지 생각해 본 적이 있습니까? 다음 사항에 대해 생각해 본 적이 있습니까?

불완전한 테스트 범위

시장 출시 시간에 대한 압박으로 인해 테스트 팀은 100% 회귀하지 못하게 됩니다.

출시 시간

100% 테스트 적용 범위를 위해 수동으로 회귀하기로 결정하더라도 회귀를 자동화한다면 얼마나 많은 시간을 절약할 수 있을지 상상해 보십시오. 얼마나 빨리 시장에 진출할 수 있는지 상상해 보세요. First Mover의 이점을 상상해 보세요.

인간의 실수

실수하는 것은 인간의 일이지만 테스트 세계에서는 이를 클라이언트가 알아차린 버그에 대한 변명으로 사용할 수 없습니다. 수동 회귀는 평범해져서 확인되지 않은 버그가 발생할 수 있습니다.

값비싼

이는 리소스 비용, 도구 비용, 인프라 비용을 요약할 뿐만 아니라 시장 출시 시간 증가, 100% 회귀 부족 또는 단순한 지루함으로 인한 미확인 버그 비용을 포함합니다. 이는 모두 용납할 수 없는 비용이자 기회입니다.

수동 테스트는 절대적으로 필요합니다. 테스트 자동화는 수동 테스트를 대체할 수 없습니다. 테스트가 고품질 소프트웨어를 구축하는 수단이라면 테스트 자동화는 의미하는 수단입니다. 당신도 동의할 것입니다. 이는 최적의 소프트웨어 테스트 프로세스를 구축하는 효과적인 전략 중 하나입니다. 하지만 딜레마는 계속된다…

한편으로는 테스트 자동화를 개발, 유지 관리 및 운영하는 데 드는 비용이 있습니다. 반면에 시장 출시 기간이 길어지고 100% 수동 회귀가 부족하여 확인되지 않은 버그가 발생합니다. 당신은 무엇을 선택하겠습니까?

자동화 비용을 줄이면서도 테스트 자동화의 모든 이점을 계속 제공하겠다고 제안한다면 어떻게 될까요? 테스트 팀이 스크립트를 작성하지 않고도 자동화할 수 있다면 어떨까요? 팀 내에서 테스트 자동화 도구 라이선스를 공유할 수 있다면 어떨까요? 테스트 사례 생성에 모든 수준의 경험, 도메인 및 기술 지식이 협력한다면 어떻게 될까요? 자동화 시간을 단축하고 테스트 적용 범위를 늘릴 수 있다면 어떨까요?