테스트 – 아마도 애플리케이션 개발에서 가장 과소평가된 부분

왜 내가 당신의 작업을 테스트하기 위해 당신에게 돈을 지불해야 합니까?

이것은 고객과 테스트 예산에 대해 논의할 때 수년 동안 많이 들었던 질문입니다. 초심자에게는 공정한 질문처럼 들립니다. 그러나 소프트웨어 개발에 관련된 사람이라면 누구나 테스트가 얼마나 복잡하고 시간이 많이 소요될 수 있는지 알고 있습니다. 테스트는 사실 모든 소프트웨어 개발 프로젝트에서 가장 중요한 부분 중 하나입니다.

대규모 전자 상거래 플랫폼은 수백만 줄의 코드, 기가바이트의 데이터 및 많은 통합 지점이 있는 믿을 수 없을 정도로 복잡한 것입니다. 상호 연결된 움직이는 부분이 너무 많습니다. 사슬에 너무 많은 링크가 있어서 무언가 잘못되기가 매우 쉽습니다. 이 응용 프로그램은 수많은 데스크톱 및 모바일 장치에서 수많은 브라우저를 통해 수백만 가지 다른 방식으로 사용됩니다. 개발 프로젝트는 많은 다른 사람들이 작업하면서 최소 6개월 동안 지속되었습니다. 테스트할 수 있는 영역과 시나리오의 수는 거의 무한합니다. 어떤 것이든 효과가 있다는 것은 놀라운 일입니다!

테스트는 여러 영역으로 나눌 수 있지만 각 테스트 영역을 고려하는 것이 중요합니다. 모든 프로젝트는 약간 다릅니다. 일부 클라이언트는 테스트의 많은 부분을 스스로 수행하는 것을 좋아하고 일부는 아웃소싱을 선호하는 반면 일부 클라이언트는 개발자가 모든 작업을 수행하기를 기대합니다. 테스팅은 또한 고정된 실체가 아닙니다. 당신은 많은 테스트를 할 수 있고 조금 할 수 있습니다. 테스트를 더 많이 할수록 프로젝트의 위험은 더 많이 제거되지만 시간이 더 많이 걸리고 비용도 더 많이 듭니다.

단위 테스트

단위 테스트는 코드의 작은 '단위'를 테스트하여 예상대로 작동하는지 확인하는 것입니다. 예를 들어, 양식이 제출되면 입력된 세부 정보를 데이터베이스 테이블에 저장해야 합니다. 특히, 장치가 예상대로 작동하는지 확인하는 독립 실행형 테스트입니다. 진정한 테스트 주도 개발 방법론을 사용하여 개발자는 테스트를 통과한 경우에만 코드가 완료된 것으로 간주될 수 있도록 실제로 코드를 생성하기 전에 먼저 테스트를 작성합니다. 실제로 단위 테스트는 핵심 기능이 예상대로 작동하는지 확인하기 위해 애플리케이션의 일부 핵심 영역에서만 사용됩니다. 단위 테스트는 기능적 문제가 발생할 가능성을 줄일 수 있지만 개발 시간을 늘릴 수도 있습니다.

연기 테스트

개발 에이전시에서 연기 테스트에 대해 많이 이야기하는 것을 듣게 될 것입니다. 스모크 테스트는 애플리케이션 전체의 주요 사용자 여정과 기능을 다루는 테스트 사례의 실용적인 하위 집합입니다. 최소한 개발자는 UAT를 위해 무엇이든 넘겨주기 전에 연기 테스트를 수행해야 합니다.

UI 테스트

사용자 인터페이스(UI) 테스트는 매우 복잡하고 시간이 많이 소요될 수 있습니다. 웹 사이트에 액세스하는 데 사용되는 모바일, 태블릿 및 데스크톱 장치, 운영 체제 및 브라우저가 매우 다양하기 때문에 모든 조합을 수동으로 종합적으로 테스트하는 것은 거의 불가능합니다. 다루어야 하는 다양한 변형이 많기 때문에 UI 테스트는 자동화된 테스트를 위한 완벽한 후보입니다. 자동화된 테스트 도구는 웹사이트를 통해 스크립트로 작성된 여정을 따르고 예상 결과가 달성되는지 테스트할 수 있습니다. 또한 각 여행을 기록하여 각 여행을 재생할 수 있습니다. 이 방법이 완벽하지는 않지만 웹사이트가 직면할 수 있는 주요 UI 문제의 수를 크게 줄일 수 있습니다.

