스크럼 팀을 위한 테스트 전략에 대한 모범 사례

스크럼 빼기 테스트 계획은 스테로이드에 대한 POC와 같습니다.

오늘날 대부분의 성공적인 프로젝트는 개념 증명(POC)으로 시작합니다. 개념 증명(POC)은 아이디어에 대한 상대적으로 작은 규모의 평가입니다. 여기에서 선택한 기술과 기능 팩이 먼저 검증되고 비즈니스 사용자에게 잠재적인 영향이 있는지 평가된 다음 일단 입증됩니다. 투자할 가치가 있는 완전한 규모의 프로젝트 팀이 모든 기능을 갖춘 제품을 설계 및 제공하고 프로덕션에 배포하도록 지정됩니다.

이것은 스크럼 팀에게 완벽한 사례입니다. 팀은 각 스프린트마다 상당한 새 기능을 추가하여 프로토타입을 신속하게 개발할 수 있으며, 비즈니스 사용자는 실시간으로 빠른 진행 상황과 약 10개의 스프린트 내에서 아이디어가 처음부터 어떻게 구축되는지 확인할 수 있습니다. 그것은 강한 인상을 남기지만(어쨌든 POC의 주요 대상임) 하나의 중요한 속성도 가지고 있습니다. 테스트 활동이 최소화되거나 전혀 없으며 테스트 프로세스에 대해 생각하는 것조차 농담이 될 것입니다.

스크럼 팀 내부에서 그것은 재미있는 활동이 아니며 사람들은 속도를 늦추는 프로세스 없이 개발한다는 아이디어를 대부분 좋아할 것입니다. 이것은 기본적으로 모든 테스트 활동이 암묵적으로 수행하는 것입니다. 그리고 최종 사용자에게 가장 깊은 인상을 주어야 하는 시간 동안 불필요한 속도 저하를 원하는 사람은 누구입니까?

POC 기간이 끝난 후 프로젝트 팀이 같은 방식으로 계속되면 발생하는 상태는 내가 POC를 스테로이드 로 부르는 데 사용하는 것입니다. 생산 시스템의 크기와 기능이 성장하지만 여전히 POC처럼 작동합니다. 숨겨진 결함과 탐색되지 않은 코너 케이스, 심각한 충돌만 기다리고 있습니다.

그러나 거기에서 변환하기 전에 롤링 문제를 해결하는 것이 더 복잡해지기 때문에 팀은 안정적인 릴리스를 따라가는 스프린트에서 스프린트로 더 힘든 시간을 보낼 것입니다.

다음은 유사한 문제를 다룰 때 작동하는 것으로 입증된 몇 가지 기술이며 개발 진행을 너무 복잡하게 만들지 않으면서 견고한 테스트 프로세스를 구현하기 위한 모범 사례로 명명될 수 있다고 생각합니다. 왜냐하면 우리 모두가 원하는 것이기 때문입니다. 스크럼 팀.

고통을 분산

고통을 나누는 것보다 불필요한 귀찮음을 다룰 때 어디에서 시작해야 할까요 :).

이것이 의미하는 바는 여기저기서 개발자의 약간의 추가 활동이 필요하지만 시간이 지남에 따라 점진적이지만 지속적으로 공통 목표에 크게 기여할 계획을 세우는 것입니다.

#1. 새로 생성된 각 코드 조각에 대한 단위 테스트 코드 개발

스크럼 팀이 스프린트 내에서 생성된 각각의 새 코드에 대한 단위 테스트의 정의 완료 절 개발을 추가하도록 설득할 수 있다면 장기적인 관점에서 이것은 큰 성과가 될 것입니다.

그 이유는 매우 분명합니다.

개발자는 코드의 다양한 비표준 경로에 대해 생각해야 합니다. –

• 이러한 단위 테스트는 자동화된 DevOps 파이프라인에 연결되고 개발 또는 테스트 환경에 대한 모든 단일 배포에서 실행될 수 있습니다. 또한 파이프라인의 메트릭을 쉽게 내보낸 다음 소스 코드에 직접 바인딩된 테스트 사례의 백분율 적용 범위를 비즈니스 사용자에게 시연하는 데 사용할 수 있습니다.

가장 중요한 것은 빨리 시작하는 것입니다. 단위 테스트가 늦게 개발되기 시작할수록 개발자가 스프린트 내에 추가하는 것이 더 산만해집니다.

