메뉴

스크럼에서 QA의 역할에 시작 및 중지 경계가 있습니까?

is there any start stop boundary qa s role scrum

문제를 제거하기 위해 도구를 사용해보십시오

스크럼에서 QA의 역할 : 테스터를위한 스크럼 활동

이 문서는 일부 프로세스 또는 방법에 대한 자습서 또는 QA로 작업하는 방법에 대한 지침이 아닙니다. 오히려 이것은 SCRUM에서 선임 QA로 일한 경험을 공유하고 싶은 기사입니다.

저의 이전 CTO는 항상 ‘자유에는 책임이 따릅니다’. 당신이 당신의 방식대로 일을 할 자유가 주어진다면 당신의 일이나 업무 또는 활동에 대한 책임은 당신뿐입니다.

이것이 스크럼의 모든 것입니다 !! 계속 진행하면서 스크럼에 대한 기본적인 아이디어를 알려 드리겠습니다.

스크럼에서의 QA 역할

학습 내용 :

스크럼 개요

스크럼은 애자일 방법론 널리 사용되는 경량 프로세스 프레임 워크입니다.

Scrum은 작은 모듈로 제품을 제공하여 고객을 행복하게 유지하는 데 도움이되며, 자주 변경되는 요구 사항이 활동 속도를 늦출 수 있음을 고객이 인식하도록합니다. 릴리스가 짧고 관련 팀의 능력에 따라 작업이 수행되므로 실패 또는 불만족 고객의 가능성이 크게 줄어 듭니다.

반면에 요구 사항 (이 경우 사용자 스토리)은 재 작업을 방지하기 위해 Sprint가 시작되기 전에 완료되므로 Sprint가 지연되거나 실패하게됩니다 (예외는 항상 존재 함).

그러나 QA의 가장 큰 도전은 릴리스 기간이 짧고 Sprint는 대부분 15 일주기라는 것입니다. 따라서 버그가없는 제품을 최대 4 ~ 5 일 (개발 시간 제외)에 제공하려면 많은 노력과 현명한 사고가 필요합니다.

나는 우리 팀의 QA입니다.

스크럼

오 예, 저는 제 팀의 QA이고 제 팀의 중요한 선수입니다. 왜?? 고객, BA, Scrum Master 및 기타 모든 사람들이 응용 프로그램 또는 제품의 품질, 모양 및 느낌 및 성능에 대해 애매하기 때문입니다.

스크럼에서는 스프린트 기간이 짧기 때문에 QA가 현명한 방식으로 수행되어야하므로 QA가 처음부터 바로 참여해야하는 '계획'이 매우 중요합니다. PO를 사용할 수 없을 때 QA가 프록시 제품 소유자의 역할을 수행 할 수있는 경우가 있습니다. 따라서 BA가 승인 기준 테스트 시나리오 / 케이스를 생성하는 데 도움이됩니다.

또한 개발자는 기능이나 비즈니스 규칙에 문제가있을 때 QA에 접근합니다. Scrum에서 초점은 원활하고 성공적인 Sprint 릴리스를 갖는 데에만 있으며, 팀이 도움을 청할 때 도움의 손길을 제공하는 것은 '내 작업'또는 '내 작업'이 아닙니다.

스크럼 팀 결속에서 팀 구성원 간의 건전한 관계는 매우 중요한 역할을하며 QA가되므로 테스트중인 사용자 스토리에 대한 의견을 전달하는 동안 매우주의해야합니다. 커뮤니케이션은 작업 한 사람이 아닌 사용자 스토리 또는 기능에 관한 것이어야합니다.

스크럼에서 QA는 그가 발견 한 버그의 수뿐만 아니라 팀과 어떻게 상호 작용하는지, 어려운시기에도 팀을 돕고 팀에 동기를 부여하는 방식에 대해 평가되거나 평가되지 않습니다.

스프린트 작업을 테스트하는 것 외에도 테스트 계획 / 테스트 사례 / 릴리스 문서를 작성하는 것은 Sprint의 릴리스 기간이 짧고 모든 사람에게 목표가 동일하기 때문에 더 많은 작업을 포함하려고합니다. '서로를 도와 성공적으로 작동하는 버그없는 제품을 제공하기 위해'.

QA는 Sprint에서 수행되는 거의 모든 활동에 관여하며 기술적으로 QA 활동의 시작 또는 중지에 대한 경계가 없습니다. QA가 릴리스 테스트로만 제한되는 기존 Waterfall 모델과 달리 여기서 QA는 훨씬 더 많은 책임이 있습니다. 따라서 다음 활동을 더 많이 시도하고 수행하는 것이 좋습니다.

따라야 할 활동

다음은 스크럼의 QA로 따라야 할 몇 가지 활동입니다.

소프트웨어 테스트 면접 질문 및 더 신선한 답변

# 1) 더 깊이 살기 :

즉, 사용자 스토리와 수용 기준이 준비되면 철저히 연구하고 종속성, 숨겨진 결과 및 더 나은 방법이 있는지 더 깊이 생각합니다.

이에 대해 생각하지 않았을 수도 있기 때문에 BA 및 개발 팀과 소통하고 협력하십시오. 아이디어와 결과를 팀과 공유하십시오.

숨겨진 장애물이나 부정적인 영향이있는 경우 스크럼 마스터 및 개발자와 함께 문제를 제기하면 그에 따라 생각하고 행동 할 시간을 줄 것입니다. Scrum의이 활동은 프로젝트가 대규모 프로젝트 일 때 매우 중요합니다. 팀에 모듈이 분산되어있을 때.

이제 종속성에 대해 연구하는 동안 QA에 미치는 영향은 매우 중요하며 개발 팀도이를 인식하게합니다. 이를 위해 다른 팀의 QA와 논의하고 그들로부터 의견을받습니다.

# 2) 추정에 참여 :

일반적인 관행은 견적에 QA를 포함하는 것이지만 작은 스프린트로 인해 많은 경우 QA가 작업을 테스트하고 테스트 작업에 3/4/5 일을 남겨두기 위해 견적을 요청하지 않을 수 있습니다.

이것을 받아들이지 마십시오. 필요한 경우 목소리를 높이 되 모든 작업에 필요한 시간을 포함해야하는 테스트 견적을 제공하고 있는지 확인하십시오.

연구 시간, 설정 시간, 기록 데이터 수집 시간 등이 포함될 수 있지만 테스트 활동을 수행하는 데 필요한 시간에 대해 엄격하고 구체적이어야하며 이러한 시간 값을 개발 작업 시간과 함께 사용자 스토리에 추가해야합니다. .

할당 된 시간 내에 작업을 시도하고 완료 할 수없는 경우 실패에 대한 책임은 자신에게 있으므로 매우 중요합니다. QA 시간이 추가되면 스크럼 마스터 인 PO는 관련된 QA 활동과 필요한 시간을 인식하게됩니다.

# 3) 개발자 QA 페어링 :

이상적으로는 Scrum에서 Sprint User Stories는 개발이 완료된 후 테스트를 위해 전달되지만 개발 테스트가 완료되면 문제는 4 ~ 5 일 정도 테스트를 위해 QA에 전달된다는 것입니다. 데모 또는 리뷰에 남아 있습니다.

이제 QA로서 4 개의 차단기 또는 기능적 실패를 발견하면 기능 테스트, 회귀 등이 수행되므로 릴리스 날짜를 맞추기 위해 늦은 밤이나 주말에 작업해야합니다. 이것은 최선의 방법이 아닌 전통적인 폭포 모델처럼 보입니다. 스크럼에서 가장 현명한 방법은 “결함을 찾는 것보다 결함을 예방하십시오”.

따라서 해결책은 개발자가 테스트를위한 공식 릴리스 이전에도 스토리를 준비하는 즉시 개발 QA 페어링을 수행하고 개발 설정에 대한 기본 테스트를 수행하는 것입니다.

사용자 스토리의 개발 설정에서 BVT를 수행하기 위해 다음 기준을 고려할 수 있습니다.

  • 각 사용자 스토리에 대한 허용 기준 : 수용 기준에 따른 사용자 스토리의 BVT.
  • 개발자에 대한 자신감 부족 : 때로는 개발자가 일부 구현에 대해 확신하지 못하기 때문에 이러한 구현에 대해 논의하고 동일한 개발 설정에있는 사람들을 위해 BVT를 수행합니다.
  • 종속성 / 영향 테스트 : 새로운 구현의 다른 모듈에 대한 종속성 또는 영향의 BVT.
  • 단위 테스트 : 자신이 만든 단위 테스트의 개발자와 BVT를 수행합니다. 필요한 경우 단위 테스트를 추가하거나 업데이트하여 도움을줍니다.

이렇게하면 버그를 앞뒤로 줄이는 데 도움이되며 대부분의 충돌 또는 기능 버그가 이미 수정 된 QA 릴리스 이전과 마찬가지로 모든 사람의 시간을 절약 할 수 있습니다. 스프린트 검토 전에 이러한 결함을 도구에 기록하고 '종료'상태가 될 때까지 이동해야합니다.

개발자 QA 페어링

# 4) 화이트 보드에 대한 QA :

나는 항상 개인적으로 우리 팀에게 버그를 포함하여 화이트 스크럼 보드에 QA 작업을 포함하도록 권장했습니다. 이것은 스크럼 마스터가 단순히 보드를보고 사용자 스토리의 QA 상태를 파악하는 데 도움이됩니다.

아니. To Do 목록의 버그, In Progress 목록의 버그, To Do, In Progress 및 Done 목록의 QA 활동이 스스로를 대변합니다. 누군가가 Sprint에 대한 개별 스토리의 테스트 상태에 대해 물어볼 때 나는 도구 컴파일에서 내 상태를 가져 와서 보여 주거나 이메일 초안을 작성하는 데 추가 시간을 투자해야하기 때문에 정말 고통 스럽습니다.