Bug Finder와 같은 일부 타사 테스트 서비스는 전 세계 수백 명의 프리랜서 휴먼 테스터가 웹사이트를 테스트하는 데 사용되며 문제를 발견하면 비용을 지불하는 크라우드 소싱 서비스를 제공합니다. 이 접근 방식은 수백 개의 장치/플랫폼/브라우저 조합에서 애플리케이션을 테스트하는 비교적 비용 효율적인 방법이 될 수 있습니다. 테스트 주기에서 약 200개의 문제가 제기되는 것은 정상입니다. 가장 중요한 문제를 처리하는 데 리소스를 집중할 수 있도록 문제를 분류하고 우선 순위를 지정하는 경우가 많습니다. 모든 웹사이트에는 해결될 가능성이 거의 없는 낮은 수준의 문제에 대한 지속적인 백로그가 있습니다.

회귀 테스트

회귀 테스트는 진행 중인 개발에서 매우 중요한 부분입니다. 응용 프로그램의 한 부분에 대한 변경 사항이 다른 부분에 문제를 일으켰는지 여부를 테스트하도록 설계되었습니다. 예를 들어 문의 양식을 확인하는 데 사용되는 JavaScript 함수를 변경하면 결제에 사용되는 양식에 잠재적으로 영향을 미칠 수 있습니다. 모든 전자 상거래 플랫폼의 복잡한 특성으로 인해 회귀 문제는 드문 일이 아니므로 견고한 회귀 테스트 계획을 고안하여 이러한 문제로 인해 사용자 경험이 부정적인 영향을 받지 않도록 하는 것이 중요합니다.

UAT

UAT(User Acceptance Testing)는 모든 개발 프로젝트의 중요한 부분이며 고객이 서비스를 시작하기 전에 플랫폼에 대한 전체 종단 간 테스트를 수행하는 것을 포함합니다. UAT는 내가 가장 자주 과소 평가되는 프로세스입니다. 일정이 촉박할 때 가장 먼저 피해를 보는 프로젝트의 일부이기도 하다. 그러나 이것은 더 높은 실패율로 이어질 가능성이 있습니다. 새로운 웹사이트 구축의 경우 최소 2개월의 UAT를 계획하는 것이 좋습니다. 귀하의 전자 상거래 웹사이트는 상거래 비즈니스의 한 부분일 뿐이며 검색, 체크아웃, 주문 관리, 지불, 발송, 고객 서비스, 금융 및 체인의 다른 모든 부분을 포함하는 종단 간 프로세스는 다음과 같아야 합니다. 테스트했습니다.

UAT는 종종 여러 시스템 간의 통합을 구체적으로 테스트하는 SIT(시스템 통합 테스팅)와 혼동되거나 병합됩니다. SIT는 체인의 모든 부분이 올바르게 함께 작동하는지 확인하는 종단 간 테스트의 일부입니다.

좋은 UAT에는 테스트 케이스 및 테스트 계획 생성이 포함됩니다. 이들은 일반적으로 수동 테스터가 실행하고 결과에 따라 테스트를 통과하거나 실패하는 스크립트 집합(실행할 작업 집합인 스크립트)의 형태를 취합니다. 종단 간 UAT 테스트 계획에 500개 이상의 테스트 사례가 포함되는 것은 드문 일이 아닙니다.

UAT의 A는 이것이 중요한 이유 중 하나입니다. UAT 프로세스가 끝나면 일반적으로 응용 프로그램을 수락한 것으로 간주되므로 예상한 대로 정확히 작동하는지 확인하기 위해 철저히 테스트하는 것이 중요합니다. 이것은 발견되지 않은 버그가 보증되지 않는다는 것을 의미하지는 않지만 예상한 방식으로 작동하지 않는 기능이 있는 경우 UAT에서 이를 선택해야 합니다. 이것이 중요한 또 다른 이유는 문제가 게시되기 전에 문제를 선택할 수 있는 마지막 기회이기 때문입니다. 모든 버그와 문제는 사용자 경험에 부정적인 영향을 미칠 수 있습니다.

UAT는 종종 과소평가되는 클라이언트를 대신하여 많은 노력을 요구합니다. 일부 클라이언트는 UAT 동안 외부 테스트 기관을 사용하여 UAT를 효과적으로 수행할 수 있는 인력이 없는 프로젝트의 위험을 크게 줄일 수 있습니다.

보안 테스트

