스크럼 가이드에서 테스터가없는 이유는 무엇입니까?

scrum.org에서 Scrum Guide를 읽었으며 다음과 같이 말합니다.

개발 팀에는 테스트 또는 비즈니스 분석과 같은 특정 도메인 전용 하위 팀이 없습니다.

문자 그대로의 번역에서 이것은 혼란스러운 테스터가 없음을 의미합니다. 그들은 이것을 어떻게 제안 할 수 있습니까?

다음 중 하나를 의미합니다.

1. 테스터는 개발 팀에 통합되어 개발자는 테스트뿐만 아니라 테스트 할 수 있도록 도구를 구축합니다.

   또는:

2. 팀은 테스트 주도 개발을 수행합니다. 즉, 시스템을 실행하는 자동화 된 테스트를 작성합니다.

이 중 하나는 별도의 테스트 팀이 필요하지 않음을 의미합니다.

문자 그대로의 번역에서 이것은 혼란스러운 테스터가 없다는 것을 의미합니다 ... 어떻게 이것을 제안 할 수 있습니까?

예, 이것이 바로 그들이 제안하는 것입니다. 다시 말해 개발자는 테스터이고 테스터는 개발자입니다.

아이디어는 코드 소유권과 품질을 향상시키는 것 입니다.

그렇다고 코드가 테스트되지는 않았지만 코드 작성에 관여하는 사람들이 코드를 테스트하는 사람들이라는 것을 의미합니다. 책임의 분리가 없습니다.

이 접근 방식으로 해결하려는 문제는 개발자와 테스터 사이의 너무 일반적인 분리입니다. 개발자가 코드를 작성하고 다른 팀에 "벽을 넘어서 던질"경우 프로젝트가 지연되고 생성됩니다. 하위 표준 소프트웨어.

이것의 기본 부분은 코더의 책임이 작동하고 요구 사항을 채우는 코드를 작성하는 것입니다. 여기에는 특정한 사고 방식이 필요합니다. "작성중인 코드가 수행해야하는 작업을 수행합니다."

코더의 책임을 혼합한다는 것은 코더가 다른 활동에 대한 다른 사고 방식을 입력해야한다는 것을 의미하지만, 코더로서 자신과 자신의 사고를 완전히 이혼하는 것은 불가능합니다.

테스터의 책임은 기능과 필요한 기능이 다른 버그와 장소를 찾는 것입니다. 이를 위해서는 "코드가 깨져서 어떻게 찾을 수 있는지"라는 사고 방식이 필요했습니다.

마찬가지로 비즈니스 분석가는 고객이 실제로 요구하는 요구 사항을 식별하려고합니다. 이를 위해서는 "응용 프로그램이이 방식으로 작동하지 않지만 작동해야합니다"라는 다른 사고 방식이 필요합니다.

코더가 다른 용량으로 작동하려면 사고 방식이 충돌하고 코더가 하위 수준을 수행 할 가능성이 합리적입니다.

• Coder / QA- "이 코드는 완벽하게 작동하며 이미 깨뜨릴 수있는 모든 가능한 방법을 처리하도록 코딩되었습니다."
• Coder / BA- "코드는 내가 원하는 방식으로 작동해야하며 고객이 생각하지 않은 깔끔한 코드가 될 것입니다.

이것은 모든 코더가 이러한 문제에 취약하다는 것을 말하는 것은 아닙니다 (저는 매우 재능있는 코더 / QA 유형을 만났습니다 ...하지만 그들이 작성한 코드는 아닙니다).

이것은 개발 팀까지 확장됩니다. 개발 팀의 책임과 관련 책임을 혼합하면 최종 제품 (코드)이 손상됩니다.

테스트 전용 하위 팀 이 없다고 말합니다 . 그렇다고 테스트가 수행되지 않았다는 의미는 아닙니다. 이는 팀원이 자체 테스트를 수행하고 종종 다른 사람의 코드 / 기능을 테스트한다는 의미입니다. 나는 스크럼 방법론에 익숙하지 않지만, 사지로 가서 클라이언트가 테스트에 참여할 수도 있다고 말할 것이다.

