이전 주제에 대한 새로운 설명: 애자일 테스트란 정확히 무엇입니까?

7년 전 (2013년) InfoQ에 같은 제목의 기사가 실렸지만 이 기사는 완전히 새로운 것입니다 . "애자일 테스팅이 정확히 무엇인지"에 답하기 전에 질문을 하나 드리겠습니다. 애자일 개발을 이해하고 있습니까?

이해가 안된다면 먼저 애자일을 이해해야 하는데, 예를 들어 스크럼이 더 이상 스크럼이 아닌 스크럼이 스크럼이 되기 전에 쓴 글을 읽어보면 애자일을 이해하는 데 도움이 될 수 있습니다. 애자일을 이해하려면 agilemanifesto.org로 이동하여 유명한 애자일 선언문과 애자일 개발의 12가지 원칙을 주의 깊게 읽는 것이 더 중요합니다.

생각하면서 아래에서 말씀드릴 사례를 들어보세요.듣는 과정에서 사례를 검토하여 어떤 것이 애자일 가치에 부합하는지, 어떤 것이 애자일 개발 원칙에 위배되는지 판단할 수 있습니다.마지막으로 사례를 분석해 보겠습니다. 그리고 "애자일 테스팅이 정확히 무엇인지"라고 대답하세요.

* 기존 테스팅에서 애자일 테스팅으로 전환한 사례 *

이번 사례는 안드로이드 기반 스마트단말기 위주로 제품을 생산하는 국내 업체에서 나왔다. 이 이야기는 6년 전인 2013년에 회사의 소프트웨어 R&D 부서가 일련의 애자일 테스트 지향 시도를 시작했을 때 일어났습니다 .

먼저 사건의 배경을 소개하겠습니다 .회사의 소프트웨어 R&D 부서는 4개의 개발 부서와 거대한 테스트 부서가 있으며, 그 중 다양한 R&D 도구 개발을 담당하는 부서도 테스트 부서에 소속되어 있습니다. 개발자와 테스터의 비율은 거의 1:1이며 개발 부서의 책임은 담당 기능 모듈에 따라 나뉘며 테스트 부서는 기능 테스트, 성능 테스트, 보안을 포함한 소프트웨어 시스템 수준의 모든 테스트를 담당합니다. 테스트, 신뢰성 테스트, 호환성 테스트 등 당시에는 전통적인 폭포수 개발 모델, 즉 V 모델이 채택되었고 코드 작성과 제품 테스트는 두 단계로 명확하게 구분되었습니다.

지속적인 통합 시도

여기에서 사용되는 도구는 다음과 같습니다. 분산 코드 버전 제어 도구 Git + 코드 검토 도구 Gerrit + 지속적 통합 도구 Jenkins + Monkey Runner 기반의 자체 개발 자동 테스트 프레임워크. Git + Gerrit + Jenkins를 기반으로 개발부는 코드의 자동 구성을 실현했습니다.

원하는 목표는 코드 제출 후 자동 빌드, 자동 배포 및 자동 테스트를 완료하고 테스트 보고서를 자동으로 생성하는 것입니다. 구현 과정에서 툴 체인에 문제가 없고 자동 구성 및 자동 배포에 문제가 없으며 문제는 자동화된 테스트에 있습니다.

제품에 대한 수동 테스트 케이스는 1,000개 정도인데 자동 스크립트로 변환하여 통합 환경에서 장기간 실행할 수 있는 테스트 케이스는 100개가 넘고, 버전 검증만 구현하는데, 우리가 평소에 "스모크 테스트"를 호출합니다. 이것은 개발자가 코드를 제출할 때 트리거된 자동화 테스트의 범위가 매우 제한적이라는 것을 의미하며, 통합 환경이 지속적인 검증을 지원할 수 있어도 모두가 매우 맛이 없다고 느낍니다.

Test-forward 및 조직적 시도

당시 테스트 포워드의 정의는 개발이 끝날 때까지 기다렸다가 테스트를 시작하는 것이 아니라 소프트웨어 코딩 단계에서 테스트하는 것이었습니다. 간단히 말해서 이를 통해 제품 개발 주기가 단축되기를 바라면서 개발하면서 테스트하는 것 입니다 .

(1) 첫 단계