나는 때때로 일부 소매업체가 보안 테스트를 충분히 심각하게 받아들이지 않는다는 사실에 매우 놀랐습니다. 소매업체가 웹 플랫폼에서 마지막으로 침투 테스트를 실행한 시간을 알지 못하는 경우는 드문 일이 아닙니다. 이들은 일반적으로 아직 사이버 공격을 받은 적이 없는(또는 공격을 받은 사실을 아직 모르는) 사람들입니다. 사이버 범죄의 빈도와 정교함이 계속해서 증가하고 특히 유럽에서 GDPR이 다가오면서 보안 테스트가 점점 더 중요해지는 현 상황에서. 모든 전자 상거래 웹 플랫폼은 적어도 매년, 이상적으로는 일년에 두 번 전문 제3자에 의해 침투 테스트를 받아야 합니다. 또한 Nessus와 같은 전문 소프트웨어를 사용하여 정기적으로 응용 프로그램의 취약점을 검사하는 것이 좋습니다. Envoy에서는 애플리케이션 취약점을 매우 빠르게 파악하기 위해 매주 고객의 웹 플랫폼을 스캔하는 경향이 있습니다. 최소한 각 프로덕션 릴리스 전에 애플리케이션 보안 스캔을 수행해야 합니다. 새로운 애플리케이션 취약점을 도입했을 때 다음 침투 테스트까지 6개월을 기다리는 것은 좋지 않습니다.

성능 시험

성능 테스트는 일반적으로 웹사이트가 처리할 수 있는 트래픽, 페이지 요청, 동시 사용자 및 주문량을 결정하는 데 사용됩니다. 정확히 테스트하려면 실제 사용자 행동을 모방해야 하고 실제 사용자는 다양한 작업을 수행해야 하므로 상상할 수 있는 것보다 더 어려운 프로세스입니다. 당신이 할 수 있는 최선은 검색, 장바구니에 담기 및 결제와 같은 주요 사용자 여정을 모방하는 것입니다. 스테이징 환경이 아닌 프로덕션 환경에서 부하 테스트를 수행하는 것이 이상적입니다. 그래야 훨씬 더 정확한 그림을 얻을 수 있기 때문입니다. 하지만 테스트 중 어느 시점에서 플랫폼이 오프라인 상태가 될 수도 있습니다.

대부분의 소매업체는 일반적으로 블랙 프라이데이나 크리스마스와 같은 성수기 전에 1년에 한 번 부하 테스트를 수행하는 경향이 있습니다. 이로 인해 발생할 수 있는 문제는 지난 연례 테스트 이후 응용 프로그램에 많은 변경이 있었고 그 중 일부는 성능에 점진적인 영향을 미쳤을 수 있다는 것입니다. 연간 부하 테스트에서 전년도와 비교하여 성능이 저하되는 경우 지난 1년 동안 어떤 변경 사항이 성능 저하에 기여했는지 판별하기가 매우 어렵습니다. 이것은 또한 피크 거래가 시작되기 전에 성능 문제를 해결할 충분한 시간을 제공하지 않을 수 있습니다.

이에 대응하기 위해 각각의 새 코드 릴리스 전에 성능 벤치마크를 수행하는 것이 좋습니다. 각 테스트가 마지막 릴리스에 비해 성능이 증가 또는 감소했는지 여부를 확인하는 것이 목표이므로 동일한 환경에서 각 테스트가 수행되는 한 프로덕션 환경에서 이러한 작업을 수행할 필요가 없습니다. 이 접근 방식을 통해 개발 팀은 성능의 증가 또는 감소가 어디에서 오는지 이해할 수 있습니다. 물론 시간이 걸리므로 개발 시간과 비용이 증가합니다.

위의 목록이 완전하지는 않지만 소프트웨어 개발 내에서 테스트의 범위가 매우 크고 복잡할 수 있음을 알 수 있습니다. 각 유형의 테스트에는 시간과 노력이 필요하며 추가 비용 없이 모두 표준으로 수행된다고 가정해서는 안 됩니다. 테스트에 중점을 둔 회사는 모든 프로젝트 시간의 최대 40%를 테스트에 할당할 것이며 이는 매우 놀라운 금액일 수 있습니다. 좋은 테스트는 프로젝트의 위험을 없애고 장기적으로 그 자체로 비용을 지불할 수 있습니다. 결과적으로 버그가 줄어들고 성능이 향상되며 고객에게 전반적인 경험이 향상되기 때문입니다.