나는 단순히 그 사람을 스크럼 보드로 가리키고 그들이 스스로 알아 내도록하는 것을 선호합니다. QA Sticky 슬립에는 밝고 뛰어난 색상을 선호합니다.

화이트 보드에 대한 QA

# 5) 문서 :

이것은 Sprint의 크기가 작기 때문에 문서화 할 시간이 많지 않고 스크럼 팀에서 테크니컬 라이터를 본 적이 없다는 Scrum의 단점 또는 단점 중 하나입니다. 스크럼 마스터 / BA는 제품 정보에 대한 문서를 업데이트하지 않을 수도 있고 업데이트하지 않을 수도 있습니다.

문제는 새로운 회원이 가입하거나 비즈니스 규칙, 기능이 변경되고 최악의 경우에 발생합니다. '완료'사용자 스토리에서 정보를 검색하는 것은 건초 더미에서 바늘을 찾는 것과 같기 때문입니다.

해결책은 문서를 검토하고 스크럼 마스터 또는 BA가 문서를 업데이트하거나 업데이트 할 수 있도록 문서화를 위해 가능할 때마다 (대부분 여유 시간에 또는 작업량이 매우 적을 때) 스프린트에 별도의 작업을 생성하는 것입니다.

QA는 사용자 스토리를 테스트하고 확인하며 기능을 안팎으로 알고 있기 때문에 문서 업데이트에 도움이되는 적임자입니다. BA가없고 스크럼 마스터가 업데이트 하느라 바쁘다면 직접 수행하십시오.

# 6) 스프린트 검토 / 스프린트 데모 :

대부분의 경우 QA는 PO와 이해 관계자에게 데모를 제공하기 위해 선택된 사람입니다. 하지만 스크럼 마스터가 그렇게하도록 설득하지 않으면. QA는 사용자 스토리를 안팎으로 테스트 했으므로 데모를 제공하기에 적합한 사람입니다.

QA는 기능, 흐름 및 비즈니스 규칙을 알고 있기 때문에 비즈니스 관점에서 데모 할 수 있습니다. 데모를 잘 준비하고 PO와 이해 관계자가 가지고있는 모든 질문에 답하십시오. 이것은 스크럼 마스터와 BA가 없을 때 그들과 연락하는 데 도움이 될 것입니다.

# 7) BA처럼 행동 :

이것은 정규 작업이 아니며 QA에서 기대하지도 않지만 QA가 BA가 될 수있는 가장 좋은 사람이기 때문에 기회가 던져 질 때이 역할을 맡으십시오. 예를 들어 흐름, 기능 또는 비즈니스 규칙이 고객에게 도움이되는 방식으로 수정 될 수 있는지 생각하고 시각화하십시오.

UI의 현재 트렌드, 애플리케이션의 룩앤필, 어떻게 이길 수 있는지, 더 사용자 친화적으로 만들 수 있는지 등을 생각하고 검색합니다. 팀이 문제에 갇혀 있으면 참여하고 간단하고 스마트하게 제공하세요. 해결책. 이것은 귀하의 역할을 향상시키고 귀하의 경력 성장에 기여하는 요소가 될 것입니다.

PO와의 통화 중 일부 문제가 논의되거나 제안 할 수있는 검토 / 데모에서 기회가 올 수 있습니다.

결론

Scrum은 일반적인 Waterfall 방법과는 매우 다른 방법론이며 Scrum Master는 촉진자입니다. 따라서 그 / 그녀가 귀하를 위해 귀하의 활동을 정의 할 것이라고 기대하지 마십시오.

Scrum에서는 QA의 역할에 대한 시작 및 끝 경계가 없습니다. QA는 사전 계획부터 스프린트 검토 / 데모까지 모든 활동을 처음부터 끝까지 모든 활동이 필요하며 참여해야하며 모든 활동에 참여해야합니다.

이것은 Scrum에서 작업 할 때 사용할 수있는 적절한 문서가 없기 때문에 제품 또는 응용 프로그램을 이해하는 데 도움이됩니다. 당신은 책임감 있고 의욕적이며 적극적이어야합니다. 그러므로 누군가가 와서 당신이 무엇을 어떻게해야하는지 말해 줄 때까지 기다리지 마십시오.

스스로 주도권을 잡고 가능한 모든 방법으로 팀을 돕고 건전한 관계를 유지하고 팀에서 진행중인 일을 추적하고 가장 중요한 것은 주어진 스프린트에서 작업에 대해 명확히해야합니다.

여기에는 귀하를 모니터링하거나 귀하의 활동을 추적 할 관리자가 없습니다. 항상 팀을위한 도움의 손길을 준비하면 최상의 기회를 얻을 수 있습니다.

이 유익한 기사에 대한 생각 / 제안을 아래 댓글 섹션에 자유롭게 표현하십시오.

추천 도서

^