• 기존 코드에 대한 단위 테스트를 역방향으로 개발하려면 상당한 노력이 필요합니다. 코드의 일부는 다른 개발자가 만들 수 있으며 모든 단일 코드 부분에서 어떻게 작동해야 하는지에 대한 정확한 지식은 현재 개발자에게 명확하지 않습니다. 어떤 경우에는 수정된 코드에 단위 테스트를 추가하는 것이 스프린트(확실히 스프린트 계획 중에 아무도 계산하지 않은 상태)에 대한 기능 변경을 개발하는 것보다 더 많은 시간이 걸릴 수 있습니다.

#2. 개발 환경에서 단위 테스트의 모든 부분을 실행하는 루틴 만들기

새 코드를 Master 브랜치로 병합하기 위한 풀 리퀘스트를 생성하기 전에도 개발 환경에서 기능 코드와 단위 테스트 코드를 모두 테스트하는 것이 표준 활동일 것입니다. 이렇게 하면 다음이 보장됩니다.

• 단위 테스트 코드는 실제로 각 부분에서 작동합니다(결국 확인해야 하는 또 다른 코드일 뿐입니다). 이 단계는 매우 자주 완전히 건너뜁니다. 어쨌든 단위 테스트가 DevOps 파이프라인에 연결되어 있으면 결국 기본적으로 어딘가에서 실행되고 테스트될 것이라고 가정합니다. 그러나 이것은 팀이 모든 커밋된 스토리를 완료하는 데 일반적으로 더 적은 시간과 더 많은 스트레스를 받는 상위 수준의 스프린트 활동으로 문제를 밀어 넣는 것에 지나지 않습니다.
• 새 기능 코드는 기본 기능에 대해 개발자가 테스트합니다. 분명히 이 테스트에서 비즈니스 기능이 완전히 검증될 것이라고 기대할 수는 없지만 적어도 이 테스트는 코드가 개발자가 의도한 방식으로 작동한다는 것을 확인할 것입니다(현재로서는 비즈니스 로직이 개발하는 동안 잘못 이해).

#삼. 마스터 분기에 코드 병합 후 단위 테스트 실행 예상

로컬 브랜치(브랜치 소유자 외에는 아무도 새 기능을 개발하지 않음)에 기능 코드가 있는 것과 풀 리퀘스트 후에 동일한 코드가 작동하고 마스터 브랜치로 병합되는 것은 완전히 다른 것입니다.

마스터 브랜치에는 다른 스크럼 팀 구성원의 변경 사항이 포함되어 있으며 충돌이 해결되고 모든 것이 괜찮아 보이더라도 병합 및 충돌 해결 후의 코드는 기본적으로 여전히 테스트되지 않은 코드 조각이며 먼저 확인하지 않고 추가로 보내는 것은 위험합니다. 여전히 잘 작동합니다.

따라서 여기에서 효과적인 것으로 입증된 것은 이전에 개발 환경에서 이미 수행된 동일한 단위 테스트를 마스터 분기 코드 버전에서 빌드된 환경에서도 실행하도록 요청하는 것입니다.

개발자에게는 삶에 포함시켜야 할 추가 단계일 수 있지만, 이 경우에는 새로운 것을 발명해서는 안 되며 이미 한 번 수행한 작업을 다시 실행하기만 하면 되기 때문에 그렇게 많은 노력이 필요한 것은 아닙니다.

이제 이 단계는 특정 경우에 건너뛸 수 있습니다.

• DevOps 파이프라인의 자동화된 단위 테스트는 매우 포괄적이어서 그 위에서 실행되는 전체 수동 테스트를 이미 다루고 있습니다.

이 상태를 달성하는 것은 확실히 가능하지만 실생활에서 그런 상태를 경험한 적이 없습니다. 개발자가 이렇게 상세하고 자동화된 단위 테스트를 만드는 데 너무 많은 시간이 소요될 수 있습니다. 제품 소유자가 팀이 이 활동에 너무 많은 시간을 할애하도록 허용하는 것은 스프린트 내에서 전달되는 스토리 수에 명시적인 영향을 미치기 때문에 쉽게 용납되지 않을 수 있습니다.

그러나 스프린트 콘텐츠에 대한 선호도는 단위 테스트를 수행하지 않거나 최소화하는 데 대한 변명이 될 수 없습니다. 이렇게 함으로써 팀은 코드가 너무 많은 단위 테스트 범위가 부족한 상태로 다시 전환할 것이고, 그 다음 만회를 위해 이미 너무 늦을 수 있습니다(다시 말하지만, 단위 테스트 완료에 대한 노력이 실제 스프린트에 대한 코드 변경).

이러한 모든 이유로 망설임 없이 마스터 코드 버전에서 단위 테스트를 다시 실행하는 것이 좋습니다. 그것이 가져다 줄 가치에 비해 너무 적은 노력입니다.

릴리스 테스트 단계를 위한 마스터 브랜치의 준비 상태에 대한 최종 확인을 수행합니다. 또한 대부분의 기술적 버그(예: 성공적으로 종료될 때까지 소스 코드가 성공적으로 실행되지 않는 버그)를 찾는 데 도움이 되며 다음 단계는 비즈니스 기능 검증에만 집중할 수 있습니다.

기능 테스트 준비

이전의 모든 테스트 활동은 하나의 특정 결론으로 ​​이어집니다. 즉, 마스터 분기 코드에는 기술적 버그가 없으며 종단 간 기능 흐름에 대한 문제 없이 실행 가능합니다.

이것은 한 사람이면 쉽게 다룰 수 있는 단계이며, 이 사람은 기술적 배경이 없어도 됩니다.

실제로 개발자와 연결이 끊어진 사람이 실행하지만 비즈니스 사용자가 코드의 동작을 기대하는 기능을 기능적으로 인식하는 경우 훨씬 더 좋습니다. 완료해야 할 두 가지 주요 활동이 있습니다.

#1. 기능 테스트를 대상으로 하는 새로운 스프린트 스토리

각 스프린트는 이전에는 존재하지 않았던 몇 가지 새로운 기능(스프린트 목표 증분)을 이상적으로 가져와 검증해야 합니다. 비즈니스 사용자가 적어도 마지막 스프린트 전체를 기대하고 있었기 때문에 비즈니스 사용자가 지금 가지고 있는 것에 만족할 정도로 새로운 소프트웨어가 작동하는지 확인하는 것이 중요합니다 :).

(오랫동안) 약속된 기능이 마침내 출시될 것이라고 발표했는데, 다른 날 실제로 제대로 작동하지 않는다는 것을 알게 된 것은 정말 슬픈 경험입니다.

따라서 새로운 스프린트 기능을 제대로 테스트하는 것이 중요합니다. 이를 성공시키기 위해서는 중요한 테스트 사례를 사전에 관련 이해 관계자(제품 소유자 또는 최종 사용자)로부터 수집하고 내부 콘텐츠에 필요한 모든 테스트 사례 목록을 작성하는 것이 좋습니다. 스프린트.

언뜻 보기에는 압도적으로 보일 수 있지만 내 경험에 비추어 볼 때 역시 한 사람이 완전히 관리할 수 있습니다. 스프린트는 대부분 매우 짧기 때문에(예: 2주 짧은 기간) 스프린트에는 기술적 부채 이야기, 문서화, 디자인/스파이크 이야기 등과 같은 추가 활동도 포함되어 있으므로 어쨌든 새로운 콘텐츠가 너무 많지는 않습니다.

그런 다음 원하는 기능을 가장 먼저 확인하기 위해 테스트 케이스를 실행합니다. 결과에 문제가 발생하면 해당 개발자(이 특정 결함과 관련된 변경 사항을 소유한 사람)에게만 접근하여 문제를 신속하게 해결하기를 바랍니다.

이러한 방식으로 개발자는 기능 테스트와 관련된 최소한의 시간을 보내고 여전히 가장 좋아하는 활동에 집중할 수 있습니다.

#2. 회귀 테스트 케이스 실행

기능 테스트의 다른 부분은 지금까지 작동했던 모든 것이 다음 릴리스 이후에도 작동하는지 확인하는 것입니다. 이것이 회귀 테스트의 목적입니다.

회귀 테스트를 위한 테스트 사례는 각 릴리스 전에 정기적으로 유지 관리하고 다시 방문하는 경우 가장 좋습니다. 구체적인 프로젝트 세부 사항을 기반으로 단순하게 유지하되 전체 시스템을 통해 실행되는 대부분의 핵심 기능과 중요한 종단 간 흐름을 포함하는 것이 가장 좋습니다.

일반적으로 각 시스템에는 다양한 영역에 영향을 미치는 프로세스가 있으며 이러한 프로세스는 회귀 테스트 사례에 가장 적합한 후보입니다.

경우에 따라 회귀 테스트는 예를 들어 스프린트의 새로운 스토리가 기존 흐름의 특정 부분을 변경하는 경우 스프린트의 새로운 기능도 암묵적으로 다루고 있습니다.

따라서 대부분의 경우 새로운 스프린트 스토리 기능 테스트와 함께 회귀 테스트를 완료하는 것은 전혀 복잡하지 않습니다. 특히 각 프로덕션 릴리스 전에 정기적으로 수행되고 프로덕션 릴리스의 주기성이 너무 작지 않은 경우 더욱 그렇습니다.

모든 프로덕션 릴리스 전에 품질 보증 테스트 실행을 주장합니다.

QA(Quality Assurance) 테스트는 프로덕션에 출시하기 전 마지막 단계이며 종종 이 테스트가 중요하지 않아 건너뜁니다. 특히 스크럼 팀이 새로운 콘텐츠에 대해 공격적으로 관리되는 경우.

비즈니스 사용자조차도 새로운 기능에 관심이 있다고 말하지만 기능을 유지하거나 결함 수를 낮추는 데는 그다지 관심이 없습니다. 하지만 시간이 지남에 따라 개발 팀이 결국 속도를 늦추어야 하는 주된 이유이며 비즈니스 사용자는 어쨌든 원하는 것을 얻지 못할 것입니다.

QA 테스트는 Scrum 팀 외부의 사람들, 이상적으로는 가능한 한 향후 프로덕션에 가까운 전용 환경에서 비즈니스 사용자가 직접 실행해야 합니다. 또는 여기에서 제품 소유자가 최종 사용자를 대신할 수 있습니다.

어쨌든 이 테스트는 개발 스크럼 팀과 연결되지 않고 최종 사용자의 관점에서 깨끗하고 기능적인 테스트여야 합니다. 제품에 대한 하나의 최종 보기를 제공하고 스크럼 팀의 누구도 예상하지 못한 방식으로 사용될 것입니다(이상적인 경우는 아니지만 확실히 일어날 수 있음). 막바지 수정을 위한 시간이 아직 남아 있습니다.

또는 스크럼 팀이 기대치를 잘 이해하지 못했다는 것이 분명해질 수 있으며, 이 경우 적어도 실제 프로덕션 릴리스가 출시되기 훨씬 전에 후속 계획에 동의할 수 있습니다. 이것은 다시 이상적인 경우는 아니지만 성공적인 프로덕션 릴리스를 보고한 직후 실패를 인정하는 것과 훨씬 더 낫습니다.

여기에서 다음으로 어디로 가야합니까?

일상적인 스크럼 작업에 이러한 관행을 적용하면 생산 릴리스를 지연시키거나 전체 스프린트를 다음 릴리스를 준비하는 데 소비하지 않고 스크럼 팀의 모든 사람이 원하지 않는 일을 하도록 강요하지 않고도 보다 안정적이고 예측 가능한 스프린트 릴리스 습관을 진지하게 가져올 수 있습니다. 스프린트의 대부분을 어쨌든 효과적으로 수행하는 방법을 좋아하지 않거나 모릅니다.

하지만 여기서 멈출 필요는 없습니다.

성능 테스트 포함은 여기에서 언급할 하나의 주제입니다. 그것들은 종종 무시되거나 불필요한 것으로 간주되어 "스크럼 활동 최적화"의 첫 번째 라운드에서 긁어냅니다. 그러나 정기적으로 성능을 확인하지 않으면 생산 시스템이 시간이 지남에 따라 어떻게 발전할 수 있는지에 대해 항상 의심했습니다.

한 단계 위로 올라가는 것은 자동화된 테스트의 도입을 의미하기도 합니다.

이미 한 그룹의 자동화된 테스트(파이프라인의 단위 테스트)를 다루었습니다. 그러나 테스트 환경에 배포할 때마다 완전히 자동화되고 자체적으로 실행되는 전체 종단 간 회귀 테스트를 개발할 수 있습니다. 이것은 개발 스크럼 팀을 훨씬 더 자유롭게 할 수 있지만 이러한 자동화된 테스트를 개발하고 유지 관리하기 위한 전담 팀이 필요합니다. 프로덕션 코드가 변경될 때마다 일부 기존 자동화 테스트가 무효화될 수 있으므로 파이프라인에서 계속 작업하려면 업데이트해야 하므로 지속적인 작업이 됩니다. 소수만이 기꺼이 비용을 지불하는 노력이지만 개발 스크럼 팀의 이점은 클 것입니다.

이는 이 기사의 범위를 훨씬 넘어서는 주제이며 여기에 언급된 각 테스트 유형에 대한 올바른 일정과 타이밍을 파악하여 스프린트 기간 내에서 수행할 수 있도록 합니다. 다음에 기꺼이 다이빙하겠습니다!