애자일과 같은 개발에서 누가 시험 사례를 작성해야합니까? [닫은

https://stackoverflow.com/questions/194790

10-07-2019
|

문제

우리 팀에는 각 개발자에게 할당 된 작은 증분 작업을 게시하는 작업 시스템이 있습니다.

각 작업은 자체 지점에서 개발 된 다음 각 지점은 트렁크에 병합되기 전에 테스트됩니다.

내 질문은 : 일단 작업이 완료되면 누가 테스트 사례 이 작업에 대해 수행해야합니까?

이상적으로 나는 그 과제의 개발자가 그 일에 가장 적합하다고 생각하지만, 시간 낭비라고 생각하거나 단순히 그것을 좋아하지 않는 개발자들로부터 많은 저항력을 가지고있었습니다.

내가 QA 사람들이 그렇게하는 것을 좋아하지 않는 이유는 내가 자신의 작품을 만드는 아이디어가 마음에 들지 않기 때문입니다. 예를 들어, 그들은 단순히 테스트하기에는 너무 많은 일을 남기지 않을 수 있으며 필요한 기술적 세부 사항을 알지 못할 수 있습니다.

그러나 마찬가지로, 테스트 사례를 수행하는 개발자의 아래쪽 부분은 그들이 깨질 것이라고 생각하는 것들을 남기지 않을 수 있다는 것입니다. (심지어 무의식적으로도)

프로젝트 관리자로서, 나는 각 과제에 대한 테스트 사례를 직접 작성했지만 시간이 세금이 부과되고 이것을 변경하고 싶습니다.

제안?

편집 : 테스트 사례라면 트렁크에 병합되기 전에 지점에 수행 해야하는 개별 QA 작업에 대한 설명을 의미합니다. (블랙 박스)

해결책

팀.

결함이 고객에게 도달하면 팀의 따라서 결함 팀 결함이 고객에게 도달하지 않도록 테스트 사례를 작성해야합니다.

프로젝트 관리자 (PM) 팀의 누구보다 도메인을 더 잘 이해해야합니다. 그들의 도메인 지식입니다 필수적인 도메인과 관련하여 적합한 테스트 케이스가있는 것. 예제 입력을 제공하고 유효하지 않은 입력에 대한 기대에 대한 질문에 답변해야합니다. 그들은 적어도 '행복한 길'테스트 케이스를 제공해야합니다.
개발자 코드를 알게 될 것입니다. 개발자가 작업에 가장 적합 할 수 있지만 블랙 박스 테스트 케이스를 찾고 있다고 제안합니다. 개발자가 제공하는 테스트는 흰색 상자 테스트입니다. 이것이 바로 개발자가 테스트 케이스를 만들도록하는 이점입니다. 코드의 이음새가 어디에 있는지 알고 있습니다.

좋은 개발자들은 또한 "언제 어떻게해야합니까?"라는 질문으로 PM에 올 것입니다. - 이들 각각은 테스트 사례입니다. 대답이 복잡한 경우 "if ㅏ 그 다음에 엑스, 그러나 만약 비 그 다음에 와이, 목요일을 제외하고 " - 여러 테스트 사례가 있습니다.
테스터 (QA) 소프트웨어를 테스트하는 방법을 알고 있습니다. 테스터는 PM과 개발자가 생각하지 않을 테스트 사례를 제시 할 가능성이 높습니다. 그래서 테스터가있는 이유입니다.

다른 팁

프로젝트 관리자 또는 비즈니스 분석가는 이러한 테스트 사례를 작성해야한다고 생각합니다.
그런 다음 QA 사람에게 양도하여 살을 치고 테스트해야합니다.

이렇게하면 사양과 실제로 테스트되고 전달되는 내용 사이에 누락 된 간격이 없습니다.

개발자는 단위 테스트를 테스트하기 때문에 확실히 수행하지 않아야합니다. 그래서 그것은 시간 낭비입니다.

또한 이러한 테스트에서는 개발자가 사양의 오해로 인한 오류 또는 올바르게 생각하고 구현되지 않은 코드를 통한 기능 또는 경로로 인해 개발자가 결코 찾을 수없는 오류를 찾을 수 있습니다.

당신이 이것에 대한 시간이 충분하지 않다면, 훌륭한 제품을 제공하는 것이 중요하기 때문에 다른 사람을 고용 하거나이 역할을 홍보하십시오.

우리는 QA 사람과 개발자의 쌍을 실험하여 결과가 좋은 결과를 얻었습니다. 그들은 일반적으로 '서로 정직하게 유지'했으며 개발자는 코드를 처리하기 위해 단위 테스트를 받았기 때문에 이미 변경 사항에 매우 친밀했습니다. QA 사람은 블랙 박스 쪽에서 나왔습니다. 둘 다 완전성에 대해 책임을졌다. 진행중인 검토 프로세스의 일부는 단위 테스트 단점을 포착하는 데 도움이되었으므로 문제가 발생했을 가능성이 높기 때문에 누군가가 의도적으로 X 테스트 작성을 피하는 곳이 어디에 있는지 알고 있었던 사건이 너무 많지 않았습니다.

나는 어떤 경우에는 페어링 아이디어를 좋아하고 그것이 잘 작동한다고 생각합니다. 항상 효과가있는 것은 아니지만 다른 지역의 플레이어가 상호 작용하는 것은 종종 일어나는 '벽 위에 던지는'정신을 피하는 데 도움이되었습니다.

어쨌든, 그것이 당신에게 도움이되기를 바랍니다.

과거의 경험에서, 우리는 약간 다른 것을 테스트하기 위해 다른 수준에서 테스트를 정의하는 행운을 빕니다.

1 단계 : 코드/클래스 수준에서 개발자는 원자 단위 테스트를 작성해야합니다. 목적은 가능한 한 개별 클래스와 방법을 테스트하는 것입니다. 이 테스트는 코드를 코드로, 아마도 코드를 소스 컨트롤에 보관하기 전에, 그리고 사용중인 경우 연속 통합 서버 (자동화)에 의해 실행되어야합니다.

2 차 계층 : 구성 요소 통합 수준에서 개발자에게는 단위 테스트를 생성하지만 구성 요소 간의 통합을 테스트합니다. 목적은 개별 클래스와 구성 요소를 테스트하는 것이 아니라 서로 상호 작용하는 방법을 테스트하는 것입니다. 이 테스트는 통합 엔지니어가 수동으로 실행하거나 사용중인 경우 연속 통합 선견자가 자동으로 운영해야합니다.

3 계층 : 응용 프로그램 수준에서 QA 팀이 시스템 테스트를 실행하도록합니다. 이러한 테스트 사례는 제품 관리자가 제공 한 비즈니스 가정 또는 요구 사항 문서를 기반으로해야합니다. 기본적으로 최종 사용자 인 것처럼 테스트하고 문서화 된 INT EH 요구 사항에 따라 최종 사용자가 수행 할 수 있어야 할 작업을 수행하십시오. 이러한 테스트 사례는 QA 팀과 고객이 원하는 것이 무엇인지, 응용 프로그램 사용 방법을 알고있는 제품 관리자가 작성해야합니다.

나는 이것이 꽤 좋은 수준의 적용 범위를 제공한다고 생각합니다. 물론 위의 1 단계와 2는 QA 팀에 구축 된 응용 프로그램을 보내기 전에 이상적으로 실행해야합니다. 물론, 당신은 당신의 비즈니스 모델에 맞는 것에 이것을 조정할 수 있지만, 이것은 나의 마지막 직업에서 꽤 잘 작동했습니다. Build/Integration Process에서 장치 테스트 중 하나가 실패하면 누군가가 테스트를 실행하는 것을 잊고 소스 아카이브에 고장난 코드를 커밋 한 경우에도 지속적인 통합 서버가 개발 팀에 이메일을 시작합니다.

"시간 낭비라고 생각하거나 단순히 그렇게하는 것을 좋아하지 않는 개발자"는 보상을받습니다. 시험 사례를 만들기 위해 어떤 사회 공학이 필요합니까?

QA는 코드 및 테스트 사례를보고 "충분한 적용 범위가 없으므로 더 많은 사례가 필요합니다"를 발음 할 수 있습니까? 그렇다면 "충분한"커버리지가있는 프로그래머는 Big Kahuna가됩니다.

따라서 내 질문은 다음과 같습니다. 일단 작업이 완료되면 누가이 작업에 대한 "충분한"테스트 사례의 목표를 정의해야합니까? "충분한"것을 알면 프로그래머가 "충분한"을 채우는 책임을지고 QA가 "충분한"테스트가 완료되었다고 보장 할 책임이 있습니다.

"충분히"정의하기가 너무 어렵습니까? 흥미로운. 아마도 이것은 처음에 프로그래머와의 충돌의 근본 원인 일 것입니다. 그들은 이미 "충분한"것을했기 때문에 시간 낭비라고 생각할 수도 있고 이제 누군가는 그것이 "충분하지 않다"고 말하고 있습니다.

"고객"과 함께 QA 사람들은 정의하다 각 작업에 대한 테스트 사례 [여기서는 용어를 혼합하고 있습니다.] 개발자는이를 작성해야합니다. 첫 번째!

내가 QA 사람들이 그렇게하는 것을 좋아하지 않는 이유는 내가 자신의 작품을 만드는 아이디어가 마음에 들지 않기 때문입니다. 예를 들어, 그들은 단순히 테스트하기에는 너무 많은 일을 남기지 않을 수 있으며 필요한 기술적 세부 사항을 알지 못할 수 있습니다.

Yikes, 당신은 당신의 QA 부서를 더 신뢰하거나 더 나은 부서에 대해 더 신뢰해야합니다. 내 말은, 당신이 "내 개발자들이 소프트웨어를 개발하는 것을 좋아하지 않습니다. 나는 그들이 자신의 작품을 만드는 아이디어가 마음에 들지 않습니다."

개발자로서 저는 제 자신의 테스트를 작성하는 데 관련된 위험이 있다는 것을 알고 있습니다. 그것은 내가 그렇게하지 않는다고 말하는 것이 아닙니다 (특히 TDD를하는 경우). 그러나 테스트 범위에 대한 환상이 없습니다. 개발자는 자신의 코드가 자신이 생각하는 것을 수행한다는 것을 보여주는 테스트를 작성하려고합니다. 실제 비즈니스 사례에 적용되는 테스트를 너무 많이 쓰지 않을 것입니다.

테스트는 기술이며, QA 부서, 또는 적어도 해당 부서의 리더는 그 기술에 정통합니다.

하나 또는 두 명의 테스터를 선택하고 테스트 사례를 작성하도록하십시오. 검토. 작업으로 작업하는 개발자가 작업에 대한 테스트 사례를 검토하는 경우에도 유용 할 수 있습니다. 테스터가 테스트 세트에 대한 개선과 추가를 제안하도록 장려하십시오. 때로는 사람들이 보스가 한 일을 고치는 것을 두려워합니다. 이렇게하면 테스트 디자인에 능숙한 사람을 찾을 수 있습니다.

테스터에게 기술적 인 세부 사항에 대해 알리십시오. 민첩한 팀의 모든 사람이 코드에 대한 액세스를 읽어야한다고 생각합니다. 내가 아는 대부분의 테스터는 코드를 읽고 쓸 수 있으므로 단위 테스트가 유용하여 확장 될 수도 있습니다. 테스트 디자이너가 무언가를 알아야 할 경우 개발자로부터 유용한 답변을 얻도록하십시오.

내 제안은 코드가 병합되어 품질을 보장하기 전에 다른 사람이 테스트 사례를 살펴 보도록하는 것입니다. 이것은 개발자가 다른 개발자의 작업을 간과하고 있다는 것을 의미 할 수 있지만 두 번째 눈 세트는 처음에는 잡히지 않은 것을 잡을 수 있습니다. 초기 테스트 사례는 테스터가 아닌 개발자, 분석가 또는 관리자가 수행 할 수 있습니다.

QA는 예상 결과가 정의되지 않은 상황이기 때문에 테스트 사례를 작성해서는 안되며,이 시점까지 각 측면이 해석이 올바른 것이라고 생각하면 QA와 개발 사이에 누군가 심판을 갖기가 어려울 수 있습니다. 그것은 내가 여러 번 보았고 그것이 자주 일어나지 않기를 바랍니다.

테스트를 "개발자"테스트 및 "고객"테스트로 느슨하게 해체하고 후자는 "수락 테스트"입니다. 전자는 개발자가 코드가 올바르게 수행되고 있는지 확인하기 위해 개발자가 작성하는 테스트입니다. 나중에는 누군가가 테스트입니다 다른 개발자보다 동작이 사양과 일치하도록하기 위해 글을 쓰는 것보다. 개발자는해야합니다 절대 테스트중인 소프트웨어 생성이 올바른 일을했다고 가정하므로 Cackatance Test를 작성하십시오. 따라서 그들의 수락 테스트는 아마도 개발자가 이미 진실이라고 생각한 것을 주장 할 것입니다.

수락 테스트는 사양에 따라 주도되어야하며 개발자가 작성한 경우 코드와 원하는 동작이 아닌 현재 동작에 의해 주도됩니다.

그만큼 민첩한 캐논 개발자 테스트와 고객 테스트라는 두 가지 테스트 계층이 있어야합니다.

개발자 테스트 생산 코드를 작성하는 동일한 사람들이 작성하고 바람직하게는 테스트 중심 개발. 그들은 잘 어퍼링 된 디자인을 제시하는 데 도움이되며, 코드가 리팩토링 후에도 개발자가 생각하는 일을 수행하도록 보장합니다.

고객 테스트 ~이다 지정되었습니다 고객 또는 고객 프록시에 의해. 실제로 시스템의 사양이며, 모두 실행 파일 (완전 자동화)으로 작성해야합니다. 그리고 비즈니스 사람들이 이해할 수 있습니다. 종종 팀은 고객이 쓰다 QA 사람들의 도움으로 그들. 이것은 기능이 개발되는 동안 또는 이전에 발생해야합니다.

이상적으로는 QA가 병합 직전에해야 할 유일한 작업은 모든 자동 테스트를 실행하는 버튼을 눌러 추가 탐색 (= 미확인) 테스트를 수행하는 것입니다. 합병 후에도 다시 테스트를 실행하여 변경 사항을 통합하는 것이 무언가를 깨지지 않도록합니다.

테스트 케이스는 스토리 카드에서 먼저 시작됩니다.

테스트의 목적은 왼쪽으로 결함을 유도하는 것입니다 (소프트웨어 개발 프로세스의 초기에는 저렴하고 빠른 수정이 더 빠릅니다).

각 스토리 카드에는 수락 기준이 포함되어야합니다. 제품 소유자는 솔루션 분석가와 짝을 이루어 각 스토리의 수락 기준을 정의합니다. 이 기준은 스토리 카드의 목적이 충족되었는지 확인하는 데 사용됩니다.

스토리 카드 수락 기준은 개발자가 테스트 중심 개발을 수행 할 때 개발자가 코딩 해야하는 자동화 된 단위 테스트를 결정합니다. 또한 자동 앰프 테스터가 구현 한 자동화 된 기능 테스트 (및 FIT와 같은 도구를 사용하는 경우 개발자 지원)를 구동합니다.

마찬가지로, 수락 기준은 자동화 된 성능 테스트를 주도하며 개발자의 응용 프로그램 프로파일 링을 분석 할 때 사용할 수 있습니다.

마지막으로, 사용자 수락 테스트는 스토리 카드의 수락 기준에 따라 결정되며 비즈니스 파트너 및 사용자가 설계해야합니다. 이 프로세스를 따르면 결함이없는 상태에서 해제 될 것입니다.

나는 소규모 팀을 제외하고 프로젝트 관리자가 테스트 사례를 작성하는 것을 거의 듣지 못하거나 보지 않았습니다. 크고 복잡한 소프트웨어 애플리케이션에서는 분석가에게 진짜 응용 프로그램을 알고 있습니다. 나는 모기지 회사에서 PM으로 일했습니다 - 서브 프라임 대출, 금리 등을 이해해야 했습니까? 어쩌면 피상적 인 수준이지만 실제 전문가들은 그 일이 작동하도록해야했습니다. 저의 임무는 팀을 건강하게 유지하고 민첩한 원칙을 보호하며 팀을위한 새로운 기회를 찾는 것이 었습니다.

시스템 분석가는 모든 테스트 케이스와 사용 사례와의 올바른 관계를 검토해야합니다. 또한 분석가는 최종 UAT를 수행해야하며 테스트 케이스를 기반으로 할 수 있습니다. 따라서 분석가와 양질의 사람은 일종의 동료 검토를 만들고 있습니다.

품질은 테스트 케이스를 구축하는 동안 사용 사례를 검토하고 있으며 분석가는 작성 후 테스트 케이스를 검토하고 UAT를 수행하는 중입니다.

물론 BA는 기술적 인 관점이 아닌 도메인 전문가입니다. BA는 요구 사항을 이해하고 테스트 사례는 요구 사항에 매핑되어야합니다. 개발자는 자신의 코드에 대해 테스트 할 테스트 사례를 작성하는 사람이되어서는 안됩니다. QA는 요구 사항 당 세부 테스트 단계를 작성할 수 있습니다. 그러나 요구 사항을 작성하는 사람은 테스트해야 할 사항을 지시해야합니다. 실제로 테스트 사례를 작성하는 사람은 테스트 사례가 요구 사항으로 거슬러 올라갈 수있는 한 너무 신경 쓰지 않습니다. BA가 테스트 방향이나 범위를 안내하는 것이 합리적이라고 생각하고 QA는 세분화 된 테스트 계획을 작성합니다.

우리는 "이것이 어떻게 행해졌거나 정신이 행해져야하는지"에서 발전해야합니다. 그것은 실패하고 지속적으로 실패합니다. 테스트 계획/사례 작성 문제를 해결하는 가장 좋은 방법은 테스트 사례가 Waterfall의 Doc 또는 Agile의 사용자 스토리에 대한 요구 사항에 작성되어야한다는 것입니다. 이런 식으로 테스트해야 할 사항은 의문의 여지가 없으며 QA 및 UAT 팀은 테스트 사례를 실행하고 실제 테스트 및 결함 해상도에 초점을 맞출 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow