테스터를 대상으로 해커톤을 개최한 이유는 무엇인가요?

이 기사는 우리처럼 테스트 분야에서 적합한 전문가를 선택하는 문제에 직면한 사람들에게 흥미로울 것입니다.

이상하게도 우리 공화국의 IT 회사 수가 증가함에 따라 합당한 프로그래머의 수만 증가하고 테스터의 수는 증가하지 않습니다. 많은 사람들이 이 직업에 관심을 갖고 있지만 그 의미를 이해하는 사람은 많지 않습니다.

모든 IT 회사를 대변할 수는 없지만 QA/QC 역할을 품질 전문가에게 맡겼습니다. 이들은 개발팀의 일원이며 연구부터 새 버전 출시까지 개발의 모든 단계에 참여합니다.

팀의 테스터는 계획 단계에서도 사용자 스토리를 수용하기 위한 기능적, 비기능적 요구 사항을 모두 생각해야 합니다. 프로그래머는 물론, 제품의 운용 특성을 더 잘 이해하고, 기획 단계에서도 팀이 잘못된 결정을 내리지 않도록 도와주어야 합니다. 테스터는 구현된 기능이 어떻게 작동하는지, 어떤 위험이 있을 수 있는지를 명확하게 이해하고 있어야 합니다. 우리 테스터들은 스스로 테스트 계획과 테스트 케이스를 만들고 필요한 모든 테스트 벤치를 준비합니다. 원숭이 리모콘처럼 미리 만들어진 사양에 따라 테스트하는 것은 우리의 선택 사항이 아닙니다. 그는 팀 내에서 일하면서 가치 있는 제품을 출시하도록 돕고 문제가 발생하면 제때에 경보를 울려야 합니다.

테스터를 찾다가 만난 것

많은 이력서를 공부하는 단계에서 우리에게 적합한 경험을 가진 전문가가 있는 것 같았고 우리 팀의 테스터를 선택하는 데 문제가 없을 것 같았습니다. 그러나 개인 회의를 통해 우리는 실제로 정보 기술의 세계와는 거리가 먼 후보자를 점점 더 많이 만났습니다. 예를 들어 브라우저와 웹 서버 간의 상호 작용 원리, 보안의 기본, 관계형 및 비표준을 말할 수 없었습니다. 관계형 데이터베이스의 경우 가상화 및 컨테이너화에 대해 전혀 몰랐지만 동시에 수석 QA 수준에서 스스로를 평가했습니다. 수십 차례의 인터뷰를 진행한 결과, 우리는 해당 지역에서 우리에게 적합한 전문가의 수가 미미하다는 결론에 도달했습니다.

다음으로, 오랫동안 기다려온 품질 좋은 전투기를 찾기 위해 우리가 취한 조치와 밟은 실수에 대해 말씀 드리겠습니다.

우리가 상황을 해결하기 위해 어떻게 노력했는지

준비된 전문가를 소싱하는 데 지친 우리는 인근 지역을 목표로 삼기 시작했습니다.

1. 우리는 강력한 전문가를 양성할 수 있는 바로 그 사람들인 "떠나지 않는" 사람들 중에서 식별하기 위해 평가 관행을 적용하려고 노력했습니다.

   우리는 거의 동일한 수준의 지식을 가진 잠재적 후보자 그룹에게 작업을 완료하도록 요청했습니다. 그들의 사고방식을 관찰하면서 가장 유망한 후보자를 찾아내려고 노력했습니다.

   특히 우리는 주의력, 기술 역량 및 다문화주의의 특징에 대한 이해를 테스트하는 작업을 고안했습니다.

   
   

2. 기존 파견단의 직업에 대한 이해의 지평을 넓히기 위해 테스터들을 위한 모임을 개최했습니다.

   각각에 대해 조금 말씀 드리겠습니다.

   Ufa 소프트웨어 QA 및 테스트 모임 #1은 해당 직업에 관심이 있는 사람들을 모으는 동시에 우리가 전달하려는 내용에 대중이 관심을 가질 것인지 이해하려는 첫 번째 시도입니다. 기본적으로 우리의 보고서는 테스터가 되기로 결정한 경우 시작하는 것이 더 나은 곳에 관한 것입니다. 초보자가 눈을 뜨고 성인처럼 테스트를 볼 수 있도록 도와주세요. 우리는 초보 테스터가 직업에 합류하기 위해 취해야 할 단계에 대해 이야기했습니다. 품질이란 무엇이며 실제 조건에서 품질을 달성하는 방법에 대해 설명합니다. 또한 자동 테스트란 무엇이며 이를 사용하는 것이 더 적합한 곳은 어디입니까?

   
   
   그러다가 1~2개월 간격으로 2번의 모임을 더 열었습니다. 이미 참가자 수가 두 배나 많았습니다. "Ufa 소프트웨어 QA 및 테스트 모임 #XNUMX"에서 우리는 주제 영역에 대해 더 깊이 파고들었습니다. 버그 추적 시스템, UI/UX 테스트, Docker, Ansible에 대해 이야기하고, 개발자와 테스터 간에 발생할 수 있는 충돌과 해결 방법에 대해서도 이야기했습니다.

   세 번째 회의인 "Ufa 소프트웨어 QA 및 테스트 모임 #3"은 테스터의 작업과 간접적으로 관련되어 있지만 프로그래머에게 로드 테스트, e2e 테스트, 자동 테스트의 Selenium, 웹 애플리케이션 취약점과 같은 기술 및 조직적 의무를 적시에 상기시키는 데 유용했습니다. .

   지금까지 우리는 이벤트 방송에서 일반적인 빛과 소리를 만드는 방법을 배워왔습니다.

   → 테스트의 첫 번째 단계 – Ufa 소프트웨어 QA 및 테스트 모임 #1
   → UI/UX 테스트 – Ufa 소프트웨어 QA 및 테스트 모임 #2
   → 보안 테스트, 부하 테스트 및 자동 테스트 – Ufa QA 및 테스트 모임 #3

3. 그리고 결국 우리는 테스터들을 위한 해커톤을 개최하기로 결정했습니다.

테스터를 위한 해커톤을 준비하고 진행한 방법

우선, 우리는 이것이 어떤 종류의 "짐승"인지, 그리고 그것이 일반적으로 어떻게 수행되는지 이해하려고 노력했습니다. 결과적으로 이런 종류의 행사는 러시아 연방에서 여러 번 개최되지 않았으며 아이디어를 빌릴 곳이 없습니다. 둘째, 언뜻보기에 의심스러워 보이는 이벤트에 많은 자원을 즉시 투자하고 싶지 않았습니다. 그래서 전체 QA 업무 주기가 아닌 개별 단계별로 짧은 미니 해커톤을 진행하기로 결정했습니다.

우리의 주요 골칫거리는 명확한 테스트 맵을 만드는 데 있어 현지 테스터 간의 연습이 부족하다는 것입니다. 그들은 구현 전 사용자 스토리를 조사하고 기능적 및 비기능적 요구 사항, UI/UX, 보안, 작업 부하 및 최대 부하에 대해 개발자에게 명확한 수용 기준을 만드는 데 시간을 소비하지 않습니다. 따라서 우리는 처음으로 작업에서 가장 흥미롭고 창의적인 부분인 프로젝트 전 조사 중 요구 사항 분석 및 형성을 수행하기로 결정했습니다.

우리는 잠재적인 참가자 수를 추정하고 MVP 릴리스를 위한 최소 5개의 백로그, 5개의 제품, 제품 소유자 역할을 하고 비즈니스 요구 사항을 파악하고 제한 사항에 대한 결정을 내릴 5명의 사람이 필요하다고 결정했습니다.

우리가 얻은 것은 다음과 같습니다. 해커톤 백로그.

주요 아이디어는 가능한 한 모든 참가자의 일상 업무와 동떨어진 주제를 제시하고 그들에게 창의적인 상상력을 발휘할 수 있는 여지를 제공하는 것이었습니다.

우리는 어떤 실수를 했고, 무엇을 더 잘할 수 있었나요?

영업 사원 및 하위 관리자 채용 분야에서 널리 사용되는 평가 관행을 사용하려면 엄청난 노력이 필요했지만 각 참가자에게 충분한 관심을 기울이고 그의 능력을 평가할 수 없었습니다. 일반적으로 이 선택 옵션은 많은 사람들이 불충분한 피드백을 받고 결과적으로 자신과 다른 사람들에게 고용주의 폭정 효과를 생성하기 때문에 회사에 대한 부정적인 이미지를 만듭니다(IT 커뮤니티의 커뮤니케이션은 매우 발달되어 있습니다). 결과적으로, 우리에게는 문자 그대로 매우 먼 미래를 가진 두 명의 잠재적 후보가 남게 되었습니다.

모임은 좋은 것입니다. 광범위한 정교화 기반이 마련되고 참가자의 전반적인 수준이 높아집니다. 회사는 시장에서 점점 더 인지도를 얻고 있습니다. 그러나 그러한 사업의 노동 강도는 적지 않습니다. 모임을 개최하는 데 연간 약 700~800인시가 소요된다는 점을 분명히 이해해야 합니다.

테스트 해커톤에 관해서. 이러한 종류의 이벤트는 개발자를 위한 해커톤과 달리 개최 빈도가 훨씬 적기 때문에 아직 지루하지 않습니다. 이 아이디어의 장점은 편안한 방식으로 많은 양의 실무 지식을 교환하고 각 참가자의 수준을 매우 정확하게 결정할 수 있다는 것입니다.

이벤트 결과를 분석한 결과, 우리가 실수를 많이 했다는 것을 깨달았습니다.

1. 가장 용서할 수 없는 실수는 4~5시간이면 충분할 것이라고 믿는 것이었습니다. 결과적으로 백로그 소개와 숙지에만 거의 2시간이 걸렸습니다.
   초기 단계에서 제품 소유자와 작업하고 주제 영역을 자세히 살펴보는 데에도 같은 시간이 걸렸습니다. 따라서 남은 시간은 테스트 맵을 포괄적으로 개발하는 데 분명히 충분하지 않았습니다.
2. 이미 밤이 되었기 때문에 각 맵에 대한 자세한 피드백을 받을 시간과 에너지가 부족했습니다. 따라서 이 부분은 분명히 실패했지만, 애초에는 해커톤에서 가장 가치 있는 부분을 목표로 삼았습니다.
3. 우리는 모든 참가자의 간단한 투표로 개발 품질을 평가하기로 결정했으며 각 팀에 3표를 할당하여 최고 품질의 작업에 부여할 수 있었습니다. 아마도 배심원을 조직하는 것이 더 나을 것입니다.

당신은 무엇을 달성했나요?

우리는 문제를 부분적으로 해결했으며 이제 4명의 용감하고 잘생긴 남성이 우리를 위해 일하고 4개의 개발 팀의 후방을 담당하고 있습니다. 잠재적으로 유력한 후보자들의 상당한 풀과 도시 QA 커뮤니티 수준의 실질적인 변화는 아직 발견되지 않았습니다. 그러나 약간의 진전이 있으며 이는 기뻐할 수밖에 없습니다.

출처 : habr.com