테스터가 찾을 수 있도록 의도적 인 버그를 코드에 남김

우리 회사에서는이 작업을 수행하지 않지만 내 친구 중 한 사람은 프로젝트 관리자가 제품이 QA에 들어가기 직전에 모든 개발자에게 의도적 인 버그를 추가하도록 요청했다고 말합니다. 이것이 작동하는 방식입니다.

1. 제품이 QA에 들어가기 직전에 개발 팀은 코드의 임의 위치에 의도적 인 버그를 추가합니다. 그들은 원래의 작동 코드를 올바르게 백업하여 해당 버그가 최종 제품과 함께 제공되지 않도록합니다.
2. 테스터들도 이에 대해 알려줍니다. 그래서 그들은 버그가 존재한다는 것을 알지 못해서이를 무능력의 표시로 간주 할 수 있기 때문에 열심히 테스트 할 것입니다.
3. 의도적이든 아니든 버그가 발견되면 개발 팀에서 수정 한 것으로보고됩니다. 그런 다음 개발 팀은 제품이 2 단계 품질 관리로 넘어 가기 직전에 코드의 관련 섹션에 또 다른 의도적 인 버그를 추가합니다. 프로젝트 관리자는 테스터가 개발자처럼 생각해야하며 변경 한 부분에서 새로운 버그를 예상해야한다고 말합니다.

글쎄, 이것이 어떻게 진행되는지입니다. 그들은이 접근법이 다음과 같은 장점이 있다고 말합니다.

1. 테스터는 항상 발끝을 잡고 미친 듯이 테스트합니다. 이를 통해 개발자는 의도하지 않은 숨겨진 버그를 찾아 개발자가 수정할 수 있습니다.
2. 테스터는 버그를 먹습니다. 버그를 찾지 못하면 사기에 영향을 미칩니다. 따라서 그들이 쉽게 찾을 수 있도록하면 사기에 도움이 될 것입니다.

이러한 의도적 인 버그 중 하나가 최종 제품과 함께 제공되는 시나리오를 무시하면이 방법을 채택하기 전에 고려해야 할 다른 단점은 무엇입니까?

몇 가지 설명 :

1. 소스 제어에서 원래 코드를 올바르게 백업합니다.
2. 테스터가 의도적 인 버그를 발견하면 개발 팀은이를 무시합니다. 테스터가 의도하지 않은 (원래) 버그를 발견하면 개발 팀은 먼저 의도적 인 버그로 인한 것인지 확인합니다. 즉, 개발 팀은 먼저 원래 작업 코드에서이를 재현하려고 시도하고 가능한 경우이를 수정하려고합니다.
3. QA와 개발 팀 간의 관계 문제는 무시하십시오. 나는 특히 Workplace가 아닌 Programmers 에게이 질문을했다 . QA와 개발 팀 사이에는 좋은 관계가 있으며 근무 시간 후에 함께 파티를 시작합니다. 프로젝트 관리자는 항상 두 팀 (Godsend)을 모두 지원할 준비가되어있는 훌륭한 노인입니다.

이것은 절대적으로 너트 소리입니다. 그것은 매우 의심스러운 이익을 얻기 위해 많은 노력을 기울이고 있으며, 그 관행은 잘못된 건물을 기반으로합니다.

• QA는 매일 테스트를 받고 있다는 사실을 알지 못하면 열심히 일하지 않습니다 (도덕에 적합하지 않음)

• 품질 관리팀이 찾을 수있는 실수로 소프트웨어에 의도 치 않게 도입 된 버그가 충분하지 않음

• QA의 임무는 버그를 찾는 것입니다. 소프트웨어가 생산 품질인지 확인하는 것입니다.

• 개발과 QA 사이의 이런 종류의 재치 싸움은 어떤면에서는 회사에게 건전하다는 것입니다. 모든 직원은 서로 경쟁하는 대신 회사 경쟁 업체와 협력해야합니다.

그것은 끔찍한 아이디어이며 문제의 프로젝트 관리자는 사람과 동기에 대해 전혀 이해하지 못하는 바보 / 바보입니다. 그리고 그것은 사업에 좋지 않습니다.

"QA 's job"에 대한 설명을 확장하려면 QA는 코드와 테스트 스위트 모두에서 작업을 수행하는 결과물로 버그를 찾아야하지만 역할을 "찾을 필요가 없다"고 정의해서는 안됩니다. 버그. " "새로운 기능을 설명하고 높은 테스트 범위를 보장하려면 테스트 스위트를 최신 상태로 유지해야합니다. 버그가 발견되지 않으면 테스트 절차가 제품에 대해 충분히 정교하지 않습니다.

글쎄, 내가 배운 것을 바탕으로 :

1. 학교 나 면접이 아닙니다.
2. 테스터는 어린이가 아닙니다.
3. 게임이 아닙니다.
4. 회사의 돈을 낭비합니다.

QA는 버그 를 찾을 뿐만 아니라 시스템이 얼마나 직관적 인지 , 사용자를위한 학습 곡선 , 사용성 및 접근성 에 대해 걱정 해야합니다 . 예를 들면 : "시스템이 못 생겼 습니까?", "사용자 색맹이고 물건이 빨간색과 초록색입니까?" 그들도 불평해야합니다.

QA를 통과하기위한 시스템의 최소 요구 사항은 일반적으로 해당 특정 기능에 대한 사용자 스토리 또는 PO가 시스템을 그의 머리에두고 싶어하는 마법에 설명되어 있습니다.

tl; dr

버그 일뿐만 아니라 테스터는이 좁은 시야에서 벗어나야합니다.

나쁜 생각.

테스터의 관점에서 : "따라서 버그가 존재한다는 것을 알지 못하고 버그를 발견하지 못하면 무능하다고 간주 될 수 있기 때문에 열심히 테스트합니다." 기본적으로 개발자는 코드를 booby-trapping합니다. 벌레가 미리 알려져 있기 때문에 궁극적으로 무의미하지만 여전히 인식되는 방식에 영향을 미치는 일을하는 사람들은 거의 없습니다. 부비 트랩을 찾지 못한 것에 대한 실질적인 형벌이 있다면 더 그렇습니다. 테스터가 버그를 찾는 데 성공했다는 것을 알고 있습니까? 그것은 유독 한 대립 환경처럼 들린다; QA는 검사하는 코드의 품질이 좋으면 만족해야합니다. 그들이 버그에 의해 지불된다면 ... http://thedailywtf.com/articles/The-Defect-Black-Market

개발자의 관점에서 : QA는 사용자가 알고있는 버그를 찾기 위해 인센티브를 받고 있습니다. 그것은 실제 버그가 문 밖으로 나올 가능성을 증가시킬 수 있습니다 . 품질 보증팀은 최소한 미묘한 버그가 아니라 심기 쉬운 버그를 찾기 위해 시간을 투자하고 있습니다. 또한 booby-trap이 문에서 빠져 나올 가능성이 적습니다.

나는 이것이 왜 동기 부여에 좋지 않으며 일반적으로 끔찍한 사람들 관리에 관한 위의 답변에 전적으로 동의합니다. 그러나이 작업을 수행하지 않는 확실한 기술적 이유가있을 수 있습니다.

제품이 QA에 들어가기 직전에 개발자 팀은 코드의 임의 위치에 의도적 인 버그를 추가합니다. 그들은 원래의 작동 코드를 올바르게 백업하여 해당 버그가 최종 제품과 함께 제공되지 않도록합니다.

1. 첫 번째 진술 에 따르면 실제로이 두 단계에서 의도 한 생산 코드를 테스트 하지는 않습니다 .

2. 고객의 변경을 돌파하려고 할 때 실수로 릴리스 된 생산 코드에 '의도적'버그를 포함시킬 가능성이 크게 증가했다고 생각합니다. 어느 시점에서 약간의 뺨이 생길 수 있습니다.

3. 나는 이것이 테스터에게 개발자처럼 생각하도록 (즉, Tom이 어떻게 버그를 추가 할 것인지) 훈련을 시켜서 Tom이 생각하지 않은 버그를 찾을 가능성이 낮아질 것이라고 생각합니다.

편집하다

이 답변은 QA 프로세스 테스트 개념에 대해서만 이야기하고 있으며 질문에 표시된 특정 방법론을 변호하지는 않습니다.

편집 종료

테스트 / 검사가 실제로 작동하는지 확인해야 할 정당한 이유가 있습니다. 제조의 모범을 보여 드리지만 원리는 같습니다.

기계를 통해 재료를 공급할 때 피더가 재료를 충분히 밀어 넣지 못할 수 있습니다. 이것을 "짧은 피드"라고하며이를 방지하기 위해 "짧은 피드 센서"(일반적으로 재료에 의해 차단되는 투과형 센서)를 설치할 수 있습니다. 이 센서는 전체 공급 길이에 도달 할 때 재료의 끝을 감지합니다. 기계 사이클의 특정 시점에서 센서가 막혔는지 확인하고 검사에 실패하면 기계를 정지시킵니다.

이제 테스트 자체가 어떻게 실패 할 수 있는지 생각해야합니다. 예를 들어, 먼지 나 이물질이 있으면 센서를 막을 수 있으며 항상 "OK"라고보고하고 기계를 멈추지 않습니다. 또한 센서의 특성상 빔이 빔에 부딪히면 수신기가 켜지므로 설치 한 센서 유형에 따라 센서가 차단되지 않은 경우 전기적으로 "ON"입력을받습니다 . 즉, 케이블이 끊어 지거나 해당 센서의 전원이 끊어 지거나 입력이 실패한 경우 프로그램 논리에 "OFF"가 표시되고 "차단됨"또는 "확인"이됩니다.

