안녕하세요 여러분! 제 이름은 Yulia이고 테스터입니다. 작년에 내가 너한테 말했었지 바고델냐 - 버그 백로그를 정리하기 위해 당사에서 개최하는 이벤트입니다. 이는 단 하루 만에 이를 크게 줄일 수 있는(다른 팀의 경우 10~50%) 완전히 실행 가능한 옵션입니다.

오늘 저는 봄 Bagodelny 형식인 BUgHunting(BUH)에 대해 말씀드리고 싶습니다. 이번에는 오래된 버그를 수정하지 않고 새로운 버그를 찾고 기능에 대한 아이디어를 제안했습니다. 컷 아래에는 그러한 이벤트의 조직, 결과 및 참가자의 피드백에 대한 많은 세부 정보가 있습니다.

규정을 숙고하고 작성한 후 기업 Slack의 모든 채널에 어떠한 제한도 포함되지 않은 초대장을 보냈습니다.

그 결과 개발자와 비기술 전문가 모두 약 30명이 등록했습니다. 우리는 행사를 위해 근무일 전체를 할당하고, 큰 회의실을 예약하고, 사무실 매점에서 점심을 준비했습니다.

이유는 무엇입니까?

각 팀이 기능을 테스트하는 것 같습니다. 사용자가 우리에게 버그를 보고합니다. 도대체 왜 이런 행사를 하는 걸까요?

우리에게는 몇 가지 목표가 있었습니다.

1. 관련 프로젝트/제품에 더 가까운 사람들을 소개하세요..
   이제 우리 회사에서는 모두가 별도의 팀, 즉 단위로 일하고 있습니다. 이들은 자신의 기능 부분에 대해 작업하고 있지만 다른 프로젝트에서 무슨 일이 일어나고 있는지 항상 완전히 인식하지 못하는 프로젝트 팀입니다.
2. 동료들에게 서로 소개해주세요..
   모스크바 사무실에는 거의 800명의 직원이 있지만 모든 동료가 서로를 눈으로 아는 것은 아닙니다.
3. 제품에서 버그를 찾는 개발자의 능력 향상.
   우리는 이제 이러한 방향으로 애자일 테스팅 및 교육 인력을 홍보하고 있습니다.
4. 테스트에 기술 전문가 이상의 참여.
   기술 부서 외에도 "아... 아무것도 작동하지 않습니다."와 같은 메시지를 덜 받을 수 있도록 버그를 올바르게 보고하는 방법에 대해 더 자세히 이야기하고 싶어하는 다른 전문 분야의 동료가 많이 있습니다.
5. 물론 까다롭고 눈에 띄지 않는 버그도 찾아보세요..
   저는 팀이 새로운 기능을 테스트하도록 돕고 구현된 기능을 다른 각도에서 볼 수 있는 기회를 제공하고 싶었습니다.

Реализация

우리 하루는 여러 블록으로 구성되었습니다.

• 요약 보고;
• 주요 사항(테스트의 목표 및 원칙 등)만 다룬 테스트에 대한 짧은 강의
• 버그를 소개할 때 "예의의 규칙" 섹션(여기에 원칙은 잘 설명되어 있습니다);
• 높은 수준의 시나리오가 설명된 프로젝트에 대한 XNUMX개의 테스트 세션; 각 세션 전에는 프로젝트와 팀 분할에 대한 짧은 소개 강의가 있었습니다.
• 이벤트에 대한 간단한 설문 조사;
• 요약.

(또한 세션 사이의 휴식 시간과 점심 식사도 잊지 않았습니다.)

기본 규칙

• 이벤트 등록은 개별입니다., 한 사람이 가지 않기로 결정하면 관성으로 인해 팀 전체가 지치는 문제를 해결합니다.
• 참가자는 세션마다 팀을 변경합니다.. 이를 통해 참가자들은 언제든지 오고 갈 수 있으며, 더 많은 사람들을 만날 수도 있습니다.
• 팀 각 세션 전에 두 사람 무작위로 형성된다, 이를 통해 더욱 역동적이고 빨라집니다.
• 도입된 버그에 대해 수여됩니다. 중요도에 따라 포인트(3~10).
• 중복된 경우에는 점수가 부여되지 않습니다.
• 버그는 모든 내부 표준에 따라 팀원이 제출해야 합니다.
• 기능 요청은 별도의 작업으로 생성되며 별도의 후보에 참여합니다.
• 감사팀은 모든 규칙의 준수 여부를 모니터링합니다.

기타 세부 정보

• 처음에는 "고급" 테스트 이벤트를 진행하고 싶었지만... 제품 이외의 팀(SMM, 변호사, PR)의 직원이 꽤 많이 등록했기 때문에 콘텐츠를 크게 단순화하고 복잡한/프로필 사례를 제거해야 했습니다.
• 다양한 프로젝트의 Jira 유닛 작업으로 인해 흐름에 따라 버그 도입을 위한 템플릿을 설정하는 별도의 프로젝트를 특별히 만들었습니다.
• 포인트를 계산하기 위해 웹훅을 통해 업데이트된 리더보드를 사용할 계획이었지만 문제가 발생하여 결국 수동으로 계산해야 했습니다.

이벤트를 조직할 때 모든 사람이 문제에 직면하게 됩니다. 여러분의 편의를 위해 피할 수 있는 문제에 대해 설명하겠습니다.

스피커 중 한 명이 갑자기 병이 나서 새 스피커를 찾아야 했습니다..
오전 9시에 같은 팀의 교체 선수를 찾은 것은 정말 운이 좋았습니다. 하지만 운에 의존하지 말고 여유를 갖는 것이 좋습니다. 아니면 필요한 보고서를 직접 제공할 준비를 하십시오.

기능을 출시할 시간이 없었고 블록을 교체해야 했습니다..
전체 블록을 버리지 않으려면 백업 계획을 세우는 것이 좋습니다.

일부 테스트 사용자가 중단되어 신속하게 새 사용자를 다시 만들어야 했습니다..
테스트 사용자를 사전에 교차 확인하거나 신속하게 수행할 수 있습니다.

형식이 단순화 된 사람은 거의 오지 않았습니다..
강제로 누군가를 끌 필요가 없습니다. 자신을 낮추십시오.
이벤트 형식을 "아마추어"/"고급"으로 엄격하게 규정하거나 두 가지 옵션을 동시에 준비하고 사후에 어떤 옵션을 개최할지 결정하는 옵션이 있습니다.

유용한 정리 포인트:

• 사전에 회의를 예약하세요.
• 테이블을 준비하고, 연장 코드와 서지 보호 장치도 잊지 마세요(노트북/휴대폰을 충전하는 것만으로는 하루 종일 충분하지 않을 수 있습니다).
• 채점 프로세스를 자동화합니다.
• 순위표를 준비합니다.
• 테스트 사용자의 로그인 및 비밀번호, Jira 작업 지침, 스크립트가 포함된 종이 유인물을 만듭니다.
• 행사 일주일 전에 알림을 보내는 것을 잊지 말고, 가지고 가야 할 것(노트북/기기)도 명시하세요.
• 데모, 점심 식사, 커피 한잔과 함께 동료들에게 이벤트에 대해 알리십시오.
• 이날 아무것도 업데이트하거나 출시하지 않기로 devops에 동의합니다.
• 연사를 준비하다;
• 기능 소유자와 협상하고 테스트를 위한 더 많은 시나리오를 작성합니다.
• 간식으로 간식(쿠키/사탕)을 주문하세요.
• 이벤트 결과에 대해 알려주는 것을 잊지 마세요.

조사 결과

하루 종일 직원들은 4개의 프로젝트를 테스트하고 192개의 버그(그 중 134개는 고유함)와 기능 요청에 대한 7개의 문제를 생성했습니다. 물론 프로젝트 소유자는 이러한 버그 중 일부에 대해 이미 알고 있었습니다. 하지만 예상치 못한 발견도 있었습니다.

참가자 전원은 달콤한 상품을 받았습니다.

그리고 승자는 보온병, 배지, 스웨트셔츠입니다.

흥미로운 점은 다음과 같습니다.

• 참가자들은 시간이 제한되어 있고 생각하는 데 많은 시간을 보낼 수 없는 힘든 세션의 형식을 예상치 못했다는 것을 알았습니다.
• 데스크톱, 모바일 버전 및 애플리케이션을 테스트했습니다.
• 우리는 한 번에 많은 프로젝트를 보았고 지루할 시간이 없었습니다.
• 다양한 동료들을 만나 버그 도입에 대한 접근 방식을 살펴보았습니다.
• 테스터들의 고통을 모두 느꼈습니다.

개선할 수 있는 사항:

• 프로젝트 수를 줄이고 세션 시간을 1,5시간으로 늘립니다.
• 선물/기념품을 미리 준비하십시오(때때로 승인/지불에는 한 달이 소요됩니다).
• 긴장을 풀고 어떤 일이 계획대로 진행되지 않을 것이며 불가항력이 있을 것이라는 사실을 받아들이십시오.

리뷰

Anna Bystrikova, 시스템 관리자: “구호원은 나에게 매우 교육적이에요. 테스트 과정을 배웠고, 테스터들의 '고통'을 모두 느꼈습니다.
먼저 테스트 과정에서 예시 사용자로서 버튼이 클릭되는지, 페이지로 이동하는지, 레이아웃이 밖으로 이동했는지 등 주요 사항을 확인합니다. 그러나 나중에는 고정관념에서 벗어나 더 많은 생각을 하고 응용 프로그램을 "깨기" 위해 노력해야 한다는 것을 깨닫게 됩니다. 테스터는 어려운 일을 합니다. 인터페이스 전체를 "찔러보는 것"만으로는 충분하지 않습니다. 고정관념에서 벗어나 생각하고 세심한 주의를 기울여야 합니다.
인상은 긍정적이었습니다. 이벤트가 끝난 후 어느 정도 시간이 지난 지금도 제가 발견한 버그에 대한 작업이 어떻게 진행되고 있는지 알 수 있습니다. 제품 개선에 참여하는 기분이 들어서 좋아요 ^_^.”

Dmitry Seleznev, 프론트엔드 개발자: “경쟁 모드에서 테스트하면 더 많은 버그를 발견할 수 있는 동기가 부여됩니다.) 모두가 Baghunting에 참여하도록 노력해야 할 것 같습니다. 탐색적 테스트를 통해 테스트 계획에 설명되지 않은 사례를 찾을 수 있습니다. 게다가 프로젝트를 모르는 사람들도 서비스 편의성에 대해 피드백을 줄 수 있어요.”

Antonina Tatchuk, 수석 편집자: “저는 테스터로서 직접 시험해 보는 것을 좋아했습니다. 이것은 완전히 다른 작업 스타일입니다. 당신은 시스템을 깨뜨리려고 하는 것이지 시스템과 친구가 되려고 하는 것이 아닙니다. 우리는 항상 동료들에게 테스트에 관해 질문할 기회가 있었습니다. 버그의 우선순위 지정에 대해 더 많이 배웠습니다(예를 들어, 나는 텍스트에서 문법 오류를 찾는 데 익숙하지만 그러한 버그의 "무게"는 매우 작습니다. 반대로 나에게 별로 중요하지 않은 것으로 보였던 것이 결국에는 즉시 수정된 심각한 버그입니다.)
행사에서 사람들은 테스트 이론을 요약했습니다. 이는 기술적인 지식이 없는 사람들에게 유용했습니다. 그리고 며칠 후 나는 "언제 어디서"라는 공식을 사용하여 다른 사이트를 지원하고 사이트에 대한 나의 기대와 현실을 자세히 설명하고 있다는 생각이 들었습니다.

결론

팀 생활을 다양화하고 싶다면 기능을 새롭게 살펴보고 미니를 준비하세요. "개밥은 직접 먹어라", 그러면 그러한 행사를 열어보고 함께 논의할 수 있습니다.

최고의 성능과 버그 감소!

출처 : habr.com