단위 테스트는 개발 또는 테스트입니까?

단위 및 통합 테스트의 역할에 대해 테스트 관리자와 논의했습니다. 그녀는 개발자에게 유닛 및 통합 테스트 대상 및 방법을보고하도록 요청했습니다. 저의 관점은 단위 및 통합 테스트가 테스트 프로세스가 아닌 개발 프로세스의 일부라는 것입니다. 의미를 넘어서는 의미는 단위 및 통합 테스트가 테스트 보고서에 포함되어서는 안되며 시스템 테스터는 이에 대해 걱정해서는 안된다는 것입니다. 나의 추론은 두 가지에 근거합니다.

1. 단위 및 통합 테스트는 항상 인터페이스 및 계약에 대해 계획 및 수행됩니다. 공식화 된 계약을 사용하는지 여부에 관계없이 방법, 예를 들어 계약서 등 수행 할 작업을 계속 테스트합니다.

   통합 테스트에서는 두 개의 서로 다른 모듈 간의 인터페이스를 테스트합니다. 인터페이스와 계약에 따라 테스트 통과시기가 결정됩니다. 그러나 항상 전체 시스템의 제한된 부분을 테스트합니다. 반면에 시스템 테스트는 시스템 사양에 따라 계획되고 수행됩니다. 사양에 따라 테스트 통과시기가 결정됩니다.

2. 폭과 심도 및 통합 테스트를 (시스템) 테스터에게 전달하는 데 아무런 가치가 없습니다. 특정 비즈니스 계층 클래스에서 수행되는 단위 테스트 종류를 나열하는 보고서를 작성한다고 가정합니다. 그에게서 무엇을 빼앗아 야합니까?

   테스트해야 할 것과 그렇지 말아야 할 것을 판단하는 것은 모든 단위 및 통합 테스트를 통과하더라도 시스템이 사양에 필요한 방식으로 작동하지 않을 수 있기 때문에 잘못된 결론입니다.

이것은 쓸모없는 학문적 토론처럼 보일 수 있지만, 내가 공식적인 환경에서 일하는 경우 실제로 우리가하는 일을 결정하는 것이 중요합니다. 어쨌든, 나는 완전히 틀린가?

자동화 된 테스트 작성은 개발자의 작업입니다. 테스트는 코드베이스의 일부이므로 처리해야합니다. 프로젝트의 나머지 부분과 동일한 코드 검토, 코딩 표준, 소스 제어 규칙 등이 적용되어야합니다.

상기 테스트를 수행하는 것은 두 가지 이유에서 수행된다 : 첫째, 개발자를 안내하는 도구로서. 테스트를 실행하여 방금 작성한 코드가 예상대로 작동하는지 확인하고 추가 문서로 사용하며 변경 사항으로 인해 기존 기능이 손상되지 않는지 확인합니다. 실제 TDD를 수행하는 경우 테스트는 기술 사양의 권위있는 소스이기도합니다. 테스트를 사용해야하는 두 번째 이유는 QA 및 배포 중입니다. 모든 자동 테스트를 실행하는 것은 모든 테스트 라운드의 첫 단계 중 하나 여야합니다. 자동화 된 테스트를 실행하는 것은 저렴하며 (실제로 인력이 전혀 필요하지 않음) 자동화 된 테스트에 실패한 경우 수동 테스트를 수행하는 것은 의미가 없습니다.

이것은 책임이 다음과 같아야 함을 의미합니다.

• 개발자는 자동 테스트를 작성합니다
• 개발자는 개발 워크 플로의 일부로 필요에 따라 개별 자동화 테스트를 실행합니다
• QA는 테스트의 첫 단계 중 하나로 모든 자동 테스트를 실행합니다.

빌드 서버가있는 경우 QA의 작업 (자동 테스트 관련)이 "빌드 서버의 보고서를 열고 모든 것이 녹색인지 확인"으로 귀결됩니다.

그녀에게 그 보고서가 필요한 이유 를 분명히 밝히는 것이 가장 중요하다고 생각합니다 .

매우 다양한 전략이 필요한 여러 가지 설명이있을 수 있습니다 (여러 답변에서 제안한대로).

• 그녀가 합리적인 사람이고, 단순히 테스트 팀의 작업을 돕기 위해 정보를 얻고 자한다면, 일반적인 이해를 얻고 두 사람에게 적합한 솔루션을 찾는 것이 합리적입니다. 단위 테스트의 특성과 단위 대 기능 / 시스템 / 수락 테스트의 기본 차이점에 대해 논의 할 수 있습니다. 바라건대 당신은 그녀가 이것들이 매우 다른 수준에서 작동하고 다른 것을 대체 할 수 없다는 것을 이해할 수 있습니다.
• 그녀가 통제 괴물이나 관료라면 그것을 위해서만 보고서를 요구하면 최소한의 노력으로 그녀의 변덕을 만족시킬 수있는 무언가를 만들 수 있습니다 (예 : @Doc이 제안한 :-).
• 그녀가 파워 ​​게임을하고 있다면 개발자에게 보고서를 요구할 권리가 있는지 의문을 가질 수 있습니다. 내 경험상 개발자는 대개 QA 부서에보고하지 않아야합니다.

QA 및 개발의 역할과 상호 작용은 조직마다 크게 다를 수 있다고 생각합니다. 그러나 일반적으로 팀에서는 멤버에게 참여하여 기본적으로 품질 보증 팀이없는 것처럼 가장하여 프로덕션으로 진행중인 변경에 대한 책임을 진다고 말합니다. Google 품질 관리팀은 개발자 테스트에 대해 많이 생각하지 않으며 시스템 전체를 기능적으로 전체적으로 테스트합니다.

이러한 이유로 Google의 품질 관리팀은 테스트를 시작하기 전에 단위 테스트가 무엇인지, 단위 테스트가 아닌지에 대해 전혀 신경 쓰지 않습니다.

QA 팀이 단위 테스트가 무엇을 다루고 다루지 않는지를 높은 수준에서 이해하는 것이 도움이된다고 생각합니다.이를 통해 우리는 간격과 더 엄격한 부분을 파악하기 위해 공동으로 작업 할 수 있습니다. 따라서 동료는 세부적인 내용과 달리 높은 수준의 요약을 얻은 것일 수 있습니다.

그녀는 개발자들이 유닛 및 통합 테스트 대상과 방법을보고한다고 주장했다.

그녀는 실제로 이런 종류의 테스트가 실제로 "개발"영역에 있는지에 대해 논쟁하려고합니까, 아니면 코드가 단위 테스트에 얼마나 잘 적용되는지 알아 내려고합니까? 귀하가 제공 한 정보를 살펴보면 코드의 어느 부분이 다루어지고 어디에서 팀의 노력을 집중해야 하는지를 알고 싶어하는 것 같습니다.

개발 직책으로 이사하기 전에 학교 밖에서 테스트 팀에서 일했으며 이것이 팀과 팀에게 어떻게 가치가 있는지 알 수 있습니다.

나는 그것이 너무 중요하다는 것을 알지 못한다.

QA / Testing에 제공하지 않고 적절한 테스트를 수행하지 않고 프로덕션에서 실패하면 지정된대로 작동하는지 확인하지 않고 QA를 통해 프로덕션으로 전환하는 것은 결함입니다.

QA / 테스트에 제공하고 적절한 테스트를 수행하지 않으면 제공하지 않은 것과 동일한 결과를 얻습니다.

그러나 당신이 그것들을 제공한다면, 그들은 또한 그것들을 스펙과 비교하고 그리고 / 또는 어떤 테스트에 결함이 있는지, 또는 버그를 발견했기 때문에 변경이 필요한지를 제안 할 수 있습니다.

실제로, 나는 그들을 제공하는 데 많은 단점을 보지 못합니다. 사양에 대한 유효성 검사는 여전히 품질 보증 / 테스트 중입니다. 그들이 게으른 길을 가고 그들이 모두 통과했기 때문에 테스트가 충분하다고 신뢰한다면, 그것은 그들의 일에 실패한 것입니다. 그들이 여전히 스펙을 가지고있는 한, 단위 / 통합 테스트의 결과는 단지 보풀 일 뿐이며, 어떤 식 으로든 당신을 해칠 수 없습니다. 이것이 우리가 dev와 QA를 가진 이유입니다. 앱이 지정된대로 수행되는지 여러 번 확인합니다.