이러한 테스트 실패 모드를 파악하기 위해 일반적으로 두 번째 검사를 삽입 하여 사이클의 두 번째 부분 동안 센서가 실제로 차단되지 않았는지 확인합니다 . 이런 식으로 테스트가 실제로 작동하는지 확인합니다 (가능한 한 최선).

마찬가지로 QA 부서가 실패 할 수있는 여러 가지 방법이 있습니다. 자동화 된 테스트가 실행되지 않았고 보고서가 테스트 데이터의 오래된 사본을보고있는 것 같습니다. 아마도 누군가 자신의 일을 제대로하고 있지 않을 것입니다. 품질 관리 부서 테스트는 합리적입니다.

분명한 단점은 "테스트 버그"가 QA 부서를 통해 완성 된 제품으로 만들 수 있다는 것입니다. 제조업에는 때때로 "빨간색 토끼"라고하는 알려진 불량 부품이 공정에 삽입되고 (일반적으로 QA 담당자가) 부품이 공정을 통과하고 소요되는 시간을 측정하는 경우가 있습니다. 부품을 찾아서 제거하십시오. 일반적으로이 부분은 밝은 빨간색 (또는 주황색)으로 칠해져 쉽게 추적 할 수 있습니다. 누군가가이 테스트 과정에서 부품이 공정을 거치는 것을보고 있기 때문에 최종 제품으로 부품을 만들 가능성은 거의 없습니다. 물론 "시스템이 그것을 찾을 수 있는지 확인하기"위해 프로세스에 알려진 나쁜 부분을 던지는 사람에 대한 외설적 인 이야기가 있습니다.

솔직히 저는이 행동을 비 윤리적이고 비현실적이라고 부릅니다. PM은 종료가 아닌 경우 심각한 재교육이 필요합니다.

• 그것은 품질 보증의 개념에 대한 이해가 근본적으로 부족하다는 것을 보여준다 . 테스터는 개발자처럼 생각해서는 안됩니다. 최종 사용자처럼 생각해야합니다. QA 팀이있는 이유는 개발자가 본질적으로 코드에 너무 가깝기 때문입니다. QA는 개발자가 놓친 것을 포착 할 수 있도록 코드에서 충분한 거리를 유지해야합니다.
• QA 노력을 낭비 합니다. 이러한 버그가 사소한 것이 아니라고 가정하면 (아래의 버그가있는 경우 참조) QA는 이미 알려진 것을 조사하는 데 시간과 리소스를 소비하고, 알려지지 않은 것을 찾는 노력을 기울일 수 있음을 의미합니다.
• 개발자의 노력을 낭비 합니다. QA 담당자가 사소한 버그를 잡으려면 개발자가 먼저 버그를 작성해야합니다. 이를 위해서는 버그를 코딩 할뿐만 아니라 소프트웨어 요구 사항 및 디자인도 고려하면서 추가 노력이 필요합니다.
• 생산이 불필요하게 위험에 처하게 됩니다. 변경 사항이 제대로 병합되지 않는 것은 시간 문제입니다.
• 위의 작업을 수행하지 않으면 의미가 없습니다 . 알려진 모든 버그가 사소한 경우, 표준 이하의 직원을 잡을 수는 없습니다. 그들은 전혀 일을하지 않는 사람 만 잡을 것입니다. 더 좋은 방법이 있습니다.
• 그것은 작업 환경을 독살시킵니다 . QA 테스터는 전문가입니다. 그들은 신뢰해야 할 그렇지 않으면 의심 할 실제 이유가 될 때까지 전문. 이 때 이다 , 그렇지 않으면 의심 할 이유는, 대신에이 마음이 게임의 적절한 조사가 있어야한다. 다른 것은 사기를 죽입니다.

진심으로. PM의 편집증이이 특정 사례에서 잘 정립 된 것으로 밝혀 지더라도 이는 비즈니스 관리 테스터를 보유한 사람이 아닙니다.

개인적으로, 나는이 접근법에 불편 함을 느낍니다.

나에게 중요한 것은 의도적 인 버그 를 삽입하는 실용성입니다 . 이것은 예측 가능한 방식으로 수행하기 어려워 보입니다.

모든 (그렇지 않으면 고의 또는) 코드 변경 위험이 가진 부작용. 이러한 부작용은 테스트하는 동안 잘 드러날 수 있지만 근본 원인이 무엇인지 명확하지 않을 수 있습니다 (버그를 심은 개발자에게조차도). 내가 무슨 뜻인지 알면 "안전하다"고 느끼지 않습니다 (여기서 장에서 말하고 있습니다).

또한 테스터는 실제로 릴리스되지 않는 많은 테스트 코드를 낭비합니다. 일단 의도적 인 버그가 제거되면 어쨌든 완전한 재검사가 이루어져야합니다. 이것이 전체 테스트 포인트입니다. 뭔가, 변경 아무것도 , 당신은 테스트 다시 모든 것을 . 좋습니다. 실제로 그런 일은 일어나지 않지만 회귀 테스트의 핵심입니다.

따라서 전반적으로 확신하지 못했습니다.

반면 고객은 품질 보증팀의 작업을 고객이 확인하도록하는 경향이 있습니다. 그것은이다 매우 불구하고 강력한 피드백 루프.

이미 주어진 모든 이유로 나쁜 생각이지만 버그 시드는 다른 목적에 유용한 도구입니다. 이를 사용하여 QA 프로세스가 얼마나 효과적인지 대략적인 지표를 얻을 수 있습니다.

가장 간단한 경우, 100 개의 버그를 시드하고 실제 버그의 전체 범위를 대표한다고 가정 해 보겠습니다 (아마도 그럴 수는 없지만 단순화하고 있습니다). 실험을 망치지 않기 위해이 작업을하고 있다고 품질 보증팀에 알리지 않습니다 . QA 프로세스가 끝나면 100 개의 시드 버그 (및 기타 실제 버그) 중 60 개가 발견되었다고 가정하겠습니다. 이제 QA가 버그의 60 %를 발견하고 있음을 알았습니다.

QA에서 찾은 실제 버그 수를 세고 가짜 버그 비율을 적용하여 이를 더욱 확장 할 수 있습니다 . 이 예에서 QA가 200 개의 실제 버그를 발견 한 경우 60 % 만 발견했다고 결론을 내릴 수 있으므로 133 개가 남아 있습니다.

물론 이것은 막대한 오차 막대가있는 광범위한 추정치입니다. 사실적이고 대표적인 버그를 작성하는 것은 어렵습니다. 개발자가 버그를 작성하지 않도록 교육 받았으므로 QA에서 작성하는 버그가 더 쉬울 것 입니다. 일대일 오류, 유니 코드 실수, 버퍼 오버 플로우 등과 같은 버그 클래스를 시뮬레이션하는 것이 좋습니다.

이는 개발자 단위 테스트, 지속적인 통합 및 가능한 경우 전담 QA 팀을 포함 하는 전체 QA 프로세스에 적용되어야합니다 .

이는 측정 항목 이며 관리 동기 부여 도구로 납치되어서는 안됩니다.

나쁜 생각.

이것은 개발자가 종종 가져 오는 일종의 논리적 이진 접근법이지만 QE를 위해 동기를 부여하고 있습니다. 그것은 단지 신뢰의 부족을 보여줍니다. QE는 종종 이러한 상황에서 많은 의견을 듣지 않고 배치되며, 문제가없는 것으로 가정하고 달리 제안 할 장소가 아닙니다.

이러한 종류의 사고는 QE가 수동 테스터 일 뿐이며 테스트중인 실제 코드를 이해하려는 동기가되지 않습니다.

나는 선임 QE이며 이것은 내가 일한 대부분의 조직에서 익숙한 문제입니다.

나는 나쁜 생각을 할 것입니다.

하나 : 프로그래머는 코드에 고의적 인 버그를 넣는 데 시간을 보내고 좋은 버전을 저장하기 위해 노력할 것입니다. 테스터는 심은 버그가있는 기능을 포함하여 모든 것을 테스트해야 할 것으로 예상되지만, 버그를 발견 한 경우 실제로 버그가 아닌지 확인하기 위해 해당 테스트를 다시 실행해야합니다 (테스터가 혼동하지 않음) 어떤 식 으로든). 최소한 테스터는 심은 버그를 작성하는 데 시간을 할애합니다. 그런 다음 프로그래머는 심은 버그를 수정하는 데 시간을 소비해야합니다. 좋은 코드를 작성하고 실제 버그를 작성하는 데 많은 노력이 필요합니다.

둘째 : 프로그래머 및 / 또는 경영진이 자신의 업무를 수행하지 않는다고 생각하고 자녀로 취급해야한다는 명확한 메시지를 테스터에게 보냅니다. 나는 이것이 사기에 좋다고 상상할 수 없다. 프로그래머로서, 프로그램에 대해 모호하거나 모순 된 사양을 부여 받고이를 명확하게하기 위해 많은 시간을 소비해야한다면 몇 시간 또는 며칠을 낭비한 후 상사가 나에게 "오, 그래, 의도적으로 모순적인 진술을했다고한다. 스펙은 당신이 정말로 그것들을 읽고 있는지 확인하기 위해서 "라고 생각합니다. 그것이 정기적으로 일어났다면, 다른 직업을 찾도록 충분할 것입니다.

실제로 가장 사소한 코드 변경을 제외한 모든 버그에는 버그가 있습니다. 처음에 작성된 초안 코드가 너무 자주 100 % 완벽했기 때문에 테스터가 만족스러워하는 데 아무런 문제가 없었습니다. 나는 적절한 일을하지 않는 게으른 테스터들을 다루어야했지만 프로그래머들이 그렇게 완벽했기 때문에 그들은 그렇게하지 못했습니다. 한 번도 함께 일한 최고의 테스트 담당자는 새로운 소프트웨어 릴리스의 경우 100 가지 버그를 찾기위한 개인적인 목표를 설정했다고 말했습니다. 100이 현실적인 수인지 여부는 제품의 크기와 변경의 정도에 따라 다르지만 우리의 경우 거의 항상 그 목표를 달성했습니다. 때때로 그는 메시지에서 철자가 틀린 단어를 "버그"라고 부르는 것과 같이 일을 늘려야했지만, 고쳐야했습니다.

Post script :이 작업을하면 프로그래머가 의도적으로 버그를 심고 테스터는 해당 버그를 찾지 못하며 프로그래머는 좋은 코드를 다시 넣는 것을 잊어 버릴 것입니다. 이제 의도적으로 심은 버그가 고객에게 배송됩니다.

나는 이것이 나쁜 생각 이라고 생각하지 않습니다 . 내가 더 잘 작동한다고 생각하는 많은 것들이 있습니다.

1. 품질에 대한 책임은 품질 관리에 있습니다. 예를 들어 그들의 책임을지지함으로써. 이는 선적 된 제품의 품질을 높이기위한 동기를 증가시킵니다. 부적절한 사용자 (버그, 명백히 누락 된 기능, 반 직관적 인 동작)를 발견 한 다음 화가 난 사용자가 무엇을 설명하려고하는지 이해하는 데 항상 노력이 덜 걸립니다. 또한 개발자에게 책임을 맡기면 QA가 최선을 다해 일을 수행하도록 동기를 부여 할 수 있습니다.

2. 경쟁 할 수있는 여러 QA 팀이 있습니다. 물론 합리적인 측정 기준을 찾아야합니다. 문제의 수가 아닙니다. 제안 된 개선 사항의 결함 심각도 또는 비즈니스 가치 (이해 관계자가 결정한)를 고려하면 도움이됩니다.

품질 보증이 '충분한 지'여부를 판단하기는 어렵습니다. QA가 "항상 개선"될 수있는 방법을 찾는 것이 장기적으로 더 쉽고 더 좋습니다.

그래도 의도적 인 버그가 발생했을 경우 알아야 할 한 가지 문제가 있습니다 . "올바른"코드가 실제로 처음에 올바른지 어떻게 알 수 있습니까? 2 차 품질 보증 후 발견되지 않은 모든 의도적 인 버그를 제거합니다. 다른 방식으로 손상된 코드로 코드를 교체하는 것이 아니라 이전에 도달 할 수 없었던 깨진 동작을 활성화하지 않았다는 것을 알 수있는 방법이 없습니다 (과장된 예 : 의도적 인 버그로 인해 일부 대화 상자가 열리지 않음, 그러나 대화 상자 자체가 손상되었습니다-테스터가 그것을 보지 못했기 때문에 알 수 없습니다).

다른 사람들이 말했듯이 개발자는 의도적으로 소프트웨어에 버그를 추가해서는 안되지만 테스트 스위트 가 테스트 프로세스의 일부로 소프트웨어에 버그를 추가 하는 것이 합법적 인 전략 입니다 .

이를 돌연변이 테스트 라고 합니다. 아이디어는 소프트웨어를 사용하여 소스 코드의 작은 변경 사항 (돌연변이) 생성을 자동화하는 것입니다. 변경 사항은 다른 동작을 작성하도록 설계되었습니다. 예를 들어 변경 사항은

if x < 10:
    print "X is small!"

으로

# we flipped the inequality operator
if x > 10:
    print "X is small!"

그리고 좋은 단위 테스트는 돌연변이 코드 조각이 더 이상 예상대로 작동하지 않고 돌연변이를 죽인다는 것을 감지해야합니다 . 원래 코드가 테스트를 통과하고 기능적으로 동일하지 않은 모든 돌연변이 체가 테스트에 실패하면 코드와 테스트가 강력 하다는 것을 알 수 있습니다 .

나는 그 아이디어를 좋아한다. 패튼 장군은 "평화 속에서 땀을 많이 흘릴수록 피가 적게 나옵니다"라고 말한 적이 있습니까?

테스터의 의도적 인 버그를 "시간 낭비"하는 것. 그러나 그것은 또한 그들이 더 열심히 일하게함으로써 의도하지 않은 버그를 발견하는 더 나은 일을 할 것이라는 것을 의미합니다. (그리고 당신은 "원본"의 사본을 가지고 있으므로 당신이 한 일을 살 필요가 없습니다.)

의도하지 않은 버그를 더 많이 찾으면 의도적 인 버그를 처리하는 데 드는 비용보다 장기적으로 더 많은 슬픔을 줄일 수 있습니다.

또한 테스터 자체의 장점이 아니라 테스터의 성능에 대한 아이디어를 얻을 수 있습니다.

자체 가치에 대한 보상이나 처벌의 근거는 없지만 목표로하는 행동의 결과에 근거합니다. 때로는 의도하지 않은 결과가 발생하기도합니다. 품질 보증팀이 느슨해지지 않도록하거나 목표를 달성하지 못한 채 일부 관리자가 실제로 무언가를 제공하는 것처럼 느끼게하는 것이 목표입니다.

긍정적 결과-QA 팀은 버그를 찾기 위해 더 열심히 노력합니다. 누가 알겠는가? 친근한 게임입니다. 아니면 그들이보고 있기 때문에 그냥하고있는 것입니다 (호손 효과?).

부정적인 결과-그들은 더 열심히 일하지 않고 어쨌든 버그를 찾을 수 있습니다. 품질 관리팀에서는이를 사소하고 악의적 인 것으로 간주합니다. 그래서, 그들은 하이퍼 버그 찾기 드라이브에 들어가서 온갖 종류의 작은 까다로운 작은 문제를 반환합니다. 스크린 샷을 찍어 PDF로 변환하여 500 %에서 볼 때 해당 글꼴이 제대로 렌더링되지 않습니다.

영향 없음-이와 같은 소리는 차이가 없습니다. 왜 귀찮게합니까? 당신은 시간을 낭비하고 사람들을 짜증나게 할 위험이 있습니다.

우리는 이것이 90 %의 시간 동안 작동하지 않을 것이라는 데 모두 동의 할 수있었습니다. 다른 10 %에게는 그다지 좋지 않습니다. 스스로 테스트하십시오. 의도적 인 코드 버그가있는 릴리스에 대해 고객이 더 만족합니까? 다른 분야의 근로자 사기와 생산성에 영향을 미칩니 까? 매출 증가? 당신은 우리에게 말해.

개발자가 직접 테스트를 작성하고 실행할 것으로 예상되는 세계에서 온이 "테스트" "QA"사일로는 나를 두려워하고 혼란스럽게하므로이 관점에서 대답하려고합니다. 저의 관점에서 볼 때 (@SparK의 답변에 잘 설명되어있는) 자격을 갖춘 QA 엔지니어는 소프트웨어가 사용자 스토리를 완전히 만족시키고 전반적인 "품질"을 갖도록하는 더 큰 문제에 초점을 두어야합니다. 버그를 찾는 대신 소프트웨어가 사용되는 도메인).

여기에 나를 끌어 들인 것은 질문에 대한 의견에서 @JamesMcleod의 "결함 주입"에 대한 언급입니다. 실제로 개발자에게 시스템에 버그를 주입 할 수있는 방법을 생각하게하는 것은 심층 방어 개념을 대상으로하는 좋은 아이디어라고 생각합니다. 전체 시스템을 통제 할 수없는 방식으로 (작업 가능한 로깅없이) 중단하거나, 데이터 손상을 일으키거나, 보안 취약점을 노출시키기에 단일 버그로는 충분하지 않아야합니다.

각 구성 요소의 개발자가 의도적 인 결함을 만들고 다른 구성 요소의 결함을 처리하고 전체적으로 소프트웨어에 대한 더 적대적인 사고 방식을 도입하면 소프트웨어의 견고성을 향상시키는 데 많은 도움이 될 수 있습니다. 즉각적인 이점조차 중요 할 수 있습니다-나는 새로운 종류의 결함을 주입 할 때마다 (지금까지 테스트되지 않은) 개발자는 즉시 새로운 테스트로 그것을 커버해야합니다. 버그를 잠시 동안 코드베이스에 그대로 둔 다음 전달하기 전에 스위치를 켜고 결함을 제거하여 테스트 스위트를보다 포괄적으로 만드는 정기적 인 테스트로 만듭니다.

관련 옵션은 기능 구성 요소를 사용하여 특정 구성 요소의 기능을 의도적으로 해제하여 다른 구성 요소가이를 처리하는 방법을 검사하는 것입니다. 또한 2012 년 선거에 Obama 팀이 사용할 소프트웨어 인프라에 대한 광범위한 테스트를 설명 하는 무료 서적 / 문서 "최초의 응답자로부터 배우기 : 시스템이 작동해야 할 때"를 읽어 보시기 바랍니다 .

다른 사람들이 이미 말했듯이 버그를 찾는 것은 QA의 일이 아닙니다. 나는 더 나아가 기술적으로 그들의 일이 아니라고 말합니다. 개발자는 자체 코드를 버그없이 유지해야합니다. 테스트 코드는 새로운 코드가 커밋되기 전에 실행되어야하며 테스트 스위트가 실패하면 처음부터 QA로 진행해서는 안됩니다. 의도적으로 버그를 도입한다는 것은 테스트 스위트를 통과 할 수 없다는 것을 의미합니다. 왜 코드가 QA로 진행됩니까?

QA의 임무는 구현하는 사용자 스토리와 비교하여 애플리케이션을 검증하는 것입니다. 흐름, UI 등을 테스트하고 사용자가 최대한 유용하고 액세스 가능한 방식으로 사용자가 할 수있는 모든 작업을 수행 할 수 있는지 확인해야합니다. 물론이 작업을 수행하는 동안 버그에 걸려 넘어 질 수 있지만 이는 수행하는 작업이 아니라 수행하는 작업의 부작용입니다. QA는 버그없는 보증이 아니라 품질 보증을 의미합니다.

이것이 소리처럼 반드시 미친 것은 아닙니다. 오히려 당신의 동기에 달려 있습니다. 당신이 당신의 테스트 팀을 이길 수있는 스틱을 찾는 경우에, 잘 그 것이다 미친. 반면, 소프트웨어 개발에서 가장 어려운 것은 테스트 방식이 얼마나 효과적인지 아는 것입니다.

따라서 올바르게 구성하면이 기술을 사용하여 배송하려는 제품에 발견 된 버그 수를 추정 할 수 있습니다. 테스트 빌드에 100 개의 버그를 인위적으로 심었고 테스터가 50 개의 버그를 발견했다고 가정 해보십시오. 그러면 50 개의 시드되지 않은 버그가 발견되면 찾을 수있는 50 개가있을 가능성이 있다는 것을 알 수 있습니다.

물론 이것은 많은 문제로 가득 차 있습니다. 이러한 통계를 기반으로 배송 여부를 결정할 수 있지만 실제 상황에서는 매우 불쾌한 문제 또는 수천 가지의 작은 자극이있을 수 있습니다.

여전히 지식은 강력하며이 기술이 없으면 코드 기반의 품질에 대한 아이디어가 훨씬 적습니다. 정중하고 올바른 이유로이를 구현할 수 있다면 "왜 안됩니까?"라고 말하고 싶습니다.

아직 아무도 언급하지 않은 것 중 하나는 돌연변이 테스트 입니다.

자동화 된 툴이 소스 코드를 가져와 의도적으로 버그를 삽입하는 곳입니다. (예를 들어, 무작위로 선택된 명령문을 삭제하고 AND를 OR 등으로 변경하십시오.) 그런 다음 전체 테스트 스위트를 실행하고 테스트 통과 여부를 확인합니다.

모든 테스트가 통과되면 두 가지 가능성이 있습니다.

• 변경된 것은 아무것도하지 않습니다. 다시 말해, 죽은 코드가 있습니다.
• 이 변경으로 인해 테스트 스위트가 포착하지 못하는 버그가 발생했습니다. 더 많은 테스트가 필요합니다.

제안과 달리 위에서 설명한 모든 내용은 자동화되어 있습니다. 무의미한 버그를 수동으로 삽입하는 개발자의 시간을 낭비하지 않습니다. 그리고 당신은 알려진 버그를 찾는 테스터의 시간을 낭비하지 않습니다. 당신이 사용하는 유일한 것은 기계 시간입니다. 이는 훨씬 저렴합니다. (기계는 20,000 번 같은 테스트를하는 것에 지루하지 않습니다. 인간은 잠시 후에 배려를 멈 춥니 다!)

자동화 된 돌연변이 테스트는 당신이 이야기하는 수동 시나리오보다 훨씬 더 나은 방법이라고 제안합니다.

개발자에게 수동으로 버그를 삽입하도록 요청하는 경우 발생하는 버그의 종류는 사람이 실수 로 저지르는 실수를 나타내지 않을 수 있습니다. (예를 들어, 경쟁 조건이 있음을 인식하지 못한 경우 의도적 인 도구를 삽입 할 가능성이 없습니다.) 자동화 된 도구가 더 객관적으로 관리 될 수 있는지 여부는 여전히 남아 있습니다.

