개발자가 테스트 단계에 참여해야합니까?

우리는 고전적인 V 자형 개발 프로세스를 사용하고 있습니다. 그런 다음 요구 사항, 아키텍처, 디자인, 구현, 통합 테스트, 시스템 테스트 및 승인이 있습니다.
테스터는 프로젝트의 첫 단계에서 테스트 사례를 준비하고 있습니다. 문제는 리소스 문제 (*)로 인해 테스트 단계가 너무 길고 시간 제약으로 인해 종종 단축된다는 것입니다 (프로젝트 관리자는 알고 있습니다 ...;)). 개발자는 원하는대로 단위 테스트를 수행하고 있습니다.

따라서 제 질문은 간단합니다. 개발자가 테스트 단계에 참여해야하며 너무 위험하지 않습니까? 작업이 완료되었으므로 프로젝트 관리자에게 더 나은 품질에 대한 잘못된 느낌을 줄 것이라 두려워하지만 추가 된 man.days는 어떤 가치가 있습니까? 필자는 개발자가 테스트를 수행하는 것에 대해 확신이 없습니다 (여기서 위법 행위는 없지만 며칠 만에 몇 번의 클릭으로 침입하는 것이 매우 어렵다는 것을 알고 있습니다).

의견을 보내 주셔서 감사합니다.

(*) 모호한 이유로 테스터 수를 늘리는 것은 현재로서는 선택 사항이 아닙니다.

(단순히, 그것은 프로그래머가 테스트 설계에 테스터를 도와 주어야 하는가? 개발자의 영향을 피하는 테스트 준비가 아니라 테스트 실행에 대해 이야기 해야하는 것은 아니다)

당신의 질문을 문자 그대로 보는 것 ( "관련") 나의 유일한 대답은 절대적입니다.

예

개발자는 자신 의 코드 에 대해 최종 결정을 내려서는 안됩니다 .

그러나 개발자는 다른 개발자의 작업을 테스트하는 데 참여해야합니다. 두 가지 작업을 수행합니다.

1. 테스트에 대한 개발자의 통찰력을 제공합니다. 이는 특정 시점에서 사용중인 API, 해당 API에서 발생할 수있는 예외 및 처리 방법을 아는 일반적인 경우입니다. 또한 개발자가 QA보다 왜 수행되고 있는지에 대한 다양한 토론에 더 많은 노출을 가져 오기 때문에 특정 프로젝트에 도움이됩니다. 개발자가 일반적으로 더 많은 정보를 제공하고 즉시 문제를 해결하는 방법에 대해 더 많은 통찰력을 제공하기 때문에 개발자가 발견 한 버그도 수정하는 것이 더 저렴할 수 있습니다.
2. 응용 프로그램에서 노출되지 않을 수있는 부분에 개발자에게 노출됩니다. 이렇게하면 장기적으로 해당 앱의 개발자가 더 좋아질 것입니다. API 사용 방식을 알면 사양을 벗어난 것보다 다음에해야 할 일을 예상하는 것이 훨씬 좋습니다. 가장 중요한 것은 응용 프로그램과 응용 프로그램을 알고 있으면 코딩을 시작하기 전에 사양이 잘못되었는지 알 수 있습니다.

마지막으로, 가능한 많은 눈을 사용하지 않는 이유는 무엇입니까? 채용 및 온 보딩 프로세스를 거치지 않아서 추가 QA 직원이 위기에 처할 수있는 경우는 거의 없습니다. 그래서 필요한 여분의 눈을 어디서 찾을 수 있습니까? 아니면 모두 같은 QA로 위기 시간을 극복하려고하십니까? 개발자가 테스트 시간의 20 %를, 버그가 발생하는 모든 것을 수정하는 데 80 %를 소비하더라도 이전보다 앱에 더 많은 관심을 기울입니다. 자동 테스트는 특정 수준의 보증 만 제공하며 절대 100 %는 아닙니다.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

단위 테스트 이외의 것은 절대 아닙니다. 개발자는 앱에 대해 너무 많이 알고 있으며 객관적인 테스터가되기 위해 어떻게 작동해야하는지 알고 있습니다.

