동일한 스프린트에서 코딩 및 테스트

스프린트가 끝날 때까지 모든 또는 대부분의 코딩이 수행되지 않으면 테스트는 코딩과 동일한 스프린트 내에서 어떻게 처리됩니까? (스프린트 내에서 단일 PBI의 "너트 간"개발 및 테스트를 언급하고있다.)

온라인에서 본 대부분의 답변에는 QA 자동화가 포함되어 있지만 자동화 된 테스트를 기록하거나 작성하려면 일반적으로 기능적인 UI가 필요하기 때문에 실제로는 불가능합니다. 기능을 개발하고 새로운 요구 사항을 발견함에 따라 계속 발전하는 스토리 보드 만 있습니다.

필자의 경우 새로운 데스크톱 응용 프로그램을 개발 중입니다. 데스크톱 앱은 일반적으로 자동 테스트에 적합하지 않습니다. 자동화 된 단위 테스트가 있지만 QA 전문가가 수행 할 수동 기능 / 통합 테스트가 아닙니다.

그래서 지금은 스프린트가 내일 끝나고 여전히 코딩을 마쳤으며 QA 직원은 아직 테스트 할 것이 없으며 손으로 쥐지 않고도 무엇을 줄지 테스트 할 방법을 모릅니다.

나는이 딜레마를 가진 사람이 처음이 아니라고 확신한다.

과거에는 파이프 라인을 작성했습니다. 현재 스프린트에서 테스트 팀은 이전 스프린트 동안 구현 된 기능을 테스트합니다. 현재 직장에서 PM은이 접근 방식을 "폭포"라고하며 허용되지 않습니다.

사용자 스토리를 테스트하지 않고 (미국) 수용 기준이 충족되는지 확인하면이 스토리는 수행되지 않습니다. 그것이 완료되지 않으면 미국은 물론 다음 스프린트로 간다. 그리고 모든 미국이이 주에 있다면 스프린트는 프로젝트에 부가가치없이 끝납니다. 고객의 입장에서는 휴가를가는 전체 개발 팀과 구별 할 수 없습니다.

린 원칙 중 하나 (애자일은 스크럼으로 끝나지 않습니다)는 "품질이 내장되어 있습니다"라고 말합니다. 정의한 품질 기준을 충족하는 경우에만 수행됩니다. 이는 실제 민첩한 프로세스를 유지하는 데 중요합니다. 값이 0 인 스프링으로 끝나거나 개발과 별도로 테스트하는 것이 큰 문제의 증상입니다.

할 수있는 일이 많이 있습니다 :

• 자동화는 성공의 열쇠입니다. 적어도 단위 테스트 수준에서는 CI와 같은 다른 방법도 중요합니다. 이것으로 충분하지는 않지만, 이러한 유형의 테스트를 잘 수행하면 수동 테스트에서 발견 된 버그가 거의 또는 전혀 발생하지 않습니다 (일반적으로 사소한 UI). 전담 QA 직원이있는 경우 승인 테스트를 자동화하는 사람이 될 수 있으며,이 자동화 중 일부는 스프린트를 마치기 전에 시작할 수 있습니다.

• 사용자 스토리의 크기를보십시오. 스프린트 첫 2 일째에 완료된 미국이있는 경우 QA 담당자가 테스트 할 수 있습니다. 제 생각에는 민첩한 개발에서 성공하기 위해 가장 중요한 것 중 하나 인 SMART (스마트) 사용자 기록이 있으며 많은 사람들이이를 인식하지 못하는 것 같습니다.

• 테스터와 개발자 간의 협업은 성공의 또 다른 핵심 부분입니다. 이전의 프로젝트에서 미국이 개발자에 의해 완성되었을 때 QA 담당자는 개발자와 "페어 테스트"를 수행합니다 (수 동일 수도 있고 자동화 된 또는 더 나은 방법으로 시작하는 것도 가능).

본질적인 문제는 코드를 작성하지만 테스트하지 않는 프로그래머와 테스트하지만 코드를 작성하지 않는 테스터가 있다는 것입니다.

그 문제를 해결하면이 문제는 없을 것입니다.

과거에 저에게 도움이 된 한 가지 방법은 코더와 테스터에게 완전히 테스트 된 스토리를 전달하는 명백한 작업과 스토리를 결합하도록 제안하는 것이 었습니다. 그것과 함께 나는 모든 형태의 "dev complete"사고를 지웠다. scrum / kanban / trello 보드에 "dev complete"열이없고, 코더에 의한 "dev done"태도는 없다.

일어난 일은 :

• 페어는 스토리를 전달할 책임이 있으며 스토리가 완료되지 않으면 둘 다 실패합니다. 그들은 소프트웨어 제공을 담당하는 책임있는 전문가로 대우 받았으며 대부분의 경우 그렇게했습니다.

• 테스터가 단위 및 통합 테스트에 노출되어 동일한 테스트를 수동으로 반복하지 않았기 때문에 테스트 작업이 훨씬 줄었습니다.

• 개발자가 테스터에게 필요한 것을 더 잘 이해하면 일부 테스트가 자동화되었습니다.

• 어떤 사람들은 화를 냈습니다.

• 코드 커밋-풀 테스트주기가 거의 즉각적이 되었기 때문에 스토리가 평균적으로 더 빨리 전달되었습니다.

물론 이것은 일화적인 경험 일 뿐이지 만 가능하다면 직접 시도해 볼 수도 있습니다.

귀하의 경우 테스터와 개발자가 귀하의 회사에서 정식으로 분리되었다는 귀하의 의견을 감안할 때 메시지가 분명합니다. 회사 규칙에 따라 의사 소통 및 협업에 대한 명백한 장벽이 있습니다.

이것은이다 통신 문제가 아닌 민첩 문제. 민첩한 방법론을 채택하는 것만으로도 분명해집니다. Silo'd 팀은 잘 알려진 관리 안티 패턴 이므로이 경우 민첩성이 적응할 수 없습니다!

QA의 실제 역할은 승인 테스트에 가깝습니다. 개발 팀의 일원이 아닌 제품 소유자의 역할을 수행하는 별도의 팀이이 작업을 수행한다고 생각합니다.

예 : 스프린트 중에 다른 기준으로 검색 결과를 필터링 할 수있는 기능을 추가해야합니다. 검색 메커니즘이 이미 구현되어 있지만 결과는 사전 순으로 정렬됩니다.

• 스프린트 동안 :

  1. 팀은 새로운 기능의 설계와 실제 코드 기반에 미치는 영향을 초안합니다.

  2. 개발자는 주문이 예상대로 작동하는지 확인하고 동시에 실제 코드를 작성하는 단위 테스트를 작성합니다.

  3. 새로운 기능은 신중하게 테스트하여 아무런 문제가 없는지 (회귀 테스트), 예상대로 작동하는지 (단위 테스트)를 확인합니다.

  4. 가능하고 적절한 경우 , 대부분의 프로젝트의 경우하지 않은 , 제품 소유자는 (그리고 QA 팀 정도) 지속적으로 잘못된 방향으로가는 팀을 방지하기 위해 새로운 기능을 평가할 수 있습니다. 이를 위해서는 매일 수십 개의 빌드와 지속적인 통합이 필요합니다.

• 스프린트 후 제품 소유자는 새 기능을 평가하여 고객의 요구에 맞는지 확인합니다. 스프린트가 끝나면 QA 팀이 실제로 여기에 있습니다.

귀하의 실제 문제는 다음과 같습니다.

• 범위 . 스프린트는 제품 소유자 역할을하는 실제 QA가 아닌 팀 및 팀에만 해당됩니다.

• 테스트 . QA 팀이 있다고해서 반드시 코드를 작성해야한다는 의미는 아닙니다. 팀의 임무는 다른 사람이 테스트 할 코드를 버리지 않고 예상대로 작동하는 기능을 제공하는 것입니다. 테스트를 위해 QA 팀에 의존하는 경우 버그가 거의 즉각적으로 수정되는 대신 1-2 주 후에 수정되므로 전체 비용이 증가합니다.

스프린트가 끝날 때까지 코딩의 전부 또는 대부분이 수행되지 않으면?

왜 빨리 끝나지 않습니까? 이 주요 제한 사항은 문제의 원인이며 두 가지 접근 방식이 성공했습니다. 하나는 민첩한 접근 방식 (그러나 다른 일반적인 관행은 아님)에 잘 맞고 다른 오염은 약간 민첩합니다 (그러나 더 일반적입니다).

첫 번째는 스프린트가 끝날 때까지 코딩하지 않는다는 것입니다. 실제로 코드를 작성하는 것은 개발 과정에서 비교적 작은 부분입니다. 스프린트를 절반 쯤 마치면 QA가 업무를 수행 할 수있는 충분한 시간이 제공됩니다. 또한 문서 작성, 기술 부채 정리, 백 로그 항목 설계 등 많은 시간을 할애 할 수 있습니다. 고품질 제품을 위해해야 ​​할 다른 모든 것. 내가 본 것의 단점은 기능 과 단위 테스트를 빠르게 수행하는 것이 거의 불가능하다는 것입니다. 개인적으로, QA가 기능을 살펴보기 시작한 후에 단위 테스트를 수행하는 것이 좋다고 생각 하지만 TDD 옹호자 (및 기타)는 동의하지 않습니다.

두 번째 옵션은 QA가 PM 증오와 같은 개발 직원 뒤에서 스프린트를 운영하도록하는 것입니다. 나는 또한 이것을 싫어하는 경향이 있습니다. 릴리스에 대한 에스컬레이션 프로세스가 있더라도 스프린트 종료시 "릴리스 가능 제품"개념을 제거합니다. 더 나쁜 것은, QA가 테스트에서 질문이나 버그를 가지고 왔을 때 개발자들은 "새로운"것에 집중할 것입니다. 개발자는이 배열에서 버그를 수정하지 않을 것입니다. 그러나 제 시간에 고품질 소프트웨어를 생산하는 것을 보았습니다.

스크럼 가이드는 팀이 서로 기능을하도록 요구합니다. 모든 팀원은 개별 전문 분야에 관계없이 개발자로 간주됩니다. 실로의 개인 (코더, 테스터, qa, ux 등)은 스크럼에서 도움이되지 않습니다. 팀원은 가능한 한 서로를 도와줍니다. '항목을 qa로 전달'한다는 개념은 없습니다.

상황에 따라 추정 문제가있는 것처럼 들립니다. 제품 백 로그 항목을 추정 할 때는 모든 요구 사항 ( 예 : 코딩, 테스트, 피어 검토, 배포, 통합)을 수행해야합니다.

대략적인 경험으로, 5 ~ 15 개의 제품 백 로그 항목을 스프린트로 가져올 것으로 예상합니다. 이를 통해 각 제품 백 로그 항목의 크기를 알 수 있습니다. 또한 스프린트 내에서 작업을 '완료'할 수있는 훌륭한 기회를 제공합니다.

마지막으로, 팀의 임무는 하나의 제품 백 로그 항목을 '완료'로 옮긴 다음 다음 항목으로 이동하는 것입니다. 때때로, 이렇게하면 사람들이 서로 발가락을 밟고 있다는 것을 의미하므로 한 번에 하나 이상의 제품 백 로그를 가동하는 것이 합리적입니다. 그러나 지침은 진행중인 작업 (WIP)을 줄이고 제품 백 로그 항목을 완료로 옮기는 것이어야합니다.

테스트와 코딩은 함께 진행됩니다. 모듈별로 예약 할 수 있습니다. 모듈이 완료되면 테스터에게 제공 할 수 있습니다. 이 전체 시나리오는 작업중인 테스트 단계에 따라 다릅니다. 나선형 SDLC 모델 이 좋아 보인다. 즉, 동시 테스트와 코딩이 편리합니다. 또 다른 방법은 V model 일 수 있습니다 .

내 대답은 아마도 처음에는 아마 이상 할 것 입니다. 코드의 부작용 에 대해 테스트를 수행해야한다고 생각하기 때문에 테스트 할 시간을 찾지 못합니다 . 그리고 부작용으로 나는 컴퓨터 과학 용어를 의미합니다 .

함수 (...)는 값을 반환하는 것 외에도 (...) 외부 세계와 (...) 관찰 가능한 상호 작용이있는 경우 부작용이 있다고합니다.

"외부 세계와의 상호 작용"부분을 강조하기 위해 인용했습니다. 화면에 인쇄 될 때 UI에서 테스트하기를 원합니다 ( "[테스트 시작]]은 일반적으로 기능이 필요하기 때문에 실제로는 불가능합니다. 자동화 된 테스트를 기록하거나 작성하기위한 UI ").

다른 답변들에 따르면이 "수락 테스트"를 자동화하여 빠르게 일어날 수 있도록했습니다. 이것은 맞지만 원래 문제를 완전히 해결하지는 못합니다. 합격 시험을 작성할 시간이 충분하지 않으면 어떻게됩니까?

코드가 외부 세계와 상호 작용 한 후 즉, 무언가를 인쇄하고 입력을 기대하면 테스트에 대한 시야를 확보해야합니다. 부작용의 문제는 실제로 테스트 할 수 없다는 것입니다. 귀도 반 로섬 (Guido van Rossum)과의 인터뷰를 읽는 동안 나는 새벽에 컴퓨터를 종료한다는 진술은 그것을 실행해야만 작동 할 수 있다고 말했다.

이 "언제 스트 성 (unestability)"에 대한 해결책은, 만약 당신이 일단 진술이 효과가 있다는 것을 증명했다면, 당신은 그것을 어디에서나 사용할 수 있고 그것을 사용하여 그 일을 수행 할 수 있다는 것을 이해하는 것입니다. 함수에서 분리하고 다른 모든 것을 테스트하십시오 .

이 예제를 귀하의 질문에 더 가깝게 가져 가면 함수는 이제 전체 라이브러리 또는 프레임 워크 일 것입니다. 컴퓨터를 종료하는 대신 사용자 인터페이스가 인쇄됩니다. 응용 프로그램의 해당 부분에 들어가면 값 비싼 수락 테스트 (예 : 일종의 외부 관찰)를 통해서만 테스트 할 수 있기 때문에 호출을 최대한 멍청하고 안정적으로 유지 하십시오.

UI를 "외국 영역"으로 간주하는 것은 실제로 올바른 관점입니다. 사용자가 제공하지 않은 라이브러리의 논리를 테스트 할 필요가 없으며, 아마도 놀랍게도 현실적인 관점입니다. 예를 들어 MyWidget.draw()단일 픽셀 수준으로 호출하는 것, 예를 들어 원하는 것을 테스트 하는지 예상하십니까?

이는 수용 테스트가 중요하지 않거나 건너 뛸 수 있다는 것을 의미하지는 않습니다. 다른 답변에서 알 수 있듯이 유지하고 자동화하는 것은 엄청난 이점이 있습니다. 그러나 동일한 스프린트에서 테스트하고 코딩 할 시간을 찾으려면 가능한 한 부작용이없는 코드를 유지하십시오.