일반적으로 나쁜 생각이지만 (다른 답변은 이유를 완벽하게 설명하지만) 의도적으로 생산 코드에 버그를 통제 된 임시 방식으로 주입하는 것이 합리적 일 수있는 특별한 상황이 있습니다.

테스트 코드를 리팩터링 할 때 테스트 코드는 프로덕션 코드와 동일한 세부 사항에주의를 기울여야합니다. 테스트 코드가 여전히 발견해야하는 버그를 찾는 지 알고 싶을 것입니다.

그런 다음 테스트가 여전히 작동하는지 확인하기 위해 의도적으로 생산 코드를 중단 할 수 있습니다.

이것이 가능한 여러 레벨이 있습니다 :

• 일부 단위 테스트를 리팩터링 한 개발자는 프로덕션 코드를 중단하여 단위 테스트에서 여전히 찾은 내용을 찾는 지 확인할 수 있습니다.
• 일부 승인 테스트를 리팩터링 한 테스터는 프로덕션 코드를 위반하여 승인 테스트에서 여전히 검증 대상을 검증하는지 확인할 수 있습니다.
• 인터페이스가 안정적이고 견고하면 (즉, 프로토콜 기반) 회사는 알려진 결함 제품 버전을 유지하고 테스트를 회귀 테스트하기 위해 테스트를 실행할 수 있습니다.

이러한 것들이 의미가 있는지 여부는 다릅니다. 내가 개발자이고 버그를 주입하는 데 1 분이 걸리면 단위 테스트를 테스트하고 버그를 제거하십시오. 그러나 실수로 버그를 커밋 / 전달 / 체크인 / 푸시하지 않는 훌륭한 제어하에 편집자, 사이클 및 버전 제어 시스템이 있어야합니다. 테스터와 수용 테스트도 마찬가지입니다.

조직에서 알려진 결함있는 제품 버전과 회귀 테스트를 유지하는 것이 합리적인지 여부는 테스트에 달려 있습니다. 온라인 상점에서는 그렇지 않습니다. 자동차 임베디드, 항공 우주 임베디드, 은행 카드 또는 유료 TV 카드의 경우.

얼마나 많은 노력이 필요한지는 테스트가 프로덕션 코드에서 분리 된 정도에 달려 있습니다. 테스트가 프로덕션 코드에서 더 많이 분리 될수록 더 적은 노력을 기울일수록 테스트가 프로덕션 코드와 더 응집력이 높을수록 더 많은 노력을 기울입니다.

테스트와 프로덕션 코드가 응집력이있는 경우 프로덕션 코드를 변경하면 테스트를 자주 변경해야하므로 테스트와 잘못된 프로덕션 샘플 간의 종속성이 손상 될 수 있습니다. 그런 다음 결함있는 생산 샘플도 유지해야합니다. 드문 경우지만 그 노력의 가치가있을 수 있으며, 버전 제어 시스템을 현명하게 사용하는 것뿐만 아니라 조롱하면 노력을 크게 줄일 수 있지만 숙련 된 개발자는 훨씬 더 많이 필요합니다.

제품 코드 의도적 주입 결함의 개념이라고 파괴 분사 고장이 호출되며, 사보타주 .

리포지토리에서 코드를 직접 테스트하지 않는 테스터가 잘못하고 있습니다. (1)

알려진 결함 코드 를 리포지토리에 체크인 하는 개발자가 잘못하고 있습니다. (2)

따라서이 단계에서는 개발 및 테스트 수행 방법에 대한 기본 구조를 위반하는 한쪽 또는 양쪽이 없으면이 체계가 작동 할 수있는 방법이 없습니다.

(1) 테스트 한 버전을 문서화해야하기 때문입니다. Git 해시 또는 SVN 개정 번호로 태그가 지정된 버전은 "Joe가 준 코드"는 테스트 할 수 없습니다.

(2) 테스트 드라이버 외부에서는 실패 할 것으로 예상 하지 않기 때문입니다.

이는 개발자, 테스터 및 관리자 모두에게 즉각적으로 의미가있는 가장 짧은 "엘리베이터 피치"이유에 대한 시도입니다.

품질 관리팀에 보내는 모든 빌드에 의도적으로 버그를 삽입하지 않는 것이 좋습니다.

때때로 1 년에 한 번 은밀한 "QA 감사"를 수행 할 수 있습니다. "테스트되고 작동하는"코드베이스와 가능한 많은 Todo 목록의 작은 새 기능을 사용하십시오. 평소보다 "조금 더 멍청하게"구현하십시오. 엣지 케이스를 생각하고 적어 두십시오. 그러나 코드를 수정하여 고려하지 마십시오. 품질 보증팀으로 보냅니다.

그들이 당신이 적어 놓은 것보다 더 작동하지 않는 최첨단 버그를 발견한다면, 감독이 필요한 것은 QA가 아닙니다 ... ;-)