개발자가 자신의 작업을 테스트하도록 해주는 이유

안타깝게도 내 작업 장소에서 때때로이 작업을 수행하기 때문에 개발자가 제품을 생산하기 전에 마지막 단계로 개발자가 자신의 작업을 테스트하도록하는 것은 나쁜 생각입니다. 이 주장은 다른 사람들에게 너무 바빠서 다른 사람이 프로그램의 해당 부분에 익숙해 지도록 시간을 갖지 못하는 대부분의 사람들에게 귀결되었습니다.

이 경우 테스트 계획이 있지만 (항상 그런 것은 아니지만) 실제로 테스트를 거친 테스트를 수행하지 않은 사람을 실제로 최종 테스트를 수행하는 것이 좋습니다. 그래서 나는 당신이 나에게 이것이 다음에 논의 될 때 제기 할 수있는 훌륭하고 확실한 주장 목록을 제공 할 수 있는지 묻고 있습니다. 또는 공식적인 테스트 사례가있을 때 특히 완벽하다고 생각되는 경우 반론을 제공하십시오.

다른 사람들과 자신이 지적했듯이 개발자는 자신의 코드를 단위 테스트해야합니다. 그러나 그 후, 사소한 제품은 독립적 인 사람 (QA 부서 및 / 또는 고객 자신)이 테스트해야합니다.

개발자는 일반적으로 "이 작업을 수행하는 방법" 이라는 개발자의 사고 방식으로 작업합니다. . 좋은 테스터는 "이걸 어떻게 깨뜨릴 까?" -매우 다른 사고 방식. 단위 테스트 및 TDD는 개발자에게 모자를 어느 정도 변경하도록 지시하지만 그에 의존해서는 안됩니다. 또한 다른 사람들이 지적했듯이 요구 사항을 오해 할 가능성이 항상 있습니다. 따라서 최종 승인 테스트는 고객과 가능한 한 가까운 사람이 수행해야합니다 .

개발자는 코드 작동 방식을 알고 있으며이 지식에 따라 코드를 테스트하는 습관에 빠지게됩니다.

개발자는 '어떻게 작동해야 하는가'가 아니라 '어떻게 작동하는지'라는 사고 방식에서 스스로를 제거하기가 어렵다는 것을 알게 될 것입니다.

이로 인해 객관성이 높은 사람이 프로그램을 테스트하도록하는 것이 좋습니다 (예 : QA 또는 테스트 엔지니어).

테스터 테스트 테스트, 단순 이러한 유형의 바이어스는 실제로 쇼 스토퍼를 찾기 위해 필요합니다.

개발자는 반드시 작업을 테스트해야합니다. 묵시적 책임입니다.

귀하의 진술을 바탕으로 테스트를 전담하는 팀이 없다고 가정합니다. 그러나 테스트 전용 팀이 있으면 개발자가 코드를 코딩하는 방식으로 코드를 테스트하는 경향이 있습니다. 그것은 어떤 종류의 품질 보증 팀이 있으면 이미 개발자의 책임으로 테스트를 수행 할 수 있다는 것을 의미하지는 않습니다.

개발자는 일반적으로 버그를 잡기 위해 큰 구멍이있는 그물을 사용합니다. 결과적으로 작은 버그가 빠져 나갑니다.

개발자는 자신의 코드를 깨뜨 리려고 애 쓰지 않기 때문입니다. 그들의 마음은 단순히 올바른 데이터 입력 경로와 응용 프로그램과의 상호 작용을 따릅니다. 많은 버그는 일반적인 사람 처럼 시스템과 상호 작용 한 결과입니다 . 개발자는 일반 사용자가 아닙니다. 그들은 전문 사용자입니다.

전담 테스트 팀이 있어야하는 몇 가지 이유가 있습니다. 첫째, 위에서 언급했듯이 개발자는 코드가 작동하는지 테스트하는 데 능숙하지만 깨지지는 않습니다.

또한 개발자가 작성한 내용을 알고 있지만 테스트 팀은 작성된 내용을 알고 있습니다. 때때로이 두 개념은 일치하지 않습니다. 테스트 팀의 임무 중 하나는 소프트웨어가 요구 사항을 충족하는지 확인하는 것입니다. 대부분의 경우 개발자는 시스템의 일부만 잘 알고 있지만 QA 팀은 모든 것을 알고 있습니다.

다음 이유로 테스트 팀은 완전한 통합 테스트를 수행합니다. 방금 작성한 코드는 자체적으로 잘 작동하지만 알지 못하는 다른 기능을 손상시킬 수 있습니다.

품질 보증팀과 함께 일하거나없이 QA 팀과 함께 일한 것에 대해 100 % 감사의 말을 전하며 소프트웨어 팀의 소중한 부분이라고 말할 수 있습니다. QA 팀이 있으면 철저한 테스트를 거쳤으므로 오전 3시에 전화를 덜받을 수 있으므로 코드를 훨씬 쉽게 배포 할 수 있습니다.

개발자는 자신의 코드를 단위 테스트해야합니다.

독립적 인 테스터는 테스트를 거칠뿐 아니라 개발자가 코딩하는 동안 미정의 및 정의되지 않은 가정을 테스트합니다.

개발자는 변경 사항을 적용하기 전에 초기 테스트를 수행하고 코드 작동에 만족할 것으로 기대합니다. 그런 다음 개발자는 자신이 보유한 특정 '화이트 박스'지식을 테스트 사례에 제공 할 것으로 기대합니다. 예를 들어 영향을 받았을 수있는 코드의 다른 영역을 자세히 설명합니다.

자체 코드를 테스트하는 개발자의 주요 반대 의견은 하나의 관점 만 테스트한다는 것입니다. 개발자가 사양을 읽고 해석했습니다. 바라건대 사양은 명확하고 완전하며 모호하지 않지만 항상 그런 것은 아닙니다. 개발자가 사양의 일부를 잘못 이해했을 수 있습니다. 그들이 자신의 코드를 테스트하면 함수가 예상대로 작동한다는 것을 알기 때문에 포착되지 않습니다.

다른 사람들도 다른 방식으로 제품을 사용하고 결과적으로 코드를 통해 다른 경로를 사용하는 경향이 있습니다. 개발자는 코드가 제대로 작동하는지 확인했지만 다른 테스터가 찾을 수있는 엣지 케이스를 고려하지 않았을 수 있습니다.

개발자 는 자신의 작업을 테스트 해야 합니다. 개발자가 테스트되지 않은 작업을 QA 팀 또는 개발자 동료에게 푸시하게하는 것은 정말 나쁜 생각입니다. 개발자와 테스터의 시간을 낭비하고 관계를 망칩니다.

그러나 항상 충분하지는 않습니다. 개발자는 시스템을 통해 행복한 길을 가고 있거나 개발 과정에서 계속해서 노출 된 일부 특유의 시각에 눈이 멀 것입니다.

또 다른 요점은 사양과 배포 사이에 많은 통신 계층이있을 수 있다는 것입니다. 이로 인해 최종 배포 대상에 대한 중국 속삭임 효과가 발생할 수 있습니다. 요구 사항 또는 버그 보고서를 정의한 사람이 원하는 방식으로 작동하는지 테스트하는 것이 가장 좋습니다.

개발자는 자신의 코드를 담당하고 테스트해야합니다. Does the feature work as expected?대답이 '예'이면 완료된 것입니다.

왜 테스트 케이스를하지 말아야합니까?

1. 당신은 주관적 발견 버그 (또는 동료)에 의해 기록 된대로.
2. 회사에서 케이스 테스트를 실행 하기에는 비용 이 너무 비쌉니다 . (나는 희망).

일반적으로 개발자는 대부분의 경우 특정 특수한 경우를 제외하고 코드를 사용하는 개발자가 아닙니다. 따라서 프로덕션 시스템으로 승격하기 전의 마지막 테스트 단계는 UAT (사용자 승인 테스트) 여야합니다. 그들은 일반적으로 패키지가 기대하는 것에 더 친숙해졌다. 그리고 일반적으로 일상적으로 사용하지 않는 사람에게는 익숙하지 않은 항목 흐름으로 인해 문제를 해결할 수 있습니다.

프로젝트 계획이 사용자 테스트를 제공하지 않습니까? 사용자가 테스트를 해보면 구현 후보다 일찍 버그를 발견 할 수 있습니다.

개발자는 자신의 자녀의 예술을 판단하는 것과 유사하기 때문에 자신의 코드를 테스트해서는 안됩니다. 어느 쪽이든 당신에게 아름답게 보일 것이며, 결함을 지적하려면 전문가가 정말로 필요합니다. 반면에 단위 테스트는 아이가 납으로 페인트하지 않도록하는 것과 유사합니다.

여러분이 정말로 QA를 고용하고 싶지 않다면 개발자가 다른 개발자를 위해 테스트 코드를 작성하도록하십시오. 첫 단계는 좋은 첫 단계입니다. 곧 개발자는 QA 리소스를 요구하는 것을 보게 될 것입니다. 대부분의 시간이 CR 외에도 다른 코드를 테스트하는 데 소비되기 때문입니다.

개발자는 코드를 보호하는 것뿐만 아니라 특정 사례를 인식하지 못하거나 무언가를 개발하는 방식으로 사양을 잘못 해석하면 코드를 테스트 할 때 해당 사례를 놓칠 수 있습니다.

테스트 기술과 기술도 매우 다릅니다.

테스트 팀에 의한 대부분의 테스트는 기능적으로 (제품이 사양에 따라 작동 함) 블랙 박스 (테스트 팀은 애플리케이션의 내부 작동을 보지 못함)입니다. 기능 테스터는 작동 방식에 대해 걱정할 필요가 없으며 작동 여부에만 초점을 맞출 필요가 있습니다.

내 경험으로는 최소한 소규모 조직에서는 최종 사용자가 테스트해야합니다. 우리가 얻는 거의 모든 프로젝트는 필요한 모든 정보를 제공하지 못하며 항상 특정 세부 사항을 생략합니다. 개발자는 사용자 작업을 수행하는 방법을 모르기 때문에 항상 테스트 단점이 있습니다. 따라서 제공된 정보에 따라 소프트웨어가 작동하는 것을 알고 있지만 최종 사용자에게 도움이 될지 여부는 알 수 없습니다. 그들의 일을하십시오.

개발자는 요구 사항을 잘못 읽고 해석하며 요구 사항을 담당하는 개발자는 종종 핵심 사항을 지정하지 않습니다. 개발자를 제외한 다른 사람이 테스트하지 않으면 라이브로 가기 전에 아무도 이러한 연결 끊기를 찾을 수 없습니다. 개발자는 테스트 할 때 작동 방식에 대해 너무 많이 알고 있으며 사용자가 시도하는 어리석은 일을 시도하지 않습니다. 또한 개발자는 요구 사항에 대한 자체 해석을 기반으로 테스트를 작성하기도하는데 실제로는 실제로 의미하는 바가 아닙니다. 따라서 테스트는 통과했지만 요구 사항이 충족되지 않았습니다. 다른 사람의 검사를받을 때, 그 사람은 요구 사항에 대해 다른 아이디어를 가지고있을 수 있으며, 종종 두 명의 다른 사람들이 해석하는 방식에 따라 reuirement가 제대로 표현되지 않은 장소를 발견하게됩니다. 실제로 테스트 한 후 테스트하는 것이 훨씬 좋습니다.

개발자는 우리가 코딩 한 부분이 요구 사항에 따라 작동 할 것으로 예상되는 방식을 알 수 있도록 초기 테스트를 수행해야합니다. 그래서 우리는 우리가 작성한 코드에 대한 단위 테스트를 작성하고 정상 테스트를 수행했습니다.

다음 단계는 코드를 작성할 때 개발자가 볼 수없는 것을 찾는 QA의 작업입니다. 개발자는 더 높은 수준으로 생각하지만 사용자는 같은 수준으로 생각하지 않을 수 있습니다. 개발자가 자신의 작품을 테스트하고 텍스트 상자에 텍스트를 입력해야 할 때 항상 전체 문자열을 입력하여 사용자가 그렇게 할 수 있습니다. 사용자가 할 수도 있지만 텍스트에 % & $ ^와 같은 특수 문자를 입력하면 응용 프로그램이 중단되어 최종 사용자에게 좋지 않은 것처럼 보입니다. 개발자는 그렇게 생각하도록 훈련받지 않았기 때문에 발생할 수있는 모든 가능성에 대해 생각할 수없고 생각하지 않을 것입니다. QA (테스터)에 관해서는 항상 사용자 가이 응용 프로그램을 중단하고 책의 모든 어리석은 일을 시도하기 위해 할 수있는 일을 생각합니다. 사용자는 어리석지 않지만 우연히 남겨두면 안됩니다.

이제 우리는 일반적으로 동시에 둘 이상의 작업이 수행되고 둘 다 생산 될 것임을 이해해야합니다. 개발자는 자신의 작품 만 테스트하고 제대로 작동한다고 생각할 수 있지만 두 가지 다른 조각의 조합이 응용 프로그램을 중단시킬 수 있음을 알기 위해 푸시되는 모든 조각에 대해 전체 회귀 테스트를 수행해야합니다. 잘 보이지 않습니다. 또한 부하 테스트 시나리오와 테스터가 더 잘 알고있는 기타 사항도 고려해야합니다.

마지막으로 UAT (User Acceptance Test)를 거쳐 우리가 한 일이 예상 한 것인지 확인해야합니다. 일반적으로 요구 사항이 BA를 통과하더라도 최종 사람은 모양이 무엇인지 정확히 알지 못하고 예상 한대로 생각하지 않거나 더 좋아 보이게 만들거나 다른 이유로 스크랩을 할 수 있습니다. 그들은 이미 사용 가능한 기능과 함께 가지 않을 것이라고 생각합니다.

위에서 설명했듯이 이것은 매우 중요하며 개발자가 직접 수행 할 수 없으며 응용 프로그램이 제대로 작동하는 데 절대적으로 필요합니다. 경영진은 이것이 보수적 인 접근 방법이라고 말할 수 있지만 더 나은 접근 방법입니다. 위에서 언급 한 내용을 약간 조정할 수는 있지만 전체적으로 피할 수는 없습니다.

위의 의견은 큰 요점을 제기합니다.

이전에 언급되지 않은 추가 사항은 별도의 개별 테스트 코드를 갖는 것이 요구 사항에 대한 추가 검사 및 시스템이 올바르게 구현하는지 여부입니다.

요구 사항과 문서는 완벽하지 않으며, 종종 구현은 개발자가 요구 사항을 해석 한 결과입니다.

별도의 개인이 테스트를 수행하면 테스트 계획을 작성하고 테스트를 실행할 때 요구 사항에 대한 자체 해석도 제공합니다.

테스트 활동이 개발 활동과 독립적으로 수행되고 두 가지 모두의 결과가 "동의"하면 시스템이 정확하고 요구 사항의 원래 의도와 정확히 일치한다는 추가 확인이 제공됩니다.

테스트 할 때 프로그래머에게는 "수량"이라는 레이블이 붙은 텍스트 상자가 표시되고 "1"이 입력됩니다. 숙련 된 프로그래머는 "2"값으로 후속 테스트를 수행합니다.

사용자에게 "수량"이라는 텍스트 상자가 표시되고 "~~ unicorns ROX !!! ~~"를 입력하십시오. 숙련 된 사용자도 "-12 1/2"를 시도합니다.

잘만되면, 테스터는 사용자가 이런 일을 할 때 경험하게 될 것에 대해 프로그래머에게 알리기 위해 어딘가에있을 것입니다.

한 가지 이유는 개발자가 자신의 코드에 너무 가깝기 때문입니다 . 그들은 그것이 기발한 것을 알고, 조금 이상한 행동입니다. 그들은 테스트하는 경향이 주위 가 너무 잘 알고있는 약간의 특이성을. 그들은 그것에 대해 충분히 객관적이지 않습니다. 테스트 팀은 블랙 박스처럼 취급합니다. 그들은 수십 또는 수백 가지 테스트 사례의 매트릭스를 작성하고 코드 적으로 수행 할 작업을보기 위해 체계적으로 실행합니다. 종종 개발 팀이 꿈꾸지 않을 시나리오를 생각해냅니다.

또 다른 이유는 시간입니다. 단계별로 구축 된 대규모 프로젝트의 경우 개발 팀은 1 단계를 구축합니다. 그런 다음 2 단계가 구축되고 1 단계의 결함이 수정되는 동안 테스터가이를 테스트합니다. 이것은 모든 단계에서 진행되므로 테스트중인 단계는 이전 단계입니다.

안타깝게도 내 작업 장소에서 때때로 이렇게하기 때문에 (개발자가 마지막에 나왔기 때문에) 개발자가 테스트를 시작하기 전에 마지막 단계로 개발자가 자신의 작업을 테스트하게하는 이유에 대한 몇 가지 논증을 수집하고 싶습니다. 이 주장은 다른 사람들에게 너무 바빠서 다른 사람이 프로그램의 해당 부분에 익숙해 지도록 시간을 갖지 못하는 대부분의 사람들에게 귀결되었습니다.

테스트는 개발자에게 선택 사항이 아닙니다. 개발자는 자신이 작성한 코드를 테스트해야합니다. 작업이 성공적으로 완료되었다는 것을 어떻게 확신 할 수 있습니까? 어떤 종류의 자동화 테스트 (단위 테스트)를 작성하거나 GUI를 사용하여 명령 줄에서 명령을 호출하여 "내가 원하는 작업을 수행하고 있는지 확인"하는 작업을 수행해야합니다.

그 후에 테스트되는 모든 것은 다른 사람들 (동료, QA 등)에 의한 "전용"추가 테스트입니다. 개발자가 직접 테스트하는 대안은 없습니다. 개발자가 자신이 작성한 코드 / 기능을 테스트 할 필요가 없으며 심지어 소프트웨어를 개발하는 방법에 대해 전혀 이해하지 못한다고 말하는 사람은 누구나 있습니다.

당신이 그것을 좋아하든 아니든 코드에 익숙하지 않은 누군가에 의해 테스트됩니다. 문제는 누군가가 당신의 고객이되기를 원하는지 여부입니다.

좋은 질문입니다. 상황에 따라 테스트 사례 (경우에 따라)가 있으며 소프트웨어는 초보자가 제품의 속도를 높이는 것이 실용적이지 않을 정도로 복잡해 보입니다. 또한 수행 된 테스트는 생산 전 최종 테스트라고합니다.

개발자가 최종 테스트를 수행해도되는 이유

• 다른 테스트 범위가 충분합니다 ... 단위 테스트가 존재하고, 통합 테스트 환경이 존재하며 사용되고, UI 테스트, 탐색 테스트 등이 수행 된 경우 등 최종 테스트는 최종 " 허비하다"
• 전문 SQA / 테스터가 작성한 일련의 테스트 사례가 누군가 (개발자)가 명시 적으로 따라야 할 필요가있다
• 기능 / 제품 / 모듈의 고장 위험은 그렇지 않으면 낮은 수준으로 완화되었습니다 (전문가는 높은 위험 영역을 테스트하고 "신인"은 낮은 위험 테스트)
• 비즈니스 상황의 현실은 잠재적 인 결함이있는 제품을 출시하는 것이 릴리스를 지연시키는 것보다 낫다는 것입니다
• 문제의 개발자는 실제로 자격을 갖춘 테스터이며 정신적으로 역할을 변경할 수 있습니다.
• 변경 사항은 시스템이 오프라인 상태 (고객이 사무실로 가져 와서 제어 버전 ASAP에서 테스트 / 릴리스 할 패치)로 인해 고객 사이트가 종료되거나 매출이 손실 될 때 개발자가 현장에서 수행 한 버그 수정입니다. )

개발자가 테스트를 수행하지 않아야하는 이유

• 다른 것

일반적으로 실제 솔루션을 공격하는 올바른 경로에있는 것 같습니다. SQA 전문가에게 테스트 사례를 생성하도록 요청하십시오.

참고 : 나는 일반적으로 개발자가 테스트를 할 수 있도록 찬성하지만 첫 번째 글 머리 기호가 있는지 확인합니다 ....

인간은 인간이기 때문에인지 바이어스로 고통받는 경향이 있습니다. 거의 동일한 두 시나리오에서 판단이 바뀐 몇 가지 사항 때문에 판단이 다를 수 있습니다. 8 년 동안 개발에서 주목 한 것은 개발자가 동료가 작성한 코드와 달리 자체 코드를 테스트하는 데 어려움을 겪고 있습니다.

이것은 개발자가 직접 잘못했다고 말하는 것이 아닙니다. 두뇌는 자신이 작성한 편견을 사용하여 자신의 권리를 믿는다는 사실을 강화하고 개발자가 아닌 기본 점검 만 수행합니다. 다른 사람의 코드를보고 더 철저한 검사를 수행합니다.

인지 적 편견을 방지하기위한 절차가 마련되었거나 항공 교통 관제에 전산화 된 시스템과 같이 일반적으로 "인적 요소"라고 알려진 수천 개의 예가 있으며, 두 개의 다른 항공기가 동일한 공역을 동시에 차지하는 것을 방지합니다. 한 명 이상의 의사가 진단을 내릴 수 있도록 의료 절차를 시행해야합니다.

이제 IT 산업이보다 전문적인 태도로 나아가고 자체 코드 테스트를 방지하기위한 절차를 마련해야합니다.

• 모두가 테스트해야합니다-개발자 테스트 코드, 품질 관리 테스트 기능, 마케팅 테스트 메시징. 그렇게하면 모든 사람 이 테스트의 절반에 해당 하는 동일한 철학과 언어를 공유하게 됩니다.

• 테스트는 일상적인 유지 관리이며 일반적으로 유추를 사용하여 비교 합니다. 예를 들어, 자동차 오일은 비유를 바꿉니다. 오일을 '변경'해서는 안됩니다. 그러나 당신은 어쨌든 정기적으로합니다. 양치질도 마찬가지입니다. 매일 유지해야하는 이유가 있습니다. '오늘'을 깰 수는 없습니다. 그것은 내일과 미래의 일과 투자에 관한 것입니다.

• 모든 사람은 테스트 책임 을 분담 해야합니다 . QA 팀은 중요하지만 "테스트"를 QA 팀만이하는 것으로 만드는 것은 좋은 일이 아닌 제품 개발 및 워크 플로에 통합되지 않은 '별도의'활동으로 만듭니다.

• 프로덕션 환경에서 문제가 발생하면 두 가지 작업을 수행하십시오.

  1. "음, 우리는 첫 번째 주석으로 그에 대한 테스트를 받았습니까?"라고 말합니다 .
  2. 수정 사항 보다 먼저 수정 해야 할 문제에 대한 테스트가 수정 사항에 포함 되도록하십시오.

우리 회사에서는 매우 복잡한 재무 응용 프로그램을 구축합니다. 일반적인 정책은 개발자가 기술적 오류가 발생하지 않도록해야한다는 것입니다. 기본적으로 사용자의 리소스가 주어지면 그것을 깨기 위해 가능한 모든 것을 시도하십시오. 런타임 오류를 찾을 수 없으면 테스트를 위해 BA로 전달하십시오. 우리는 소멸 시점까지 비즈니스 요구 사항을 테스트하는 데 실패한 개발자가 몇 명 있었지만 모든 테스트가 자신의 책임이 아니기 때문입니다. 눈에 띄는 눈에 띄는 오류가 없으면 출력을 이해하기 위해 돈을받는 사람들에게 전달합니다. 또한 사용자는 결과를 확인하는 데 실질적인 역할을 수행해야합니다. 소매점의 영업 직원은 당신을 위해 옷을 입히지 않고 올바른 크기의 옷을 찾는 것과 같은 "기술적 인 세부 사항"만 도와줍니다.

한 가지 문제는 개발자가 자신의 코드를 깨뜨릴 인센티브가 거의 없다는 것입니다. 자신의 작품에서 결함을 기꺼이 검색하거나 실수를 저 지르려는 사람은 거의 없습니다. 별도의 팀이 있으면 문제가 해결 될 수 있습니다.

누군가가 개발자가 요구 사항을 이해했는지 확인할 수 있도록 품질 보증 역할이 필수적입니다. 개발자가 오해가 있다고 생각되면 설명을 요구하기 때문에 개발자는 스스로 확인할 수 없습니다.