개발 부서는 Scrum Team에 따라 나뉘며 테스트 엔지니어는 3:1의 비율로 채용됩니다. 처음에는 어떤 종류의 테스터가 필요한지 이해하고 싶지 않았기 때문에 모집은 기본적으로 수동 테스트였으며 대부분 코드를 이해하지 못했습니다.

스크럼 팀의 주요 업무는 다음과 같습니다 : 수동 테스트, 개발 요구 사항에 따라 버그를 반복해서 재생산, 새 버전의 터미널 업데이트와 같은 개발자를 위한 집안일 수행, 개발에서 확인하려는 하드웨어 모델 찾기, 곧. 프로젝트 초기 단계에서 제품 하드웨어가 제자리에 없거나 소프트웨어 통합이 함께 작동하지 않으면 수동 테스트를 수행할 수 없습니다.

(2) 두 번째 단계

리더들은 당초 애자일 모델이 테스터 수를 줄일 수 있기를 바랐지만 예상과 달리 시스템 테스트를 담당하는 테스트 부서의 인원은 줄어들지 않고 개발 부서 내에서 수십 명의 테스터가 추가되었습니다. 그 이유는 두 그룹의 사람들이 사용하는 테스트 방법이 비슷하기 때문입니다. 사람이 많을수록 단순히 보고된 버그가 더 많다는 사실에 반영됩니다. 요구 사항 및 인원 수를 줄일 수 없습니다.

이에 리더는 개편 과정에서 모든 테스터를 테스트 부서로 옮기겠다고 발표하고 해당 테스트 아웃소싱 금액을 줄이도록 테스트 부서에 요청했습니다. 스크럼 팀은 테스트 부서에 3:1의 비율로 테스터를 갖추도록 요청할 수 있습니다. 테스트 부서는 스크럼 팀의 테스트 범위를 이해할 수 있어 반복 테스트를 줄일 수 있습니다. 개편 후 인원은 줄었지만 여전히 수동 테스팅이 주를 이루고 있으며, 조직 구조의 변화로 인해 개발 단계에서 테스팅에 대한 최종 결정권을 두고 개발과 테스팅이 자주 다투고 있습니다. 와 테스트가 더욱 뚜렷해졌고 관계가 더욱 긴장되었습니다 .

(3) 세 번째 단계

일정 기간 운영 후, 이것이 불가능하고 애자일 팀의 특성에 부합하지 않는다고 느꼈기 때문에 개발 단계에서 테스트를 담당하는 인력을 개발 부서로 이관하기로 결정했습니다. 좋은 변화는 다음과 같습니다. 각 스크럼 팀은 테스트 전략 및 테스트 계획을 공식화하고 개발 테스트와 시스템 테스트 간의 조정을 담당하는 테스트 소유자로서 선임 테스트 엔지니어로 시작합니다. 개발 부서도 개발 단계에서 테스트 엔지니어의 개발 역량을 교육하기 시작했습니다.

단위 테스트 시도

처음에는 단위 테스트의 커버리지 비율이 거의 0에 가까웠고 개발자는 코드를 작성하고 테스터가 제출한 결함을 수정했습니다. 지속적 통합 및 테스트 포워딩의 실패로 인해 개발 부서는 개발자에게 단위 테스트를 수행하도록 요구하고 코드 커버리지로 단위 테스트 결과를 측정해야 한다고 모두가 생각합니다. 개발도 그렇게 하겠다고 약속했지만 1년 동안 효과가 없었습니다.그 이유는 바쁘고 단위 테스트에 대한 경험과 기술이 없기 때문입니다 .

용량 갱신 테스트 시도

테스트 부서는 자동화의 중요성을 인식하고 있지만 해당 부서의 엔지니어 중 5%만이 자동화된 테스트를 담당하고 있습니다. 애플리케이션 레이어를 적용한 후 회사는 수동 테스트 엔지니어의 10%를 최종 제거 시스템으로 교체하기로 합의했습니다. 내부 이동, 외부 채용, 직원 교육 등 다양한 방법을 통해 자동화 테스트 엔지니어의 비율은 1년 만에 마침내 25%에 도달했습니다. 팀은 통합된 자동화 테스트 프레임워크를 구축하기 시작했습니다. API 및 UI 테스트에서 자동화된 테스트의 커버리지 비율은 마침내 크게 증가했지만 전체 요구 사항 커버리지 비율은 30%를 초과하지 않았으며 단위 테스트의 부족은 여전히 결함입니다. 개발자의 참여 없이 테스트는 항상 UI 레이어 Tossing은 물론 절반의 노력으로 두 배의 결과를 얻고 있습니다.

