시스템 자체를 구현하는 것보다 기능 테스트를 구현하는 데 더 많은 시간을 소비하고 있습니다. 이것이 정상입니까?

기본적으로 우리는 세 가지 주요 프로젝트를 가지고 있으며 그 중 두 개는 웹 서비스이고 다른 하나는 웹 응용 프로그램입니다. 기능 테스트 (웹 프로젝트 3 개 모두에 적절한 단위 테스트가 있음)로 웹 서비스를 최대한 많이 다루는 것에 만족하지만 웹 응용 프로그램의 기능 테스트는 구현하는 데 많은 시간이 걸립니다. 나는 단위 테스트로 테스트되는 기능을 구현하는 데 걸리는 시간을 두 배 이상, 때로는 더 의미합니다.

관리자 정책은 업무상 중요하지 않은 (즉, 새로운 CRUD) 추가하는 모든 단일 기능을 테스트하는 것입니다.

수동으로 테스트하기가 어렵 기 때문에 모든 웹 서비스 기능을 테스트하는 데 동의하며,이 테스트는 빠르게 실행되며 구현하는 데 많은 시간이 걸리지 않습니다.

그렇다면 시스템 코드 작성, 단위 테스트 및 QA 티켓 수정보다 기능 테스트 작성에 더 많은 시간을 소비하는 것이 무엇입니까? 이것이 정상입니까? 중요한 기능에 대해서만 기능 테스트를 작성하고 QA가 중요한 기능없이 회귀 테스트를 수행하도록해서는 안됩니까?

참고 : 우리는 의료 소프트웨어 또는 NASA 소프트웨어를 개발하지 않거나 그다지 중요한 것은 없습니다.

기능 테스트는 매우 중요합니다. 예, 작성하는 데 시간이 걸리지 만 올바른 기능 테스트를 작성하는 경우 그 이상의 가치가 있습니다.

애플리케이션에서 자동화 된 기능 테스트를 수행해야하는 몇 가지 이유가 있습니다.

• 새 기능이 웹 사이트에 추가되면 해당 새 기능에 대한 변경 사항이 사이트의 다른 기능을 손상시키는 경우 즉시 알려줍니다.
• 비즈니스 요구 사항을 달성하기 위해 응용 프로그램이 어떻게 실행되고 함께 작동하는지에 대한 지식이 문서화되어 있습니다.
• 타사 라이브러리를 업데이트해야 할 때 업데이트하고 기능 테스트 스위트를 실행하여 문제가 있는지 확인하십시오. 모든 페이지를 직접 살펴 보지 않고 컴퓨터에서 컴퓨터를 사용하도록 설정하고 모든 테스트 목록을 제공 할 수 있습니다.
• 부하 테스트! 수천 명의 동시 사용자가 한 번에 사이트를 방문하는 것을 시뮬레이션 할 수 있으며 압력이 가해지면 사이트 속도가 느려지고 구부러지는 위치를 확인할 수 있습니다. 심야 전화가 걸려 사이트가 다운 된지 오래 전에 웹 사이트가 어떻게 작동하는지 확인할 수 있습니다.
• 기능 테스트는 수동으로 수행하는 데 시간이 걸립니다. 그렇습니다. 케이스를 작성하는 데 시간이 오래 걸리지 만 제품을 배송하기 전에 완료해야하는 500 페이지의 테스트를 바인더와 함께 앉아야한다면 자동화 된 테스트를 원할 것입니다!
• 테스트 문서가 빨리 만료됩니다. 새로운 기능이 추가되면 반드시 마스터 테스트 문서를 업데이트해야합니다. 누군가가 일부 테스트를 건너 뛰면 갑자기 "완료되고 테스트 된"페이지에 버그가 발생합니다. 나는 현재 그런 환경에서 일하고 있으며, 그것은 악몽이라는 것을 당신에게 확신시킬 수 있습니다.

결국, 이러한 경우를 작성하는 데 시간이 걸리지 만, 작성하는 데 자부심을 가져야합니다. 코드가 작동하고 다른 모든 기능과 작동한다는 의심의 그림자를 넘어서는 입증 방법입니다. 품질 보증팀에서 버그가 있다고 말하면 버그를 수정 한 다음 테스트 스위트에 추가하여 수정되었음을 표시하고 다시는 발생하지 않도록하십시오.

안전망입니다. 누군가가 저장된 프로 시저를 가져 와서 약간 변경하여 코드와 함께 작동하면 프로세스에서 다른 3 가지 기능이 손상되었음을 알 수 있습니다. 마감일 전날 밤이 아니라 그날 밤에 잡을 수 있습니다!

시스템 크리티컬 기능에 대해서만 기능 테스트를 작성합니다. 그것은 당신에게 전체 그림을 제공하지 않으며 버그가 몰래 빠져 나올 수있게합니다. 시스템에 중요하지 않지만 시스템에 중요한 기능과 간접적으로 상호 작용하여 버그가 발생할 가능성이있는 작은 기능 하나만 추가하면됩니다.

2 번 이상… 이에 대한 이유를 분석 할 수 있습니다. 다음을 포함 할 수 있습니다.

• 테스트 생성 및 유지 관리를위한 잘못된 도구 지원

• 웹 서비스 계약은 디자인에 충분히 설명되어 있지 않습니다. 개발자는 테스트하는 동안 계약을 해결해야하며, 이는 일반적으로 시간이 걸리는 정렬 프로세스입니다.

개발자와 대화하십시오.

스프린트에서 개발한다고 가정하고 스프린트의 일부인 경우 이러한 기능 테스트를 수행하십시오. 이러한 테스트 없이는 수행되지 않습니다. 없는 경우 개발 단계 후 통합 테스트 시간이 두 배로 늘어날 수 있습니다.

시스템 자체를 구현하는 것보다 기능 테스트를 구현하는 데 더 많은 시간을 소비합니까?

물론. 정말 좋은 테스트를 작성하려면 많은 (좋은) 상점에서 많은 시간이 걸릴 것입니다.
따라서 2-1 비율이 좋습니다. 경험이 적은 개발자는 종종 테스트에 항상 시간을 고려하지 않습니다.

수익을 줄이는 법이 있습니다. 가장 위험한 코드에 대한 테스트를 먼저 작성한다고 가정하면 추가 테스트에서 생성 된 값이 시간이 지남에 따라 줄어 듭니다.

단위 테스트는 코드이므로 다른 모든 코드와 마찬가지로 버그가 포함됩니다. 이러한 버그를 수정하려면 시간이 걸립니다.

내 경험상 단위 테스트에는 테스트하는 시스템보다 훨씬 많은 버그가 포함되어 있으며이를 수정하는 것은 지속적인 부담입니다.

이것은 품질에 관한 것입니다.

시장에 진출해야하는 경우 최대한 빨리 앱을 개발해야합니다. 자동 테스트를 전혀 할 수는 없지만 =) 경쟁사보다 먼저 청각에 앱을 제공합니다.

그러나 당신이 당신의 청각이 사라지지 않는다는 것을 알고 있다면 당신은 그들을 실망시킬 수없는 일을 할 것입니다. 모든 버그 티켓은 명성을 떨어 뜨립니다. 하나의 버그가 평판의 50 %를 제거하고 다른 하나는 25 %를 제거한다고 상상해보십시오. 너무 많은 테스트가있을 수 있습니까?

"정상입니까?"라는 말이 일반적인지 아닌지 물어 보면 그렇지 않습니다. 많은 개발 팀은 테스트 관행이 열악하고 (저는 하나에 속합니다) 심지어 책보다 기능을 코딩하는 데 많은 시간을 할애하는 조언을 읽은 양질의 책을 가지고 있습니다. 정상이라면 건강에 문제가되는지에 따라 다르지만, 필요한 것보다 2 배 더 많은 검사가없는 것이 좋습니다.

중요 할 필요는 없습니다 . 기능을 테스트 할 때는 최종 사용자에게 유용한 기능을 테스트 하며 항상 올바르게 작동하는지 아는 것은 귀하의 책임입니다. 해당 목표에 대해 두 배 더 필요한 경우 가능하면 그렇게해야합니다.

자동화 된 테스트에 대해서는 정책이 너무 엄격 할 수도 있지만, 목표로하는 품질, 리소스 및 기타 할당 대상을 모른 채 말하기는 어렵습니다.