6가지 일반적인 연속 테스트 병목 현상

Agile 및 DevOps 사례는 빠르게 인기를 얻고 있습니다. 많은 기업들이 새로운 소프트웨어와 업데이트를 빠르고 자주 제공하기 위해 이러한 소프트웨어 개발 방법론을 채택하고 있습니다. Agile은 일반적으로 사용자 스토리와 요구 사항을 사용하여 제품 기능을 정의하므로 출시된 소프트웨어는 점진적으로 고객에게 가치를 제공합니다.

결과적으로 지속적인 테스트는 빠른 속도로 품질을 제공하는 핵심 촉매로서 수요가 전례 없이 증가했습니다.

지속적인 소프트웨어 테스트는 소프트웨어 개발 수명 주기(SDLC)가 끝날 때의 테스트와 달리 소프트웨어 제공 파이프라인의 일부로 테스트 슈트를 실행하는 것입니다. 소프트웨어 제공 파이프라인의 모든 단계에서 최대한 신속하게 위험 기반 피드백을 제공합니다. 지속적인 테스트를 통해 사용자 경험을 손상시키지 않으면서 소프트웨어 개발 프로세스를 빠른 속도로 진행할 수 있습니다.

Freeform Dynamics는 지속적인 테스트의 이점에 대해 논의했으며 923명의 IT 및 테스트 전문가로부터 디지털 비즈니스 인에이블러로서의 지속적인 테스트라는 연구에서 축적된 피드백을 받았습니다. 이 연구는 몇 가지 흥미로운 통계를 보여주었습니다.

약 75%의 전문가가 소프트웨어 개발에서 지속적인 테스트의 중요성에 동의했습니다. 그러나 응답자의 20%만이 적절한 수준(80% 이상)의 테스트 자동화 커버리지가 있다고 말했습니다. 또한 응답자 5명 중 1명은 여전히 ​​수동 테스트에 크게 의존하고 있다고 말했습니다.

많은 이점에도 불구하고 지속적인 테스트를 구현하는 것은 많은 회사에서 여전히 어려운 일입니다.

지속적이고 자동화된 테스트 분석

지속적인 테스트의 가장 큰 과제 중 하나는 생성된 방대한 양의 출력을 매우 빠르게 조사하는 것입니다. 출력은 여러 테스트 도구, 정적 및 동적 분석, 코드 적용 범위, 기능 및 회귀 테스트 등을 포함한 다양한 소스에서 생성됩니다.

테스트 분석은 예를 들어 테스트 스위트를 최적화하거나 테스트 커버리지를 향상시키기 위해 제공될 수 있었던 많은 시간과 노력을 필요로 합니다. 자동화 소프트웨어 테스트가 성공했는지 여부를 결정하는 데 몇 시간이 걸릴 수 있으며, 이는 구현된 지속적인 테스트의 핵심 목적, 즉 소프트웨어 제공을 촉진하는 데 방해가 됩니다.

테스트 분석을 자동화하면 이 문제를 어느 정도 해결할 수 있습니다. 점점 더 많은 개발자가 전체 제공 주기의 속도를 높이기 위해 출력 분석을 가속화하는 데 관심을 기울이고 있습니다.

지속적인 테스트 분석의 가시성

개발자와 운영 팀 모두가 테스트 분석에서 생생한 명확성을 갖는 것이 중요합니다. 왼쪽으로 이동하거나 애플리케이션 수명 주기 초기에 테스트하는 것이 매우 중요하지만 그것만으로는 충분하지 않습니다. 품질 보증을 위해 사용자로부터 지속적인 피드백을 받아야 하며 이는 오른쪽 시프트 테스트를 통해서만 가능합니다.

소프트웨어 테스팅의 주요 초점은 개발 단계 및 테스트 환경에서 제품의 성능뿐만 아니라 사용성 향상에도 중점을 두어야 합니다. 초기 단계를 최적화하려면 최종 제품으로서 애플리케이션 또는 기능의 동작에 대한 통찰력이 필요합니다.

따라서 테스트를 통합하고 문제를 조기에 발견하기 위해 왼쪽으로 이동해야 할 뿐만 아니라 제품의 잠재적인 결함을 이해하기 위해 생산에서 데이터를 조달해야 합니다.

긴 테스트 실행 시간

지속적인 테스트는 소프트웨어 아키텍처의 모든 수준에서 다양한 테스트 제품군을 구현하는 것으로 구성되기 때문에 테스트의 양은 어마어마합니다. 테스트 커버리지, 기능 커버리지, 새로운 코드 라인 스크립팅에 집중해야 하지만 런타임에도 주의를 기울여야 합니다.

소프트웨어 품질에 영향을 미치지 않으면서 전달 프로세스의 속도를 높이기 위해 지속적인 테스트가 도입되었습니다. 따라서 4~5시간 동안 테스트를 실행하는 것은 피드백을 약간 지연시키므로 실용적이지 않습니다. 결과적으로 전체 배송 파이프라인이 느려집니다.

이 문제를 극복하려면 무엇이 본질적이고 무엇이 관련이 있는지에 대한 보다 포괄적인 관점이 필요합니다. 테스트 영향 분석(TIA) 기능은 자동 테스트 선택을 통해 검증을 보강할 수 있습니다. 파이프라인에 들어가는 주어진 소스 코드에 대해 TIA는 코드를 검증하는 데 필요한 필수 테스트만 선택하고 실행합니다. 따라서 테스트 실행이 더 빠르고 더 집중됩니다.

수많은 배포에 발맞추기

지속적인 테스트는 테스트 부채를 생성합니다. 소프트웨어 품질을 평가하고 버그를 감지하고 애자일 방법론을 따라잡기 위해 다양한 테스트가 하루에 배포됩니다.

그러나 매일 실행되는 모든 테스트를 추적하기가 어려워집니다. 테스트의 효율성을 식별할 수 없거나 테스트 반복의 변경이 비즈니스 위험과 최종 사용자 경험에 어떤 영향을 미치는지 분석할 수 없다면 증가된 빈도와 속도는 무의미해집니다.

시간이 많이 걸리고 비싸다

테스트 자동화는 효율적인 연속 테스트의 핵심 구성 요소입니다. 이를 통해 팀은 새로운 테스트 및 반복의 성능을 신속하게 분석할 수 있습니다.

그러나 자동화된 테스트 스크립트를 빌드하는 데는 시간과 비용이 많이 소요될 수 있습니다. 따라서 조직에서는 사용을 최적화하는 것이 필수적입니다.

QA 업계 베테랑인 Amir Ghahrai는 조직이 어떤 테스트 영역이 가장 유익한지 자동화해야 한다는 사실을 알고 있어야 한다고 설명했습니다. 테스트 자동화 피라미드 원칙을 준수하여 테스트 스크립트에서 최대한의 가치를 추출할 수 있습니다.

원천

팀은 피라미드의 맨 아래에 있는 단위 테스트에 자동화 노력의 대부분을 집중해야 합니다. 피라미드 위로 올라갈수록 자동화를 축소하여 자동화된 스크립트에 대한 투자를 최적화할 수 있습니다.

변화에 대한 저항

마지막으로, 소프트웨어 개발 및 테스트의 모든 발전에도 불구하고 경험 많은 테스터 중 적지 만 상당한 비율이 테스트 방법 업데이트를 거부합니다. 변화를 꺼리는 주된 이유는 겉보기에 효과적인 전통적인 방법 때문입니다. 그 결과, 궁극적으로 전체 팀이 개발 절차를 늦추는 결과를 겪습니다.

Siemens Healthcare의 테스트 설계자인 Marco Achtziger는 독일에서 열린 OOP 2015 컨퍼런스에서 이 문제에 대해 이야기했습니다. 그는 당신이 끈질긴 팀원들에게 지지와 긍정적인 태도를 유지해야 한다고 제안했습니다. 고급 절차로 전환할 때의 이점뿐만 아니라 변경이 전체 팀에 가져올 이점에도 초점을 맞춥니다.

지속적인 테스트는 비즈니스 위험을 완화하면서 소프트웨어 개발 프로세스를 가속화할 수 있으므로 조직에 중요한 자산입니다. 소프트웨어 테스팅 도구는 테스팅 연습을 용이하게 하고 피드백 기반 테스트 방법과 관련된 몇 가지 문제를 극복하는 데 도움이 될 수 있습니다.

SDLC에 연속 테스트를 통합할 때 어떤 어려움에 직면했으며 어떻게 극복했습니까? 지속적인 테스트를 통합하는 데 어려움을 겪고 있는 독자에게 도움이 되도록 스토리를 공유하십시오.