나는 이것이 부분적으로 자신의 코드에 대한 테스트를 작성해야 작동한다는 것을 의미한다고 생각합니다. .

사람들이 소프트웨어 품질 작업을 다른 사람에게 오프로드하고 무시하는 대신 항상 품질 관점에서 작성하는 코드에 대해 모든 사람이 생각하도록 강요하는 것이 좋습니다.

이 진술은 기본적으로 사일로 작업을 피하려고합니다. 이에 대한 솔루션 중 하나는 테스트 중심 개발-페어 프로그래밍-풀 요청-테스트 자동화 및 모두 측면에서 독립적으로 수행되는 것이 아니라 개발 프로세스의 본질적인 부분을 테스트하는 것과 같은 사례입니다. '후'.

또한 Scrum Guide에는 역할에 대한 이야기가 매우 제한적입니다. 사실, 그들은 개발 팀에 대해 이야기합니다. 그들이 의미하는 것은 강력한 교차 기능 팀을 원한다는 것입니다. 즉, 프로젝트에 필요한 것에 따라 UX, BA, QA / Tester, Ops, Coder 등과 같은 다양한 기술이 필요하지만이를 다루는 한 명 또는 여러 명의 개인이 실제로는 중요하지 않습니다.

우리와 함께 일하는 팀은 DevOps 직원이 있기 때문에 QA를 역할로합니다. 그러나 그들은 또한이 분야의 전문성을 갖춘 모두 Dev입니다. 비결은 실제로 사일로에 빠지지 않고 격리되어 작동하는 것입니다.

테스터가 없다는 의미는 아닙니다. 스크럼 팀에 전담 테스터가 있거나 없을 수도 있습니다.

나에게 스크럼에 대한이 말은 전체 전달 파이프 라인을 단일 팀으로 생각해야한다는 것입니다. 같은 팀에 속해 있다는 것은 몇 가지 사항을 제안합니다.

1. 스토리 / 버그 / 태스크에 대한 단일 추정치가 있습니다. 개발 견적 및 테스트 추정치는 없습니다.
2. 팀은 테스터가 없으면 스토리를 추정하지 않고 커밋합니다.
3. 무언가 잘못되면 개발자의 잘못보다 테스터의 잘못이 아닙니다. 팀의 잘못 입니다.
4. 팀은 테스터를 빌리거나 요청하거나 요구할 필요가 없습니다.
5. 테스트는 완료 정의의 일부입니다. 테스트되지 않은 작업은 불완전한 작업입니다.
6. 개발자는 코드를 디자인 할 때 테스트 가능성을 고려해야합니다.

그들이 한 팀으로 함께 일하면 팀은 함께 성공하고 함께 실패합니다. 저는 여러 명의 테스터를 보유한 매우 성공적인 스크럼 팀에있었습니다. 테스터들은 모든 스탠드 업, 손질 세션, 계획 등에서 참석했습니다. 스토리를 테스트하는 방법이 확실하지 않다면, 팀은 그것에 헌신하지 않을 것입니다. 우리는 추정 할 때 항상 테스터와 대화했습니다.

다음과 같은 생각이 들더라도 테스터를 배달 팀의 일원으로 취급하지 않을 수 있습니다.

1. 테스터에는 "QA 스탠드 업"이 있습니다 (예, 본 적이 있습니다).
2. 테스터는 별도의 관리 구조를 가지고 있습니다.
3. 품질 관리 리드가 있습니다.
4. 엔드 투 엔드 테스트에 크게 의존합니다.
5. 테스트는 다음 스프린트로 작성됩니다.
6. 대부분의 테스트는 스프린트 마지막 날에 수행됩니다.

이것들은 주관적이며 반드시 틀린 것은 아닙니다. 내 의견으로는, 그들은 붉은 깃발입니다.

이 모든 것에서, 지정된 테스터 역할을 가진 사람없이 Scrum 팀을 가질 수 있습니다. 그것도 잘 작동 할 수 있습니다. 특히 테스트를 자동화하는 경우. TDD도 도움이됩니다.