테스터는 제품 개발에 대 한 중요 한

년 동안, 내가 테스트, 테스트, 및 전체 소프트웨어 품질 관리 시스템에 대 한 내 견해의 일부를 형성 했다. 그리고 그래서 난 그것을 기록 하 고 사람들에 게 보여주고 싶 나 페이스 북 테스트에 대 한 게시물에서 영감을 했다. 논쟁의 몇 가지 포인트를 있을 수 있습니다. 음, 사실, 조금 이라도 표현 대화에 그의 경 멸 사람들을 얻을 수 있다.

1. 대부분의 개발 팀은 독립적인 테스트 역할 필요 같지 않습니다. 도 하나, 그의 개발 시간이 모든 시간과 모든 테스트 해야 > 20:1. 요구 하는 당신이 나 증거? 고 대 시간에서 가장 성공적인 소프트웨어 개발 팀의 일부를 참조 하 고 싶습니다. 그것은 오늘, 페이스 북 이나 원래 NT 팀 30 년 전, 많은 좋은 제품은 실제로 팀에서 전혀 또는 거의 테스터와 함께.

2. 개발자는 자신의 코드를 테스트 해야 합니다. 이 말하는 것을 아무것도 있을 수 있습니다. 그리고 그것의 뒤에 진실을 중요 하지 않습니다. 이 자동화 된 테스트 또는 수동 또는 조합 테스트의 단위 테스트, 전체 범위를 포함합니다. 개발자 수 없습니다 또는 내키지 또는 생각이 "에 속하지 않은 나" 하는 경우, 분명히 더 나은 프로그래머가 필요.

3. 나 말을 정치적으로 올바르지 않은 몇 가지 단어가 있다. 일부 대규모 소프트웨어 개발 회사는 다양 한 개발 작업에 대 한 자격이 되지 않는다 프로그래머에서에서 테스터를 선택 합니다. 많은 사람들이 말하는 인터뷰 개발자 과정, "그녀가 하지 않습니다 개발." 들었어요. 아마 당신은 할 수 테스트 "? 이것은 널리 묵시적으로 허용 하지만 거의 공인 된 인식: 개발 하 고 만큼 영리 하지 않습니다 테스트를 하 고. 그 열정과 품질 및 테스트에 재능 있는 사람들이 소수 불공평 하 게 취급 되어이 보급 편견 때문 이다. 난 그들 때문에 내가이 사람들 중 일부와 함께 일 했습니다.

4. 그것은 위험 코드 테스트 범위를 추구 합니다. 때문에 측정 하기 쉽습니다, 그것은 종종 실제 목표에 대 한 대체 된다-품질 소프트웨어 개발. 개발 팀은 거의 사용할 수--일부 보고서에는 데이터 표시 되므로 모든 단일 코드 경로를 바보 테스트를 작성 쿵푸를 사용 하는 경우 문제가 있는. 테스트 범위는 우리가 사용 하는 많은 통계 수치 중 하나, 그것을 사용 해야 하지만 자연 수에 표시 되지 않기 때문에 그것은 다른 통계를 압도 할 수 있습니다. Goodhart의 법률의 피해자가 되었다.

5. 나 또한 매우 좋은 테스트 코드 작성 독립 테스터와 함께 일부 회사 봤어요. 불행히도,이 전혀 필요 하지 않은 경우에 일반적인 의미입니다.

6. 마찬가지로 테스트 범위 남용 일부 품질 메트릭을 간과 된다. 예: 얼마나 많은 기술 지원 메일 과정에서 생성 된? 당신은 정말 모든 시간에 당신의 자신의 제품을 사용 하 고 내부 문제를 확인? 생산 환경 및 고객 설치에서 생성 된 로그 파일을 분석. 이러한 전략의 모든 위의 언급은 페이스 북이 게시물.

7. 테스트 팀의 볼륨을 줄이기 위해 기술 지도자를 위한 일반적인 방법은 자동화 된 테스트를 할 것입니다. 이것은 큰 실수 이다. 만약 당신이 사용자에 게 직접 액세스할 수 있는 제품, 절대적으로 인간의 눈으로 그것을 테스트 해야 합니다. 경우 마이크로소프트 윈도 내려 앉아 팀 함께 커피, 당신은 윈도우 비스타 버그의 많은 수에서 자동화 된 테스트 결과에 과도 한 신뢰를 불평 그들을 듣게 됩니다. 이 오류와 함께 문제는 당신이 당신의 제품을 사용 하 여 풀 타임 테스터 필요.

Sriram Krishnan,이 문서의 저자는 야후와 마이크로소프트에 근무 하고있다 프로그래머 많은 소프트웨어를 개발, 뉴욕 타임즈에 의해 보고 되었습니다,이 기사는 그의 블로그 중 하나는 책을 썼다.

원래 링크: 테스터와 테스트에