how testers are involved tdd
TDD, BDD 및 ATDD 기술 개요 :
TDD, BDD 및 ATDD는 Agile에서 테스터의 세계에 혁명을 일으켰고 추진력을 얻은 용어입니다. 테스터의 사고 방식의 변화 또한 새로운 기술을 배우고 더 중요한 것은 태도와 작업 방식을 변경해야합니다.
격리 작업과 달리 테스터는 프로그래머와 협력하고 협력해야합니다.
- 테스트 케이스 공유
- 이야기의 수용 기준 작성에 참여
- 이해 관계자에게 지속적인 피드백 제공
- 적시에 결함을 해결하기 위해 협력합니다.
- 결과물의 품질 향상을위한 제안 및 의견 제공
- 오토메이션
테스터가 이러한 관행에 참여하는 것에 대해 논의하기 전에 먼저 이러한 용어의이면에있는 개념을 이해해 보겠습니다.
학습 내용 :
테스트 주도 개발
코드를 먼저 작성한 다음 테스트하는 기존의 소프트웨어 개발 방식을 고려하십시오. 테스트 주도 개발 또는 TDD는 전통적인 개발의 정반대 인 접근 방식입니다. 이 접근 방식에서는 테스트가 먼저 수행 된 다음 코드가 작성됩니다.
혼란스러워? !!
아직 개발되지 않은 소프트웨어를 어떻게 테스트 할 수 있습니까?
예!! 이것이 바로 테스트 주도 개발 또는 TDD입니다.
TDD는 다음과 같은 경우 작은 증분으로 작동합니다.
- 테스트가 먼저 작성됩니다.
- 테스트가 실행됩니다 – 실패합니다 (분명한 이유 때문에).
- 코드는 테스트 케이스를 통과하기 위해 작성 (또는 리팩토링)됩니다.
- 테스트가 다시 실행됩니다.
- 테스트가 통과되면 다음 테스트로 이동하십시오. ELSE 코드를 다시 작성 / 수정하여 테스트를 통과하십시오.
순서도를 통해 설명하겠습니다.
이제 우리는 TDD가 테스터가하는 테스트에 대해 이야기하지 않는다는 사실을 이해해야합니다. 오히려이 접근 방식은 실제로 프로그래머가 수행하는 테스트에 대해 이야기합니다.
예!! 맞았어요 !! 단위 테스트입니다.
먼저 작성되는 테스트는 테스터가 작성하는 테스트가 아니라 프로그래머가 작성하는 단위 테스트입니다. 따라서 단계를 다음과 같이 바꾸겠습니다.
- UNIT 테스트가 먼저 작성됩니다.
- UNIT 테스트가 실행됩니다 – 실패합니다 (분명한 이유 때문에).
- 코드는 테스트를 통과하기 위해 작성 (또는 리팩토링)됩니다.
- UNIT 테스트가 다시 실행됩니다.
- 테스트가 통과되면 다음 테스트로 이동하십시오. ELSE 코드를 다시 작성 / 수정하여 테스트를 통과하십시오.
이제 여기서 제기되는 질문은 TDD가 프로그래머의 일이라면이 접근 방식에서 테스터의 역할은 무엇입니까?
글쎄요, TDD가 프로그래머의 일이라고 말했지만 테스터가 참여하지 않는다는 의미는 아닙니다. 테스터는 다음으로 구성된 테스트 시나리오를 공유하여 협업 할 수 있습니다.
제가 말하고자하는 것은 테스터는 단위 테스트 시나리오를 정의하는 데 참여하고 프로그래머와 협력하여이를 구현해야한다는 것입니다. 테스터는 테스트 결과에 대한 피드백을 제공해야합니다.
TDD를 구현하려면 테스터가 기술 세트를 업그레이드해야합니다. 그들은 더 기술적이고 분석적이고 논리적 인 기술을 향상시키는 데 집중해야합니다.
테스터는 프로그래머가 사용하는 기술 용어를 이해하기 위해 노력해야하며 가능하면 코드에 대한 조감도를 가져야합니다. 비슷한 방식으로 프로그래머는 테스터의 입장이되어 단위 테스트를보다 견고하고 견고하게 만드는보다 정교한 시나리오를 생각해 내야합니다.
프로그래머가 버그와 결함을 찾기 위해 테스터에 의존했기 때문에 단위 테스트에 큰 비중을 두지 않았고 테스터가 스스로 탐닉하기를 원하지 않는 기존의 기존 접근 방식과 달리 프로그래머와 테스터 모두 서로 입장해야합니다. 결함을 발견 한 후 업무가 끝난다고 생각하기 때문입니다.
행동 기반 개발
행동 주도 개발 또는 BDD는 테스트 주도 개발의 확장입니다.
이름에서 알 수 있듯이 BDD는 동작을 기반으로 기능을 개발하는 방법을 보여줍니다. 동작은 기본적으로 개발을 담당하는 팀의 모든 사람이 이해할 수있는 매우 간단한 언어로 예제로 설명됩니다.
BDD의 주요 기능 중 일부는 다음과 같습니다.
- 동작을 정의하는 데 사용되는 언어는 매우 간단하고 구현에 관련된 기술 및 비 기술 인력 모두가 이해할 수있는 단일 형식입니다.
- 세 명의 아미고 (프로그래머, 테스터 및 PO / BA)가 협력하고 요구 사항을 이해할 수있는 플랫폼을 제공합니다. 문서화 할 공통 템플릿을 결정합니다.
- 이 기술 / 접근법은 시스템의 최종 동작 또는 시스템 동작 방식에 대해 설명하며 시스템 설계 또는 구현 방식에 대해서는 설명하지 않습니다.
- 품질의 두 가지 측면을 강조합니다.
- 요구 사항을 충족
- 사용에 적합
왜 BDD인가?
글쎄, 우리는 결함을 고치는 것을 알고 있습니다. 곤충 개발주기의 후반 단계에서 비용이 많이 듭니다. 생산 결함을 수정하면 코드뿐만 아니라 설계 및 요구 사항에도 영향을 미칩니다. 우리가 할 때 RCA (근본 원인 분석) 대부분의 경우 결함이 실제로 이해하지 못한 요구 사항으로 귀결된다는 결론을 내립니다.
이것은 기본적으로 모든 사람이 요구 사항을 이해하는 데 다른 적성을 가지고 있기 때문에 발생합니다. 따라서 기술 및 비 기술 인력은 동일한 요구 사항을 다르게 해석 할 수 있으며 이로 인해 배송 오류가 발생할 수 있습니다. 따라서 개발 팀의 모든 사람이 동일한 요구 사항을 이해하고 동일한 방식으로 해석하는 것이 중요합니다.
우리는 전체 개발 노력이 요구 사항을 충족하는 데 집중되고 집중되도록해야합니다. 어떤 종류의 '요구 사항 – 미스'결함을 방지하기 위해 전체 개발 팀은 사용에 적합한 요구 사항을 이해하도록이를 조정해야합니다.
BDD 접근 방식을 통해 개발 팀은 다음을 수행 할 수 있습니다.
- 간단한 영어로 요구 사항을 정의하기위한 표준 접근 방식 정의
- 요구 사항을 설명하는 정의 예제 제공
- 기술 (프로그래머 / 테스터) 및 비 기술 (PO / BA / 고객)이 협력하고 함께 모이고 요구 사항을 이해하고 구현하기 위해 동일한 페이지에있을 수있는 인터페이스 / 플랫폼 제공
BDD를 구현하는 방법?
시장에서 BDD를 구현하기위한 많은 도구를 사용할 수 있습니다. 여기에 몇 가지 이름을 지정합니다.
- 오이
- 적합
- 콩 코디 언
- JBehave
- 사양 흐름
예:
예를 들어 BDD를 이해해 봅시다. 제 경우에는 Gherkin (Cucumber)을 사용하고 있습니다.
인증 된 사용자 만 XYZ 사이트에 들어가도록 허용하려는 간단한 경우를 고려하십시오.
Gherkin 파일 (기능 파일)은 다음과 같습니다.
특색: 시험 등록 포털
시나리오 개요 : 로그인 한 유효한 사용자
주어진: 고객이 등록 포털을 엽니 다.
언제: 사용자는 사용자 이름을 ''로 입력하고 암호를 ''로 입력합니다.
그때: 고객이 양식을 볼 수 있어야합니다.
예 :
| 사용자 | 암호 |
| user1 | pwd1 |
| user2 | pwd2 |
특정 요구 사항이 간단한 영어를 사용하여 문서화되는 방법을 볼 수 있습니다. 세 가지 아미고는 함께 작동하여 기능 파일을 설계 할 수 있으며 특정 테스트 데이터는 예제 섹션에 문서화 할 수 있습니다. BDD는 프로그래머, 테스터 및 비즈니스를 하나의 테이블로 가져오고 구현할 기능에 대한 공통된 이해를 확립하는 매체를 제공합니다.
BDD 접근 방식은 노력과 비용을 절약하고 고객과 개발자의 공동 작업이 기능의 전체 개발주기에 있었기 때문에 프로덕션 배포 후 결함이 있는지 확인합니다.
개발 팀은 이러한 기능 파일을 활용하고이를 실행 가능한 프로그램으로 변환하여 특정 기능을 테스트 할 수 있습니다.
어떻게?
글쎄, 당신은 그것을 위해 오이 / Fitnesse를 배워야합니다!
수용 테스트 주도 개발
Acceptance Test Driven Development 또는 ATDD는 구현이 실제로 시작되기 전에 전체 팀이 협력하여 서사시 / 스토리의 수용 기준을 정의하는 기술입니다. 이러한 승인 테스트는 적절한 예와 기타 필요한 정보로 뒷받침됩니다.
대부분의 경우 BDD와 ATDD는 같은 의미로 사용됩니다. ATDD 접근 방식은 BDD 접근 방식에서 기능을 작성하는 방식과 마찬가지로 Given-When-Then 형식을 사용하여 구현할 수도 있습니다.
세 가지 접근 방식의 차이점을 간단히 요약 해 보겠습니다.
- TDD는보다 기술적이며 기능이 구현 된 것과 동일한 언어로 작성됩니다. 기능이 Java로 구현되면 JUnit을 작성합니다. 테스트 케이스 . BDD & ATDD는 간단한 영어로 작성되었습니다.
- TDD 접근 방식은 기능 구현에 중점을 둡니다. BDD는 기능의 동작에 초점을 맞추고 ATDD는 요구 사항 캡처에 초점을 맞 춥니 다.
- TDD를 구현하려면 기술 지식이 필요합니다. 반면 BDD 및 ATDD는 기술적 지식이 필요하지 않습니다. BDD / ATDD의 장점은 기술적 인 사람은 물론 비 기술적 인 사람이 기능 개발에 참여할 수 있다는 사실에 있습니다.
- TDD는 발전했기 때문에 좋은 디자인의 범위를 제공하고 품질의 '요구 사항 충족'측면에 초점을 맞 춥니 다. 반면 BDD / ATDD는 2에 중점을 둡니다.nd'사용에 적합'이라는 품질 측면
이러한 모든 기술은 기본적으로 전통적인 개발 방법론에서 사용되는 '테스트-마지막'접근 방식과 달리 '테스트-우선'접근 방식에 대해 이야기합니다.
테스트가 먼저 작성되므로 테스터는 매우 중요한 역할을합니다. 테스터는 방대한 도메인과 비즈니스 지식을 보유해야 할뿐만 아니라 3 명의 아미고 스 토론 중에 브레인 스토밍에 가치를 더할 수 있도록 우수한 기술 능력도 보유해야합니다.
CI (Continuous Integration) 및 CD (Continuous Delivery)와 같은 개념을 통해 테스터는 프로그래머와 잘 협력하고 개발 및 운영 영역에 동등하게 기여해야합니다.
Windows 7 64 비트를위한 최고의 방화벽
Agile의 유명한 Test Pyramid와 함께이 토론을 요약하겠습니다.
이 피라미드의 가장 낮은 레이어는 단위 테스트 레이어로 구성됩니다. 이 레이어는 기초 레이어입니다. 따라서이 층이 단단하다는 것은 제 국적입니다. 대부분의 테스트는이 계층으로 푸시되어야합니다. 이 최하위 계층은 TDD에만 집중합니다.
에서 기민한 세계에서는이 피라미드 층을 더 강하고 견고하게 만드는 데 중점을두고 있으며 대부분의 테스트가이 층에서 이루어짐이 강조됩니다.
이 피라미드 레이어에서 사용되는 도구는 모두 Xunit 도구입니다.
피라미드의 중간 계층은 서비스 계층이며 서비스 수준 테스트를 설명합니다. 이 계층은 응용 프로그램 사용자 인터페이스와 하위 수준 단위 / 구성 요소 간의 다리 역할을합니다. 이 계층은 대부분 UI의 요청을 수락하고 응답을 다시 보내는 API로 구성됩니다. BDD 및 TTDD 접근 방식은이 피라미드 계층에서 활성화됩니다.
피라미드의 중간 계층에 사용되는 도구는 다음과 같습니다. Fitnesse, Cucumber 및 Robot Framework .
피라미드의 최상위 레이어는 실제 UI로,이 레이어에는 최소한의 테스트가 포함되어야합니다. 또는이 특정 레이어의 테스트 노력은 최소화되어야합니다. 대부분의 기능 테스트는 피라미드의 최상층에 도달했을 때 완료되어야합니다.
최상위 레이어에서 사용되는 도구는 다음과 같습니다. 셀렌 , QTP 및 RFT.
우리는 작은 단위로 작업하기 때문에 스크럼 (스프린트라고 함) 이러한 모든 접근 방식을 수동으로 구현하는 것은 불가능합니다. 이러한 접근 방식에는 자동화 된 개입이 필요합니다. 이 경우 자동화는 매우 중요합니다.
실제로 이러한 접근 방식은 실제로 자동화를 통해 실행됩니다. 모든 스프린트가 끝날 때마다 새로운 기능이 추가되고 있으므로 이전에 구현 된 기능이 예상대로 작동하는 것이 중요해집니다. 그 후, 오토메이션 여기서 HERO가됩니다.
결론
기사가 끝날 때까지 테스터가 TDD, BDD 및 ATDD 기술에 참여하는 방법에 대해 배웠을 것입니다.
시리즈의 세 번째 부분에서는 애자일 세계의 자동화에 대해 논의 할 것입니다.
저자 정보 : 이 기사는 STH 작성자 Shilpa가 작성했습니다. 그녀는 인터넷 광고, 투자 은행 및 통신과 같은 도메인에서 지난 10 년 이상 소프트웨어 테스트 분야에서 일하고 있습니다.
더 많은 업데이트를 위해이 공간을 계속 지켜보십시오.
추천 도서
- TDD 대 BDD-예제를 통한 차이점 분석
- 소프트웨어 테스터에서 동기 부여를 유지하는 방법은 무엇입니까?
- 테스터를위한 소프트 스킬 : 커뮤니케이션 스킬을 향상시키는 방법
- 쓰기 및 적립-숙련 된 QA 테스터를위한 프로그램
- 개발자는 좋은 테스터가 아닙니다. 뭐라고?
- 초보자 테스터를위한 소프트웨어 테스트 조언
- 테스터에게 도메인 지식이 얼마나 중요한가요?
- 글로벌 소프트웨어 테스팅 사업, 곧 288 억 달러에 도달