개발자와 Q 사이의 철학 테스트의 근본적인 차이점은 이것입니다. 프로그래머는 일반적으로 자신의 코드가 작동하는지 증명하기 위해 프로그램을 테스트합니다 ( "긍정적 인"테스트). 품질 보증팀에서는이 작업을 수행 할 수 있으며 수행 할뿐만 아니라 "부정적인"테스트를 사용하여 소프트웨어를 중단하여 작동하지 않는 항목 을 찾는 데 중점을 둡니다 .

QA 직원이 소프트웨어 작동을 "증명"하는 테스트로 인해 잠재적으로 QA 직원이 손상 될 수있는 경우 개발자 테스트와 QA 테스트 사이에 격리 가 있어야합니다 . 개발자는 작동하는 것을 시연하여 QA 테스트를 확실히 도울 수 있지만 소프트웨어가 고장 나지 않는지 독립적으로 확인하는 것은 QA의 책임입니다.

프로그래머가 테스트 노력을 지원하기 위해 할 수있는 최선의 방법은 요구 사항 문서의 개별 요구 사항에 맞는 테스트를 포함하는 포괄적이고 고품질의 검증 가능한 단위 테스트 스위트를 제공하는 것입니다.

테스트 측면에서 3 가지 유형이 있습니다.

블랙 박스, 그레이 박스 및 화이트 박스.

블랙 박스는 제품의 내부 작동 방식에 대한 지식없이 제품을 테스트하는 사용자를 나타냅니다.

회색 상자는 컴퓨터 프로그래밍에 대한 지식은 있지만 개발 팀에는없는 고급 사용자를 나타냅니다. 이 사람들은 제품에 메모리 누수, 시스템 요구 사항 문제 등이 있는지 테스트합니다.

주요 부분은 다음과 같습니다. 흰색 상자는 코드 수준에서 제품을 테스트하는 개발자를 나타냅니다. 이것은 단위 테스트, 디버깅 등을 수행한다는 것을 의미합니다.

따라서 사용자와 개발 팀이 모두 테스트 단계에 참여하는 것이 좋지만, 각 테스트에는 테스트 대상에 따라 사용자 및 개발 팀의 적절한 커미트 레벨이 필요합니다.

단위 테스트는 모든 개발자에게 필수입니다

이것이 당신의 이익에 어떻게 사용될 수 있는지에 대한 정보는 C ++ 개발에 있다면 다음 링크를 통해 읽으십시오 :

• Google C ++ Testing Framework에 대한 간단한 소개
• 오픈 소스 C / C ++ 단위 테스트 도구, 1 부 : Boost 단위 테스트 프레임 워크 알아보기
• 오픈 소스 C / C ++ 단위 테스트 도구, 3 부 : CppTest에 대해 알아보기

품질 관리 담당자가 이러한 테스트를 수행 할 수있는 방법은 없습니다. 절대 안돼.

프로젝트에 많은 수의 개발자가 있다고 가정하면 반드시 개발자가 테스트 작업을 수행하게합니다. 한 가지주의 할 점은 개발자가 자체 코드에 대한 테스트 (단위 테스트는 포함하지 않음)를 수행하지 않는다는 것입니다.

오히려 관리 직원 (또는 실제 잠재 사용자)이 개발자보다 QA 테스트를 수행하는 것을 볼 수 있습니다. 제품의 작동 방식을 모르는 사람은 사용하려고합니다. 개발자는 테스트에 접근하는 방법이 매우 제한적인 경향이 있으며 QA 테스트에 사용하기에는 시간당 너무 비쌉니다.

당신은 쓰기:

문제는 리소스 문제 (*)로 인해 테스트 단계가 너무 길고 시간 제약으로 인해 종종 단축되는 것입니다. 개발자가하지 않기 때문입니다. 가장 안정적인 제품을 제공하는 가장 큰 인터넷 회사 중 하나는 테스터를 전혀 사용 하지 않습니다 . 개발자가 직접 수행 한 자동 테스트 만 사용합니다. 결과는 개발자가 "테스터"에게 테스트를 떠나는 것보다 x10 더 나은 제품입니다.

건설 노동자가 집을 짓는 것과 같지만 다른 팀이 건물이 실제로 서 있고 문이 열리고 닫히고 에어컨이 작동하는지 확인하십시오. 신뢰할 수없는