개발자는 실수를하고, QA는 실수를합니다. 이상적으로는 같은 항목에 대해 실수를하지 않습니다.

단위 테스트는 코드 조각 자체의 작동 방식을 이해하는 데 유용 할 수있는 개발자의 책임입니다. 일부는 이것을 문서 형식으로 볼 수 있으므로 단위 테스트를 정기적으로 변경하면 오버 헤드가있을 수 있지만 가치가 있습니다.

테스트를 통과 할 때의 또 다른 가치는 기본 기능을 보장하는 측면에서 중복 될 수있는 테스트를 두 배로 늘릴 수 없다는 것입니다.

최종 사용자가 시스템의 작동 방식에 대한 자신의 이해를 가질 수 있기 때문에이 모든 것과 별 개인 사용자 승인 테스트도 있습니다.

귀사에 자사 제품의 품질을 보장하기 위해 정의 된 방법론이있는 경우 (SOX 호환이거나 CMMI 레벨을 개선하려는 경우에는 가능할 것임), 제품은 프로세스를 입증하기 위해 감사를 견딜 수 있어야합니다. 따라 갔다.

정의 된 프로세스에는 종종 단위 테스트가 포함됩니다. 불행히도 이것은 또한 단위 테스트를 문서화하고 감사를 위해 실행되었음을 증명해야한다는 것을 의미합니다. 따라서 단위 테스트를보고 할 방법이 필요합니다.

Sonar와 같은 도구를 사용하면 코드 적용 수준과 단위 테스트 실행 결과를보고 할 수 있습니다.

이것은 실제로 회사에 달려 있지만 기존의 접근법에서 시스템 테스터로 일한 경험이 있지만 CD 모델의 민첩한 팀에서 일하는 테스터로 일하면서 테스팅 및 통합 테스트 대상이 무엇인지 아는 것이 매우 유용합니다.

품질은 팀의 책임입니다. 개발자, 테스터 및 제품 관리 및 협력은이를 보장하는 가장 좋은 방법입니다.

따라서 테스트 관리자는 단위 및 통합 테스트 대상을 알고 싶어하며 개발자에게는 약간의 추가 작업이지만 프로젝트의 전체 작업을 저장합니다! 정보를 테스트 관리자에게 제공함으로써 테스트 팀의 노력이 중요하고 중요한 것에 집중할 수 있습니다. 앞에서 언급했듯이 코드 영역이 단위 테스트되지 않은 경우 팀은 심하게 테스트 된 영역과 비교하여 노력을 집중할 수 있습니다. 정시에 출시 된 고품질 소프트웨어라는 동일한 목표를 향해 노력하고 있습니다.

이런 종류의 것을 제공하는 것이 유리할 것이라고 생각합니다. 단위 테스트 범위는 개발 및 테스트에서 알려진 것으로서이를 설명 할 수 있어야합니다.

분명히, 당신은 비즈니스 중요 사항을 테스트해야합니다. 단위 테스트 적용 범위가 큰지 여부에 관계없이 일반적으로 사용되는 기능을 열심히 테스트해야합니다. 다른 장소가 단위 테스트로 덮여 있는지 알려주는 것은 아프지 않았습니다. 이 작은 컨트롤에서 코드가 이미 엣지 케이스를 확인합니까? 이런 종류의 물건은 사업의 모든 측면에서 아는 데 도움이됩니다.

"Google의 소프트웨어 테스트 방법"책에서 논의 된 접근 방식을 언급 할 가치가 있습니다. 테스트 및 품질 관리는 모든 사람의 책임이며 표준은 엄격합니다.

실제 전통적으로 "테스트"부서 소위의 역할은 실제로 개발자의 생산성이다; 즉, 조직이 경제적으로 필요한 수준의 엄격 성을 달성 할 수 있도록하는 자동화.