이 사례를 보면 전통적인 테스팅에서 애자일 테스팅으로 변모하는 과정에서 이 회사의 R&D 부서는 진짜 애자일 테스팅이 무엇인지도 모르고 돌멩이를 느끼며 강을 건너고 계속 노력했다는 것을 알 수 있다. 어렵고 우회도 많이 했다.결국 아직 애자일 테스팅의 반대편에는 도달하지 못했고, 말할 것도 없이 제품의 품질과 테스팅의 효율성이 크게 향상되었다.

* 애자일 테스트란 무엇입니까? *

그렇다면 애자일 테스트란 정확히 무엇일까요? 확실한 것은 "애자일 테스트"는 테스트 방법도 테스트 방법도 아니지만 애자일 개발에 적응하도록 특별히 설계된 완전한 소프트웨어 테스트 솔루션 세트라는 것입니다 . 이 솔루션은 필요한 올바른 값, 사고 방식, 테스트 프로세스, 일련의 우수한 테스트 사례 및 보다 적합한 테스트 환경, 자동화된 테스트 프레임워크 및 도구를 포함하여 지속적인 제공을 지원할 수 있어야 합니다 . 애자일 테스팅은 기존의 다양한 테스팅 방법과 방법을 채택할 수 있으며 강조점은 전통적인 테스팅과 다르지만 주요 차이점은 가치, 테스팅 사고, 프로세스 및 관행 등입니다.

애자일 테스팅은 "애자일 선언문"이 옹호하는 가치를 가져야 하므로 "애자일 선언문"의 형식에 따라 다음과 같은 "애자일 테스트 선언문"을 작성할 수 있습니다.

애자일 테스트는 "개발과의 협업", "자동 테스트", "고객 사고" 및 "동적 테스트 전략 조정"이 더 중요하다고 강조합니다.

그런 다음 돌아가서 위의 사례를 살펴보겠습니다. 적어도 1과 2는 그렇지 않았습니다. 테스터는 충분한 관심과 존경을 받지 못했고 개발 및 테스트 협업이 충분하지 않았지만 다음과 같습니다.

한동안 별도의 테스트 부서가 있었는데 "개발과 테스트가 더 뚜렷해졌고 관계가 더 긴장되었습니다"
"개발자의 참여가 없으면 테스트는 항상 UI 레이어에서 던지는 것입니다. 물론 노력의 절반입니다."
"트리거된 자동 테스트는 매우 제한된 적용 범위를 달성합니다."
......

트랜스포메이션 초기에는 관련 테스터의 교육이 강화되지 않았고 테스터에 대한 애자일 모드의 요구 사항도 알려지지 않았으며 모집된 테스터는 자격이 없었습니다. 구현 과정에서 테스트 전략이 부족하고 고객의 요구 사항에서 시작하여 테스트 전략을 동적으로 조정하는 데 중점을 두지 않습니다.

애자일 개발에는 여전히 12가지 원칙이 있습니다. 위 사례의 팀이 이를 하나씩, 그리고 목표에 맞게 따랐나요? 애자일 개발의 12가지 원칙이 테스트에 대해 이야기하는 것 같지는 않지만 테스트는 전체 소프트웨어 개발의 일부이므로 이러한 원칙을 준수하고 다음과 같은 애자일 개발의 기본 요구 사항에 적응하는 것이 당연합니다.

"가치 있는 소프트웨어의 지속적이고 빠른 제공"을 지원하거나 지원하는 방법은 무엇입니까?
변화를 수용하는 방법 - "개발 후반에도 변화하는 요구 사항에 쉽게 대처할 수 있습니다."
......

이러한 원칙을 고수해야만 애자일 개발에 적응할 수 있는 올바른 자세를 얻을 수 있으며, 테스트 주도 개발과 같은 애자일 개발의 우수 사례를 채택하고 개발과 긴밀히 협력해야만 테스트가 "걸림돌"이 되지 않을 것입니다. 민첩한 개발의.

애자일 개발의 12가지 원칙을 바탕으로 다음과 같은 애자일 테스팅의 8가지 원칙을 개발했습니다.

이러한 원칙은 "Efficient Agile Testing" 칼럼의 후속 콘텐츠 에서 자세히 설명합니다 .

참고: