프로그래머는 나쁜 테스터입니까?

나는 이것이 이미 요청 된 다른 질문과 비슷하게 들리지만 실제로 약간 다릅니다. 일반적으로 프로그래머는 응용 프로그램 테스트 역할을 수행하는 데 능숙하지 않은 것으로 간주됩니다. 예를 들면 다음과 같습니다.

Joel on Software- 테스터가없는 5 가지 이유 (강력한 이유 )

대학 CS 졸업생들에게 그들이 당신을 위해 일할 수 있다고 말하지는 않지만 "모두가 코드로 넘어 가기 전에 한동안 QA를해야한다"고 생각하지 마십시오. 나는 이것을 많이 보았다. 프로그래머는 훌륭한 테스터를 만들지 않으며 , 교체하기가 훨씬 어려운 좋은 프로그래머를 잃게됩니다.

그리고이 질문 에서 가장 인기있는 답변 중 하나는 (다시 강조합니다)

개발자는 테스터가 될 수 있지만 테스터가되어서는 안됩니다. 개발자는 의도하지 않게 / 부주의하게 응용 프로그램을 손상시킬 수있는 방식으로 사용하지 않는 경향이 있습니다. 그것은 그들이 그것을 작성하고 주로 사용해야하는 방식으로 테스트하기 때문입니다.

문제는 프로그래머가 테스트에 나쁜가? 이 결론을 뒷받침 할 어떤 증거 나 주장이 있습니까? 프로그래머는 자신의 코드를 테스트하는 데만 나쁜가요? 프로그래머가 실제로 테스트에 능숙 하다는 증거가 있습니까?

"테스트"란 무엇을 의미합니까? 나는 할 수 없습니다 평균 단위 테스트 또는 쓰기 소프트웨어 소프트웨어 팀에 의해 사용되는 방법론의 일부로 간주됩니다 아무것도. 코드를 작성하고 소프트웨어 팀이 "테스트 환경"이라고 부르는 모든 곳에 배포 한 후에 사용되는 일종의 품질 보증 방법을 의미합니다.

질문은 시스템 테스트 에 대해 특별히 묻는 것처럼 보이 므로이 답변 전체에서 언급하고 있습니다.

나는 테스트를 수행하기로 선택한 나쁜 사람과 실제로 테스트에 나쁜 사람 사이에 중요한 차이점이 있다고 생각합니다.

프로그래머가 테스트에 나쁜 이유 :

• 만약 당신이 코드를 작성했다면, 당신은 이미 가능한 많은 방법을 생각하여 잘못되었을 수 있고 그것을 처리해야합니다.
• 특히 엉뚱한 버그를 발견했다면 버그를 수정하여 코드베이스에서 문제를 해결할 수 있다면 동기 부여에 도움이되지 않습니다.

프로그래머가 테스트에 능숙한 이유 :

• 프로그래머는 논리적으로 사고하는 경향이 있으며 체계적으로 작업하는 데 능숙합니다.
• 숙련 된 프로그래머는 최신 사례를 신속하게 파악하여 유용한 테스트를 수행 할 수 있습니다. 공식적인 테스트 프로세스가있는 경우 시스템 테스트 전에 이러한 모든 사례를 이미 식별하고 테스트해야합니다.
• 프로그래머는 유용한 정보가 모두 버그 보고서에 포함되도록하는 데 능숙합니다.

프로그래머가 나쁜 테스터 인 이유 :

• 프로그래머는 테스터보다 훨씬 비쌉니다 (대부분의 경우).
• 사고 방식은 근본적으로 다릅니다 : "(작동하는) 제품 빌드" 와 "이것은 (알려지지 않은) 버그가있는 문을 나가지 않습니다."
• 테스터는 일반적으로보다 효율적입니다. 즉, 같은 시간에 더 많은 테스트를 수행합니다.
• 프로그래머는 프로그래밍을 전문으로합니다. 품질 관리 전문가는 테스트를 전문으로합니다.

프로그래머가 자신의 코드 를 테스트하는 데 어려움을 겪고 있다고 생각 합니다 .

우리는 코드가 요구 사항에 따라 완벽하게 작동한다고 믿고 싶었습니다. 내 장소에서 우리는 우리 자신의 코드를 테스트 한 다음 실제 테스트 사이클을 시작하기 전에 서로 코드를 테스트하고 우리 자신의 코드를 테스트하는 것보다 훨씬 많은 버그가 발생했습니다.

프로그래머는 확실히 시스템의 일부를 테스트 할 수있는 올바른 사람입니다. 그 곳에서 효과적으로 수행 할 수있는 유일한 사람입니다.

프로그래머가 테스트에 매우 나쁜 경향이있는 한 장소는 전체 "일반 사용자처럼 UI 사용"비트입니다. 일반 사용자가 아니고 그들처럼 행동하지 않습니다. 예를 들면 다음과 같습니다.

• 프로그래머는 텍스트 입력을 올바르게하는 경향이 있습니다. 내가 볼 수있는 매우 일반적인 문제는 앞뒤 공백입니다. 대부분의 사람들은 그렇지 않은 것처럼 보이지만 훌륭한 프로그래머는 아마도 외부 공간없이 문자열을 올바른 문자열로 만드는 것에 대해 종교적 일 것입니다.
• 프로그래머는 키보드 연주자 인 경향이 있으며 작업 속도를 높이기 위해 탭과 기타 단축키를 활용합니다. 일반 사용자는 필드 사이에서 마우스를 잡는 경향이 있습니다.
• 프로그래머는 오류 메시지를 무시하고 확인을 누르기보다는 시스템이 말하는 내용을 이해하는 경향이 있습니다.

따라서 일반 사용자는 프로그래머가하지 않는 많은 일을합니다. UAT를 개발 팀에 전적으로 의존 할 수는 없습니다.

기술 수준 (단위 테스트, 통합 테스트, 회귀 테스트)에서 프로그래머는 아마도 테스터가 될 수있는 유일한 자격을 갖춘 사람 일 것입니다. 이러한 종류의 테스트는 자동화가 가능하고 자동화되어야하기 때문에 프로그래밍이 필요합니다.

그러나 나는 그것이 당신이 말하는 것이라고 생각하지 않으며, Joel Spolsky가 의미하는 것이 아니라고 확신합니다. 그것은 남아있는 부분, 실제 수동 테스트입니다. 테스트 스크립트를 작성한 다음 완성 된 제품에 대해이 스크립트를 세 심하게 실행합니다.

좋은 테스터가 되려면 좋은 프로그래머를 만드는 사람들과 거의 직교하는 자질이 필요합니다. 약간의 겹침이 있습니다-분석적으로 생각할 수 있어야하며 일반적으로 컴퓨터와의 특정 친화력이 필요합니다. 그러나 그 외에는 테스터의 기술이 많이 다릅니다. 그렇다고해서 기술 세트를 둘 다 가질 수있는 것은 아니며 실제로는 일부 사람들이 할 수도 있습니다. 그러나 정말 좋은 프로그래머가 되려면 특정 게으름이 필요합니다 (집안일을 자동화하려는 욕구). 반면에 정말 좋은 테스터는 지속성이 필요합니다. 테스터가되기 위해서는 일반적으로 아이디어를 혐오합니다.

그리고 선택적인 편견이 있습니다 : 이미 프로젝트에 참여한 프로그래머는 비록 조금이라도 이미 코드베이스에 대한 내부 지식을 가지고 있으며 최종 사용자의 관점에서 빈 마음으로 접근하는 데 어려움을 겪을 것입니다 . "이 버튼이 작동한다는 것을 알고 있으므로 '통과'만 주목할 것"과 같이 명시적일 필요는 없습니다. 좀 더 미묘 할 수 있으며, 이러한 미묘한 영향으로 인해 테스트에서 중요한 경우를 놓칠 수 있습니다.

내 경험으로는 프로그래머는 나쁜 테스터입니다. 너무 자주 나는 다른 사람들을 보았고, 나는 "어, 그러나 나는 체크인하기 전에 그것을 테스트했다!" 테스터가 당신 앞에있는 버그를 재현 할 때

왜? 글쎄, 왜 그런지 잘 모르겠지만 아마도 그것이 작동하는 것을보고 싶기 때문일 수 있습니다. 또는이 기능 또는 이미 해당 기능을 테스트하고 싶습니다.

어쨌든 테스트는 우리가 배운 기술이 아니며 기능을 잘 익히기 때문에 프로그래머로 일하지 않습니다. 또한 적절한 테스트 계획을 수행하는 방법이나 QA가 수행하는 다른 모든 작업을 수행하는 방법을 모를 수도 있습니다. 테스터가 새로운 3D 렌더링 파이프 라인을 구현할 수있는 자격을 갖춘 것보다 더 이상 테스터 업무를 수행 할 자격이 없습니다.

질문에서와 같이 테스트는 자동화 된 것이 아니라 실제로 프로그램을 사용하여 테스트하는 것을 의미합니다.

몇 가지 수준의 테스트가 있습니다. "저수준"테스트는 개발자가 수행 할 수 있으며 반드시 수행해야합니다. 나는 단위 testig 생각합니다.

반면 "높은 수준"테스트는 완전히 다른 것입니다. 일반적으로 나는 개발자가 기술을 놓치기 때문에 나쁜 테스터라고 생각합니다. 그러나 생각하기가 어렵고 몇 시간 안에 일하는 방식이 매우 어렵 기 때문입니다.

가능한 한 내 코드를 최대한 흐리게 테스트하는 데 사용하지만 테스터가 최소 10 분 동안 작성한 후에는 버그 또는 개선 사항을 고려해야합니다. 이것은 당신이 만든 것을 테스트하는 것이 어려운 일임을 의미합니다. 클릭 위치, 클릭시기, 비즈니스 로직, 데이터 유지 방법을 알고 있습니다. 당신은 결코 넘어지지 않을 신입니다.

어떤 종류의 테스트를 의미합니까? 포괄적 인 철저한 테스트를 의미하는 경우, 가능한 모든 입력 조합을 이러한 테스트의 요구 사항으로 간주하면 대부분의 사람들 이이 범주에서 가난한 사람이라고 생각하지만 예라고 말하는 근거가 있습니다.

소프트웨어를 디자인하는 개발자는 코드가 처리해야 할 부분에 터널 비전이있을 수 있으며 고려되지 않았을 수있는 경계 사례를 무시할 수 있음을 인정할 수 있습니다. 예를 들어, 숫자 n을 취하는 웹 양식을 작성한 다음 화면에 1에서 n까지 인쇄하면 아무 것도 입력되지 않거나 e 또는 pi와 같은 자연수가 아닌 경우와 같은 특별한 경우가 누락 될 수 있습니다 . 이 경우 프로그램이해야 할 일은 의심 스러울 수 있습니다.

테스트 주도 개발 (Test Driven Development) 은 테스트를 다른 관점에서 다른 관점으로 볼 수있는 개발 방법론의 한 예일 것입니다.

프로그래머는 코드 를 작성 하기 전에 테스트 를 정의 할 때 테스트를 잘 정의 할 수 있습니다. 연습하면 더 좋아집니다.

그러나 작성한 코드에 대한 테스트를 정의 할 때는 잘 수행되지 않습니다. 테스트에서 코드 작성과 동일한 사각 지대를 갖게됩니다.

프로그래머를 사용하여 수동 테스트를하는 것은 어리석은 일입니다. 수동 테스트는 그 자체로는 어리 석습니다. 프로그래머가하는 일은 매우 어리 석습니다. 비싸고 유능한 프로그래머를 몰아냅니다.

특히 개발자가 실패한 것으로 보이는 한 가지 유형의 테스트는 요구 사항이 충족되는지 테스트하는 것입니다. 개발자가 요구 사항에서 무언가를 생각하는 것과 테스터가 의미하는 것은 종종 완전히 다른 두 가지입니다.

나는 최근에 develoepr이 델타 수출을 요청받은 곳과 한 번 보내지 않은 기록을 얻는 것을 의미하는 개발자의 생각을 생각할 수 있으며 테스터는 그것이 새로운 기록과 변화를 얻는 것을 의미한다고 생각했습니다. 누가 정확한지 알아 내기 위해 고객에게 돌아 가야했습니다. 코드를 검토하고 개발자가 요구 사항에 대해 수행 한 것과 동일한 가정을했습니다. 논리적으로 업데이트를 포함하려면 업데이트를 언급했을 것입니다. 그리고 나는 보통 사용자의 사물에 있었기 때문에 모호한 것을 발견하는 데 능숙합니다.

따라서 테스트를 수행하는 다른 개발자들도 같은 가정을 많이하는 경향이 있습니다. 왜냐하면 "할 수 있기 전에 많은 세부 사항이 있기 때문에 X 부 Y를 의미한다면 더 자세했을 것입니다. 그러나 요구 사항 작성자는 그렇게 생각하지 않으므로 요구 사항 작성자와 같은 생각을하는 사람은 개발자의 가정을 테스트해야하고 개발자가 아닌 사람은 문제가있는 것을 더 잘 볼 수 있습니다.