* 전용 * 테스터 역할이없는 개발팀의 생존 가능성

최근 린 개발 팀을 구축하는 방법에 대해 많이 생각하고 있습니다. 궁극적으로, 나는 같은 생각을 가진 소수의 사람들과 함께 내 작은 소프트웨어 하우스를 열고 싶습니다. 목표는 부자가되는 것이 아니라 건강한 업무 환경을 유지하는 것입니다.

지금까지 린 팀을 다음과 같이 정의하고 있습니다.

• 작은;
• 자기 조직;
• 모든 회원은 QA를 염두에 두어야합니다.
• 회원은 여러 역할을 수행 할 수 있어야합니다

마지막 요점은 진언이 진행됨에 따라 조금 걱정되는 부분입니다.

개발자는 나쁜 테스터를 만듭니다.

나는 종종 개발자들이 자신의 코드 나 동료의 코드에 "너무 근접하여"품질에 대한 높은 수준의 평가를한다는 것을 이해하지만, 실제로 테스터 라는 것은 확실하지 않습니다 . 반대로, 좋은 개발자의 자질은 좋은 테스터의 자질과 크게 겹친다는 의견입니다.

이것이 정확하다고 가정하면 개발자 / 테스터 문제를 해결하는 여러 가지 방법을 생각하고 있으며 실행 가능한 모델을 생각해 냈습니다.

내 모델에는 다음이 필요합니다.

• 2 개 이상의 프로젝트가있는 소규모 소프트웨어 하우스
• 개발 및 제공에 대한 민첩한 (반복적 인) 접근 방식
• 프로젝트 당 1 팀
• 모든 팀원은 소프트웨어 개발자가됩니다
  • 그들의 직무 설명은 개발 , 품질 보증 , 테스트 및 납품 을 책임으로 명확하게 진술 할 것입니다

이러한 전제 조건이 모두 충족되면 프로젝트를 다음과 같은 방식으로 구성 할 수 있습니다 (이 예에서는 두 개의 프로젝트 A 및 B를 참조 함 ).

• 모든 팀원은 개발자 역할과 테스터 역할을 번갈아 가며
• 팀원이 프로젝트 A 의 개발자 인 경우 프로젝트 B 의 테스터가됩니다.
  • 멤버는 한 번에 하나의 프로젝트에서만 작업하므로 개발자 또는 테스터 역할을 수행 해야 합니다 .
• 역할주기 (두 개의 다른 프로젝트에서 다시) 데브 같이 3 번 반복하고, 테스터 2 반복으로 구성
• 프로젝트 팀에는 항상 3 명의 개발자와 2 명의 테스터가 있습니다.
• 멤버 역할주기는 1 회 반복 단계를 벗어나야합니다.
  • 이렇게하면 팀 변경의 갑작스러운 발생이 최소화됩니다. 각 반복에 대해 2 Devs 및 1 Tester는 이전 반복과 동일하게 유지됩니다.

위의 점을 감안할 때 다음과 같은 장단점이 있습니다.

찬성

• 회사 전체에 프로젝트 지식을 배포합니다.
• 팀원이 작성하는 데 도움이되는 코드를 테스트하지 않도록합니다.
• 단계를 벗어난 역할주기는 프로젝트에 100 % 멤버 스위치가없는 것을 의미합니다.
• 대체 역할은 지루한 프로젝트의 단조 로움을 깨뜨립니다.

단점

• 두 프로젝트의 반복은 밀접하게 연결되어 있습니다. 한 프로젝트가 반쯤 반복을 취소하고 다시 시작하면 두 프로젝트가 동기화되지 않은 것입니다. 이로 인해 역할주기 관리가 어려워집니다.
• 개발자 채용에 대한 경첩은 테스터로도 활동합니다.

이 접근법을 친구 및 동료와 논의 할 때 혼합 된 리뷰를 받았습니다. 일부 개발자는 이와 같은 역할을 대체하려는 개발자가 거의 없으며 다른 개발자는 개인적으로 시도해보고 싶다고 말합니다.

내 질문은 : 실제로 그러한 모델이 작동 할 수 있습니까? 그렇지 않은 경우 작동 모델로 조정할 수 있습니까?

참고 : 간결하게하기 위해 개발자 및 테스터 역할에만 집중했습니다. 필요한 경우 다른 역할을 확장하겠습니다.

동의하지 않습니다

개발자는 나쁜 테스터를 만듭니다

경력에 종사 한 대부분의 팀은 QA 지원을받지 못했습니다. 여기에는 글로벌 로그인 및 등록 시스템과 같은 제품과 관련된 대규모 글로벌 기업이 포함됩니다. 또 다른 경우에는 회사 매출의 30 %가 책상 위의 상자를 통해 실행되었습니다. (이러한 관행은 BTW에 권장되지 않습니다.)이 회사들은 코드가 올바르게 작동하는지 확인하기 위해 엔지니어에게 의존했습니다. 그리고 우리는 세부 지향적이고, 약간 강박적이고, 우리의 일을 자랑스럽게 생각하며, 소프트웨어가 올바르게 작동하도록 많은 노력을 기울였습니다.

또한 개발자로서 테스터보다 훨씬 많은 테스트를 수행합니다. Java로 작업하지 않는 경우 코드를 90 % 또는 100 %로 정기적으로 단위 테스트합니다.

테스터와 다른 관점에서 와서 내가 생각하지 못한 것을 포착하기 때문에 테스터와 함께 일하는 것을 좋아합니다. 그러나 실제로는 30 ~ 50 % 이상의 테스트 범위를 제공한다고 생각하지는 않지만 100 %를 책임집니다. (BTW 슬램이 아닙니다. 일반적으로 프로젝트 전체에 얇게 퍼져 있습니다.)

인터뷰에서 엔지니어에게 QA를 원하는지 묻지 말고 프로덕션에 버그가 표시되면 누가 책임을 지는가? 버그를 소개하고 고객이 경험하면 기분이 나 빠지고 책임을집니다. 품질 관리 담당자를 비난하지 않습니다. IMHO 그것은 당신이 고용하고 함께 일하고 싶은 종류의 엔지니어입니다.

품질을 보장하는 나의 방법은 a) 매우 공격적인 단위 테스트입니다. (완전히 테스트 주도 개발을 수행 할 수는 없지만) b) 강력한 코드 검토 프로세스가 실제로 도움이됩니다. 팀 문화의 결함.

가장 고위 사람들은 더 큰 문제를 지적 할 수 있기 때문에 가장 부지런하고 사소한 문제에도주의를 기울이는 사람들 이었다는 사실에 항상 충격을 받았습니다. 그러나 주로 그들은 그것을 얻기 위해 시간을 보내는 것을 가장 기꺼이했다.

그러나 특히 소규모 회사에서 작업 한 대부분의 팀에는 공식적인 QA 구성 요소가 없었습니다.

@Rob Y의 답변에 동의하며 몇 가지 사항을 추가하고 싶습니다.

• 민첩하게 팀 내의 전담 테스터는 반 패턴입니다. 팀이 작업을 파이프 라인으로 만들고 본질적으로 비효율적이기 때문입니다. 당신은 끊임없이 "dev done"이지만 테스트되지 않은 이야기로 끝납니다. 전담 테스터가 팀 외부 (또는 별도의 팀)에서 근무하는 경우 문제가 없습니다.

• 개발자는 나쁜 테스터를 만들고 ... 테스터는 나쁜 테스터를 만듭니다. 품질 관리는 어렵습니다. 실제로, 그것은 매우 어렵다. 문제는 사람과 역할이 아닐 수 있습니다. 문제는 소프트웨어가 돌진 된 것일 수 있습니다. 또한 민첩하게도 QA 전담 여부에 관계없이 프로덕션 전에 테스트하는 것은 팀의 책임입니다.

• QA는 리팩토링, 아키텍처 등과 같은 개발의 일부입니다. 소프트웨어를 특정의 합의 된 현실적인 표준에 따라 생성하는 것은 개발 팀의 책임입니다. 품질 관리팀은이 표준을 개선하지 않습니다. 더 나은 개발자는 아마 할 것입니다.

• 도발 : QA는 QA-ing의 개발자보다 QA가 더 낫다고 누가 말합니까? 사람들이 말하는 것이지만 ... [인용이 필요했습니다.] QA에 필요한 "해커"사고 방식은 개발자의 사고 방식입니다. 실제로 기본적으로 모든 해커는 QA가 아닌 개발자이거나 개발자였습니다.

• 도발 2 : QA 작업의 99 %가 스크립트를 통해 자동화 될 수 있습니다 (그리고 감히 말해야 합니다 ). 좋은 팀이이 작업을 수행하고 제대로 수행하려면 개발자가 필요합니다.

이전에는 QA 직원이없고 개발자 만있었습니다. 결과적으로 문제가 생산에 영향을 미쳤다면 다른 사람은 책임이 없습니다. 우리는 QA 책임을 매우 진지하게 받아들였으며 자동화 된 테스트 스위트에 크게 의존했습니다. 자동화 된 테스트를 작성하는 것은 여전히 ​​코딩 작업이므로 개발자가 테스트를 수행하는 것은 그리 중요하지 않았습니다.

핵심은 팀 문화와 모든 프로젝트의 일부로 만드는 것입니다. 우리는 테스트 계획 (프로젝트를 위해 작성하려는 간단한 테스트 목록)을 작성했으며 다른 개발자는 우리가 놓친 사례와 시나리오를 검토하고 제안 할 것입니다.

당신이 그것에 대해 엄격한 경우, 그것은 잘 작동 할 수 있습니다. 상시 가동되는 전자 상거래 웹 서비스에서 가동 시간이 우수하고 결함이 적었습니다.

먼저 경고-QA 엔지니어와 소프트웨어 엔지니어로 전문적으로 일했습니다.

그러한 모델이 실제로 작동 할 수 있습니까?

무엇이든 가능합니다.

나는 종종 개발자들이 자신의 코드 나 동료의 코드에 "너무 근접하여"품질에 대한 높은 수준의 평가를한다는 것을 이해하지만, 실제로 테스터라는 것은 확실하지 않습니다. 반대로, 좋은 개발자의 자질은 좋은 테스터의 자질과 크게 겹친다는 의견입니다.

필요한 테스트 종류에 따라 다릅니다. 모든 단일 화면이나 요소가 실제로 엘보 니아 어로 번역되었는지 확인하기 위해 마음을 사로 잡는 단조로운 반복 수동 테스트가 필요한 경우 문제가 발생합니다.

그리고 내 경험에 따르면 모든 프로젝트에는 최소한 이런 종류의 테스트가 필요합니다 (모든 프로젝트 가 그런 종류의 테스트를 수행 하지는 않았 더라도 ). 문제는 품질 관리 우수 사례에 익숙하지 않은 사람들로부터 이런 종류의 테스트를받지 못한다는 것입니다. 지옥, 당신은 베스트 프랙티스를 아는 사람들로부터 그것을 얻지 못하고 개발자를 "신뢰"합니다.

테스터는 개발자를 신뢰할 수 없습니다. "이 변경으로 인해 발생했을 수 없습니다"또는 "개발자 상자에서 완벽하게 작동"한다는 버그를 잃어 버렸습니다.

5 주 중 2 주 동안 좋아하는 일을하지 않는 것을 용납 할 수있는 개발자를 찾을 수 있더라도이 핵심 모순에 빠질 것입니다. 더 나쁜 것은, 사람들이 하나가 아닌 두 가지 일을 잘하도록 훈련시키기 위해 시간과 에너지를 소비하고 있다는 것입니다. 회사는 두 가지가 아닌 한 가지 일을 잘하는 사람들을 찾고 훈련시키는 데 어려움을 겪고 있습니다.

어쩌면 당신은 내가 아직 겪지 않은 방식으로 대단하지만 어쩌면 의심합니다.

나는 그것이 효과가 있다고 생각하지만, 당신이해야 할 몇 가지가 있습니다.

1. 응시자의 이중 역할에 대해 매우 선행하십시오. 여러 가지 이유로 모두를위한 것은 아닙니다. 마음에 들지 않는 사람이 너무 많으면 실패하고 이직하게됩니다.
2. 이를 팀과 통합하는 가장 좋은 방법을 평가할 수있는 계획을 세우십시오. 한 번에 하나의 작업 / 프로젝트에 집중하고 싶지만 매우 오랜 시간 동안 프로그래밍하고 싶지는 않습니다. 아마도 테스트는 프로그래밍에서 멀리 떨어진 멋진 휴가 일 것입니다. 변화를 위해 다른 뇌 세포를 사용하는 것이 더 쉽지는 않습니다. 가장 좋은 것을 결정하기 전에 다른 방법으로 시도 할 준비를하십시오.

프로젝트 동기화는 실용적인 솔루션처럼 보이지 않습니다. 누군가가 프로젝트의 테스터 인 경우 프로그래머를 대체하고 그 반대의 경우가 가장 좋습니다.

이 계획은 팀이 자체 구성 할 수 없습니다. 하나의 전략이 모든 팀과 모든 프로젝트에 적합한 것은 아닙니다.