테스터가 릴리스를 승인하거나 테스트에 대해보고해야합니까?

20

테스터에게 사인 오프 권한을 부여하는 것이 이치에 맞습니까? 테스트 팀이

기능, 문제 등을 테스트하고 합격 / 불합격으로 간단히보고하면 다른 사람이 해당 결과에 따라 행동하거나
그 결과에 따라 석방을 보류 할 권한이 있습니까?

다시 말해, 테스터가 릴리스에서 실제로 사인 오프해야합니까? 내가 작업하고있는 테스트 팀은 그들이하는 일을 느낀다. 그리고 우리는 "테스트 범위 크립"때문에 이것에 문제가있다. 릴리스 승인 거부는 때때로 문제의 릴리스에 의해 명시 적으로 해결되지 않은 문제에 근거한다.

testing release-management process

— 어니스트 프리드먼-힐
소스

2

설문 조사가 아닌 질문을 다시 입력하십시오. 해결하려는 문제는 무엇입니까?

— M. Dudley

5

"해야한다"는 회사의 조직 구조에 크게 의존해야한다. 프로덕션 환경에서 발견 된 버그를 측정 할 경우 버그가있는 릴리스를 보유 할 수 있어야합니다.

훌륭한 점, @MichaelT. 우리 조직에서 테스트는 직무 기술보다는 역할입니다. 평가는 좀 더 임시적이며 전혀 정량적이지 않습니다. 성공적인 배포는 긍정적 인 리뷰로 이어지지 만 프로덕션 버그는 팀의 다른 누구에게나 부정적인 영향을 미치지 않습니다.

— 어니스트 프리드먼 힐

5

테스터가 해결되지 않은 문제를 기반으로 릴리스 승인을 거부하는 문제가있는 경우, 의사 소통 문제 (문제가 해결 될 예정인지 알지 못함) 또는 사람 문제 (자신이 중요하게하고 있는지 여부) 릴리스는 궁극적으로 비즈니스 결정입니다.

— Jan Hudec

27

QA 직원이 근무한 대부분의 장소에는 일종의 사인 오프 단계가 있지만 릴리스가 진행되는지 여부에 대한 최종 권한은 없습니다. 그들의 서명은 그들이 릴리스에 결함이 없다는 것이 아니라 릴리스 계획에 의해 예상 된 테스트를 완료했음을 나타냅니다.

궁극적으로 QA! = 비즈니스와 비즈니스는 현재 상태에서 코드를 배포해도 문제가 없는지 또는 이점이 단점보다 큰지 결정해야합니다. 이는 배포 직전에 클라이언트 또는 이해 관계자가 수행하는 경우가 많으며 사용자 승인이라고도합니다.

QA가 User Acceptance 그룹 인 경우 릴리스 후보를 허용 할 수없는 것으로 정의 할 권한이 있지만 버그 수정 / 반복 / 스프린트 / 변경 범위를 벗어난 문제에 대해이 문제가 발생하는 경우 요청 / 무엇이든 시간을 보내더라도 프로젝트 관리자 또는 비즈니스 라인 이해 관계자는 QA 팀과 예수를 만나야합니다.

기존의 결함이나 의도하지 않은 새로운 요구 사항에 대해보고하는 것이 좋지만, 범위를 벗어나고 비재 해적이라면 일반적으로이를 차단 문제로 표시하는 것은 허용되지 않습니다. 제품 소유자는 다른 모든 것보다 우선 순위를 정하기 위해 백 로그에 들어갑니다.

— 계산서
소스

고객이 빌드 1234에서 승인 테스트를 수행하도록 고객을 초대할지 아니면 승인 테스트에 충분하지 않은지를 누가 결정합니까?

— Bart van Ingen Schenau

3

@BartvanIngenSchenau : 제품 소유자 / 프로젝트 관리자는 이것에 대한 마지막 말을해야합니다. 심지어 수락 테스트가 종종 있기 때문에 것 돌출하는 경우 필요 (지금 우리가 함께 작업에 Y를 얻을 수, 또는 당신은 우리가 문제를 해결할 때까지 2 개월 이상을 기다려야 할 할 수 없지만 기능 X를 하시겠습니까?) 및 제품 소유자 수 협상 중입니다.

— Jan Hudec

Jan이 말한 것 외에도 많은 방법론에서 여기에 일정이나 케이던스가 있습니다. 일부 사람들은 초기 연기 테스트에서 살아남은 모든 후보를 UAT에 배포하고, 일부는 후보 지점에 체크인 한 항목을 모두 자동 배포하고, 일부는 주 항목에 체크인합니다. 이상적으로는 당신이 어떻게 든 갈 때 이해 관계자의 진전을 보여 주었으므로 결국 놀랄 일이 아닙니다. 이러한 경우 중 일부에서 QA 사람들이 석탄을 통해 당신을 끌고있는 것을 이해 관계자에게 보여주게되며 그들은 단지 "누가 신경 쓰는지"라고 말하고 끝났습니다.

— Bill

지속적인 배포가 가능한 최신 SaaS에서 코드 (서비스) 배포주기는 기능 (비즈니스) 릴리스주기와 분리 될 수 있습니다. 이 기능 릴리스주기는 기능 플래그 또는 토글을 사용하여 구현할 수 있습니다 (예 : 알파 (내부)에서 베타 (선택)). 이는 특정 코드 또는 서비스의 배포 가능성과 상관없이보다 공식적인 비즈니스 사인 오프를 포함하는 한 가지 방법입니다. 반대로 서비스 릴리스에 기능 릴리스를 연결하면 기능 플래그 기술로 피할 수있는 프로세스에 커플 링 및 위험이 발생합니다.

— Will

@ 나는 동의하지 않지만, 숨겨진 배치 된 기능이 초기 배치에서 베타 팀 이외의 사용자가 알아 차리지 못할 정도로 숨겨져 있는지, 그리고 궁극적으로 시퀀스 플레이에 접근하는 데 사용한 모든 곳에서 판단을 내리고 있습니다. 다소 비슷하지만 움직이는 부분에 다른 레이블이 있고 위험이 조금씩 바뀌 었습니다. 설명하는 상황을 선호하지만 QA 팀은 기존의 것을 찾거나 제품 관리자가 어쨌든 진행하기로 결정한 것은이 경험에서 다른 것만큼이나 중요합니다.

— Bill

6

누군가 는 그 권위가 필요합니다 . 테스터, 테스터 팀, 테스터 팀의 리더 또는 개발 조직의 리더인지 여부는 다소 관련이 없습니다. 또는 더 정확하게는 조직에 따라 다릅니다.

궁극적으로 소프트웨어 릴리스는 비즈니스 기능입니다. 비즈니스는 품질이 적절한 지 결정해야합니다. 틀림없이, 품질 보증 책임자는 그 결정을 내리거나 그 결정을 적절한 사업부에 제공해야합니다. 모든 것은 회사의 규모, 품질의 상대적 중요성 등에 달려 있습니다.

모든 결정에서 결정을 내리는 데 사용되는 정보는 테스터로 시작됩니다 . 릴리스를 중지 할 수있는 권한이 있는지 여부에 관계없이 의사 결정자에게 릴리스 지연을 유발할 것으로 생각되는 내용이있을 때 알릴 책임이 있습니다.

— 브라이언 오클리
소스

6

테스터에게 배포 할 수 있도록 승인 권한 (즉 거부권)을 부여하는 것은 개발자에게 그 권리를 부여하는 것만큼이나 의미가 있습니다.

테스터와 개발자는 주로 기술 담당자이므로 대부분 기술적으로 결정을 내릴 수 있습니다. 그러나 릴리스 할 때 고려해야 할 사항은 기술 및 비즈니스 문제입니다. 분명히, 고객이 버그를 타는 제품을 제공하면 만족하지 않지만, 제품에 여전히 공개 된 문제가 있기 때문에 릴리스를 계속 연기하면 고객은 똑같이 불만을 갖게됩니다.

좋은 제품과 고객에게 약속 된 일정을 유지하는 것 사이에서 올바른 균형을 찾아야합니다. 그렇게하려면, 당신은해야 하지 순전히 기술적 인 역할 프로젝트에 참여되지만 오히려 프로젝트 매니저 또는 제품 소유자와 테스터와 개발자로부터 입력을 같은 더 많은 비즈니스 / 관리 중심의 역할을한다.

— 바트 반 인겐시나 우
소스

1

나는 당신이 만들고있는 몇 가지 요점과 가정에 근본적으로 동의하지 않기 때문에 이것을 거부했습니다. 많은 QA 그룹도 사용자 승인 역할을 수행하기 때문에 QA가 릴리스를 거부 할 권한이 없어야한다는 데 동의하지 않습니다. 또한 테스터가 기술인이라는 가정에 동의하지 않습니다. 항상 그런 것은 아닙니다. 소프트웨어를 출시하는 모든 그룹이 전체 QA 팀을 감당할 수있는 것은 아니므로 기술적 인 것이 아닐 수도있는 비즈니스 분석가가 역할을 수행 할 수 있습니다.

— maple_shaft

1

maple_shaft의 요점 외에도 끔찍한 것이 발견되지 않는 한 고객 역할을 맡은 사람에게이 왼쪽에 대한 최종 요청을 자주 봅니다. 그것은 궁극적으로 그들의 인도 물이며 정확한 정보를 제공한다고 가정 할 때 위험에 대한 올바른 관점을 가질 가능성이 높습니다.

— Bill

5

'릴리스'또는 '릴리스하지 않음'결정은 엄격한 위험 / 보상 분석을 수행해야하는 비즈니스 결정일이 끝날 때입니다.

조직이 테스트 팀에게이 책임을 맡도록 요청하거나 테스트 팀이이 책임에 동의하도록하는 것은 미친 짓입니다.

테스트 팀의 역할은 소프트웨어 품질, 릴리스 준비 상태 및 릴리스 여부에 대한 비즈니스 결정의 입력으로 식별 된 위험에 대한 분석을 제공하는 것입니다.

다른 사람들이 지적했듯이, _ somebody _ (그리고 나는 그것이 개인이라고 믿는다) '해제'또는 '해제 안함'결정을 내릴 권한이 필요합니다. 같은 사람이 특정 조건 하에서 해당 결정을 위임 할 수 있습니다 (예 : P1 또는 P2 버그 없음)

— 요르단
소스

3

나는 테스터들이 같은 상황에 처해 위험을 평가할 때 생산에서 일어날 가능성이 거의없는 시스템을 파괴하는 훨씬 더 창의적인 방법을 발명했습니다.

테스트 팀이 불완전한 릴리스를 보내지 않기로 이해하고 칭찬하는 동안 "허용 가능한 위험"을 정의하기 위해서는 강력한 제품 소유권이 필요합니다.

필자의 경험에 따르면 테스트 팀은 소프트웨어 릴리스에 대한 거부권을 부여 받아야하지만이 거부권은 제품 소유자가 무시할 수 있어야하지만 수석 테스터와 논의한 후에 만 가능합니다.

테스트 크리프를 겪고 있다면 소프트웨어가 완벽하지 않을 것입니다. 중대한 생산 문제가 발생하여 제대로 테스트되지 않을 때까지는 아무것도 출시되지 않습니다.

— 남자 이름
소스

1

그것은 실제 문제이지만 그것이 반드시 OP의 문제인지 확실하지 않습니다. 내 해석은 테스터가 원래 정의되지 않은 새로운 요구 사항을 해석하고 있다는 것입니다.

— maple_shaft

2

테스트 팀에 대한 나의 경험으로 인해 나는 이것의 반대편에 빠지게되었습니다. 나에게 QA는 팀의 나머지 팀에게 사건을 제기하거나 소유자가 팀을 재정의하지 않고 배포를 차단할 것으로 기 대해서는 안됩니다.

— Bill

1

사실-아마도 충분히 명확하지 않았을 것입니다. 테스터가 결함을 제기 할 때 동일한 문제가 발생하며 동일한 문제로 이어지는 "이야기의 속임수"에 인용하면 아무것도 발표되지 않습니다.

— Michael

제 경우에는 더 @maple_shaft의 해석입니다. 명시 적으로 지원되지 않는 사례를 처리하지 못하는 것으로보고하면 소프트웨어를 파괴 할 수있는 방법을 찾는 데 악의적이지 않습니다.

— 어니스트 프리드먼 힐

1

@ ErnestFriedman-Hill 부정적인 요구 사항을 설명하는 것 같 으며 기능 요구 사항 문서에서 누락 된 내용입니다. 부정적인 요구 사항은 시스템이 하지 않을 일 에 대한 명시 적 진술 이며 일반적인 요구 사항만큼 수용 가능합니다. 이것이 선언되면 부정적인 요구 사항에 대한 테스트 사례가 유효하지 않습니다.

— maple_shaft