테스터가 테스트를 설계하는 데 프로그래머가 얼마나 도움을 주어야합니까?
나는 그들이 전혀 도와 주어야한다고 생각하지 않습니다. 내 걱정은 테스터가 자신의 코드에 대한 테스트를 설계하는 데 도움이된다면 테스터에게 자신의 편견과 해당 코드에 대한 사각 지대를 '감염'시킬 것입니다.
테스터가 테스트를 작성하는 데 필요한 정보를 제공하기 위해 요구 사항이 충분해야한다고 생각합니다. 프로그래머가 걱정하는 구현의 일부가 있다면, 그 부분을 테스트하기 위해 단위 테스트를 구현하거나 자신의 비공식 시스템 테스트를 실행하여 해당 부분을 테스트하는 것이 의무라고 생각합니다.
내가 아는 모든 사람이 이것에 동의하지는 않습니다 (그리고 나는 그들의 요점을 어느 정도 이해합니다). 다른 사람들은 이것에 대해 어떻게 생각합니까? 이것은 어디에서나 문헌에서 논의되고 있습니까?
답변:
나는 동의한다. 프로그래머는 테스터가 기능 사양을 이해하고 연구 할 리소스를 찾도록 도와 줄 수 있지만 테스터의 마음을 테스트 방법에 대한 자신의 아이디어로 오염해서는 안됩니다.
QA 영역에서 개발자와 테스터가 평화롭게 공존 할 여지가 있다고 생각합니다. :)
좀 더 구체적으로 말하면 개발자는 테스터에게 전달하기 전에 대부분의 경우 물건이 작동하는지 확인하기 위해 단위 테스트 및 기본 통합 테스트의 첫 번째 테스트 수준을 책임 져야한다고 생각합니다.
구현 세부 사항과 완전히 무관 한 요구 사항을 기반으로 승인 테스트를 작성하는 것은 테스터에게 달려 있습니다 (일반적으로 '블랙 박스 테스트'라고 함). 테스터와 개발자가 요구 사항을 이해하는 방법에 차이가있는 경우 프로젝트 관리자 (있는 경우)가 해결하거나 모든 사람이 기능의 디자인 단계에서 같은 페이지에 있는지 확인하여 문제를 해결해야합니다.
테스트와 개발은 공동 작업 이므로 IMO (개발자)는 테스트 아이디어를 테스터에게 제공해야합니다. 나는 그것이 그들을 감염 시키거나 테스터를 전혀 오염시키지 않는다고 생각합니다. 물론 테스터는 다른 많은 테스트 방법으로 테스트를 강화해야합니다.
나는 또한 개발자들을 돕는 테스터들의 열렬한 팬입니다. 저는 개발자들과 디자인 아이디어를 브레인 스토밍하고 그들과 짝을 이루어 내 경력에서 여러 번 버그를 수정하고 (버그와 제안 된 수정 사항을 지적) 내 생각하지 않습니다. ve는 테스터 전문가가있는 개발자를 오염 시켰습니다.
공동 작업으로 보지 않으면 개발자에서 테스트에 이르기까지 "벽에 던져지는"코드 만 있으면 품질이 떨어집니다. 그것은 내 세상의 진실이지만 (물론) ymmv.
내가 보는 방식은 코드를 테스트하는 것이 QA의 일이 아니라는 것입니다. 테스터의 임무는 내 코드가 해당 작업의 모든 요구 사항을 충족시키는 지 확인하는 것입니다.
QA에 무언가를 전달하면 내 코드의 세부 사항이 아니라 내가하고있는 작업을 알 수 있습니다. 나는 'bone head'버그가있는 QA에 아무것도 전달하지 않습니다. 그것은 내 시간과 그들의 시간을 낭비하고 거의 모든 사람들의 시간을 낭비합니다.
마지막 직장에서 처음부터 QA를 수행했습니다. 그것은 요구 사항 수집 세션, 프로젝트 미팅 및 디자인 미팅에도있었습니다. 그들은 듣고 질문을했고 개발자는 코드를 작성하는 동안 테스트 계획을 작성했습니다. 그것은 잘 풀 렸고 아마 미끄러 졌을 많은 문제를 발견했습니다.
나는 당신이 여기에 꽤 잘못 생각합니다. 나는 테스터이자 개발자였으며 위험성이 높거나 깨지기 쉬운 영역에 대한 개발자의지도를 통해 테스터로서 큰 혜택을 얻었습니다. 개발자로서 테스터가 깊이 조사하지 않은 문제를 찾길 원합니다.
코드가 원시 하수인 경우를 제외하고는 "오염"이 없었으며 이는 완전히 다른 이유 일 것입니다.
요구 사항은 QA 전문가가 관심을 가질만한 기술적 인 문제를 전달하는 데있어 끔찍한 일입니다. 비즈니스 분석가가 파악한 것만 최대한으로 자세히 설명하기 때문입니다. 좋은 개발자는 자신의 코드가 "행복한 길"에 최적화되어 있다는 사실을 알고 있으며 고려하지 않은 내용을 알고 싶어 할 것입니다. 그들은 적어도 무엇이 잘못 될 수 있는지, 그리고 QA가 조사하기를 원하는 분야에 대한 직관을 가질 것입니다. 또한 설계에 따라 특정 기능을 둘러싼 위험에 대한 큰 그림이 무엇인지 알고 있습니다.
테스터가 개발 팀의 지침을 따르지 않았을 때 좋은 버그 보고서를 생성하는 잘못된 접근 방식을 사용했지만 때로는 더 나은 공동 작업을 통해 피할 수있는 고위험 코드 경로와 더 큰 문제를 완전히 해결하지 못했습니다. 고객에게 배송 된 개발 팀과 함께
테스터는 개발자가 말한 내용 만 테스트하도록 제한해서는 안되지만 개발자가 코드에 대해 우려하는 사항을 학습해도 손상되지는 않습니다. 때로는 구현에 대한 지식을 바탕으로 접근 방식을 미세 조정할 수 있습니다. 테스터가 특히 근시안적인 경우에만 위험이 최종 단어 인 것에 대한 개발자의 의견을 고려합니다. 개발자가 위험도가 낮은 것으로 식별하는 것을 완전히 차단하지는 않지만 고객에게 더 큰 영향을 줄 수있는 것에 더 많은 노력을 기울일 것입니다.
QA 팀은 시스템의 요구 사항 수집기 또는 개발자보다 조합 테스트 범위가 큰 영역을 볼 수 있지만 설계에 대한 인식으로 인해 더 미묘한 취약성이있는 시스템 구성 요소를 인식하지 못할 수 있습니다. 또는 시스템의 구현.
내 경험상 QA와 개발 간의 협력은보다 우수한 품질의 제품을 생산합니다. 블랙 박스 핸드 오프 만 수행하는 것은 권장하지 않습니다.
테스터로서, 나는 테스트 케이스를 제안하거나 (그러한 테스트 케이스에만 충실하겠다는 의미는 아니지만) 구현 세부 사항을 설명하는 프로그래머에게 전혀 반대하지 않습니다. 때때로 누군가에게 "이 비트가 위험 할 수 있다고 생각합니다.이 비트를 아주 철저히 테스트했다면 정말 좋겠습니다"라고 말하는 것이 도움이 될 수 있습니다. 구현 세부 사항 중 일부를 알고 있으면 수년간의 경험을 적용하여 가장 실패 할 것으로 생각되는 테스트를 선택할 수 있습니다. 때로는 간단히 언급하면 몇 가지 테스트가 갑자기 내 우선 순위 목록을 확대합니다.
그것은 나를 오염 시키는가? 나는 프로그래머가 내 테스터의 순도를 보존하기 위해 열심히 노력하고 있다는 생각에 약간 간질이 있지만 실제로는 아닙니다. 이것은 신화입니다. 더 많은 정보는 일반적으로 더 적은 질문이 아니라 더 많은 질문을 유발합니다. 나는 그것이 사고 방식이라고 생각합니다-나는 무지하기 때문에 버그를 발견하지 못합니다. 전적으로 신뢰에 대한 모든 것을 취하기에 너무 고집이 많은 회의적이고 신뢰할 수없는 유형이기 때문에 문제를 찾습니다. 테스트 한 모든 시스템에서 더 많은 문제와 "흥미로운"문제를 발견할수록 더 깊이 이해하게되었습니다.
우리가 QA 직원이 부족한 이후 Selenium에서 테스트 사례를 구현하고 작성해야한다는 이상한 위치에 있습니다. 테스트 중심 개발이 매우 도움이 되겠지만 아직 상점에 적용되지는 않았습니다.
테스트 작성에 도움이되는 것은 테스트를 작성할 때 버그를 발견한다는 것입니다. 더 강력한 코드를 작성하는 데 도움이되는 다른 관점에서 생각합니다. 그러나 테스트 범위가 제한 될 수 있다는 것은 사실입니다. 이 경우 품질 보증팀은 항상 원하는 내용을 알려줄 수 있습니다. 또는 오류가 발생하면 수동으로 더 많은 테스트를 추가 할 수 있습니다.
QA를 수행하고 있으며 코드를 사용하는 방법을 아는 대부분의 도메인과 달리 프로그래밍 언어를 배우는 것보다 훨씬 어렵습니다. 그래서 우리는 개발자들에게 새로운 whizzbang 기능에 대한 테스트 사례를 제공 할 것이라고 믿고 있습니다. 어쨌든 QA 문제는 새로운 기능의 원래 테스트보다 회귀 및 파손 된 부분을 포착하는 데 더 중요합니다. 어쨌든 결과가 복잡한 계산 인 경우 정답이 무엇인지, 정답이 무엇인지, 또는 비정상 종료가 좋은지 나쁜지를 알기가 어렵습니다.
어쨌든 개발자는 정직하다면 아기의 취약점을 알고있을 것입니다. 그는 어떤 매개 변수 값을 알고 있고 다른 알고리즘이나 테이블 조회에서 도메인을 선택해야합니다. 엄격한 테스트에 대해 진지하게 알고 있다면 많은 코드를 다루는 합리적인 크기의 테스트 모음을 생성 할 수 있어야합니다.