Бид яагаад тестерүүдэд зориулсан хакатон зохион байгуулсан бэ?

Энэ нийтлэл нь бидэнтэй адил сорилтын чиглэлээр тохирох мэргэжилтэн сонгох асуудалтай тулгарсан хүмүүст сонирхолтой байх болно.

Хачирхалтай нь, манай бүгд найрамдах улсад мэдээллийн технологийн компаниудын тоо нэмэгдэхийн хэрээр зөвхөн зохистой програмистуудын тоо нэмэгдэж байгаа боловч шалгагч биш юм. Олон хүмүүс энэ мэргэжлийг эзэмшихийг хүсч байгаа ч түүний утгыг ойлгодоггүй.
Бид яагаад тестерүүдэд зориулсан хакатон зохион байгуулсан бэ?
Би бүх мэдээллийн технологийн компаниудын талаар ярьж чадахгүй ч бид чанарын мэргэжилтнүүддээ QA/QC-ийн үүргийг өгсөн. Тэд хөгжүүлэлтийн багийн нэг хэсэг бөгөөд судалгаанаас эхлээд шинэ хувилбар гаргах хүртэлх хөгжлийн бүх үе шатанд оролцдог.

Багийн шалгагч нь төлөвлөлтийн үе шатанд ч гэсэн хэрэглэгчийн түүхийг хүлээн зөвшөөрөх бүх функциональ болон функциональ бус шаардлагыг сайтар бодож үзэх ёстой. Тэрээр программистуудын нэгэн адил бүтээгдэхүүний үйл ажиллагааны шинж чанарыг ойлгох ёстой, тэр ч байтугай төлөвлөлтийн үе шатанд ч буруу шийдвэр гаргахгүй байхад нь туслах ёстой. Шалгагч нь хэрэгжсэн функц хэрхэн ажиллах, ямар бэрхшээл тулгарч болох талаар тодорхой ойлголттой байх ёстой. Манай шалгагч нар өөрсдөө туршилтын төлөвлөгөө, туршилтын тохиолдлуудыг бий болгохоос гадна шаардлагатай бүх шалгалтын вандан сандал бэлтгэдэг. Сармагчин дарагч гэх мэт бэлэн техникийн дагуу туршилт хийх нь бидний сонголт биш юм. Багийн дотор ажиллаж байхдаа тэрээр зохистой бүтээгдэхүүн гаргахад туслах ёстой бөгөөд ямар нэг зүйл буруу болвол цаг тухайд нь дохио өгөх ёстой.

Тестер хайж байхдаа бидэнд юу тохиолдсон бэ

Олон анкет судлах үе шатанд бидэнд тохирсон туршлагатай мэргэжилтнүүд байгаа бөгөөд манай багт шалгагч сонгоход асуудал гарахгүй байх шиг байна. Гэхдээ хувийн уулзалтуудын үеэр бид мэдээллийн технологийн ертөнцөөс нэлээд хол байсан нэр дэвшигчидтэй уулзах нь улам бүр нэмэгдсээр байна (жишээлбэл, тэд хөтөч ба вэб серверийн харилцан үйлчлэлийн зарчмууд, аюулгүй байдлын үндсүүд, харилцаа холбоо, харилцаа холбоогүй байдлын талаар хэлж чадахгүй байв. харилцааны мэдээллийн сангууд, тэд виртуалчлал болон контейнержуулалтын талаар ямар ч ойлголтгүй байсан), гэхдээ тэр үед өөрсдийгөө Ахлах QA түвшинд үнэлдэг. Олон арван ярилцлага хийсний дараа бид бүс нутагт тохирох мэргэжилтнүүдийн тоо бараг байхгүй гэсэн дүгнэлтэд хүрсэн.

Дараа нь би та бүхэнд чанарын төлөө удаан хүлээсэн тулаанчдыг олохын тулд ямар алхам хийж, ямар алдаа гаргаснаа хэлэх болно.

Бид нөхцөл байдлыг хэрхэн засах гэж оролдсон

Бид бэлэн мэргэжилтнүүдээ хайж ядаж, ойролцоох газруудыг онилж эхлэв.

  1. Бид үнэлгээний практикийг ашиглахыг хичээж, олон тооны "үлдээд" байгаа хүмүүсийн дундаас хүчирхэг мэргэжилтэн бэлтгэж чадах хүмүүсийг тодорхойлохыг хичээсэн.

    Бид ижил түвшний мэдлэгтэй боломжит нэр дэвшигчдээс даалгавраа биелүүлэхийг хүссэн. Тэдний сэтгэх үйл явцыг ажиглаж, бид хамгийн ирээдүйтэй нэр дэвшигчийг тодруулахыг хичээсэн.

    Ялангуяа бид анхаарал болгоомжтой байх, технологийн чадавхи, олон соёлт үзлийн шинж чанарыг ойлгох чадварыг шалгах даалгавруудыг дэвшүүлсэн.

    Бид яагаад тестерүүдэд зориулсан хакатон зохион байгуулсан бэ?
    Бид яагаад тестерүүдэд зориулсан хакатон зохион байгуулсан бэ?

  2. Бид одоо байгаа бүрэлдэхүүний дунд мэргэжлийн талаарх ойлголтын хил хязгаарыг өргөжүүлэхийн тулд тестерүүдэд зориулсан уулзалт зохион байгуулсан.

    Би тус бүрийн талаар бага зэрэг хэлье.

    Уфа Програм хангамжийн QA болон Туршилтын №1 уулзалт бол мэргэжилдээ санаа тавьдаг хүмүүсийг цуглуулж, бидний тэдэнд юу хүргэхийг олон нийт сонирхож байгаа эсэхийг ойлгох анхны оролдлого юм. Үндсэндээ бидний тайлангууд хэрэв та тестер болохоор шийдсэн бол хаанаас эхлэх нь дээр вэ гэсэн мэдээлэл байсан. Эхлэгчдэд нүдээ нээж, насанд хүрсэн хүн шиг тестийг харахад туслаарай. Шинэхэн тестчид энэ мэргэжлээр элсэхийн тулд хийх ёстой алхамуудын талаар бид ярилцлаа. Чанар гэж юу вэ, түүнд бодит нөхцөлд хэрхэн хүрэх талаар. Мөн автомат туршилт гэж юу вэ, хаана ашиглах нь илүү тохиромжтой.

    Бид яагаад тестерүүдэд зориулсан хакатон зохион байгуулсан бэ?

    Тэгээд 1-2 сарын завсарлагатайгаар дахин хоёр уулзалт хийсэн. Оролцогчид аль хэдийн хоёр дахин их байсан. "Уфа Програм хангамжийн QA ба Туршилтын 2-р уулзалт" дээр бид сэдвийн талбарт илүү гүнзгий орсон. Тэд алдаа хянах систем, UI/UX тестийн талаар ярилцаж, Docker, Ansible-ийн талаар хөндөж, мөн хөгжүүлэгч болон тестер хоёрын хооронд гарч болзошгүй зөрчилдөөн, тэдгээрийг шийдвэрлэх арга замын талаар ярилцав.

    Бидний гурав дахь уулзалт болох "Уфа Програм хангамжийн QA ба Туршилтын уулзалт №3" нь тестерүүдийн ажилтай шууд бус холбоотой боловч програмистуудад техникийн болон зохион байгуулалтын үүргээ цаг тухайд нь сануулахад тустай байсан: ачааллын тест, e2e тест, автомат тестийн Selenium, вэб програмын эмзэг байдал .

    Энэ бүх хугацаанд бид арга хэмжээнээсээ нэвтрүүлэгт хэвийн гэрэл, дуу чимээг хэрхэн бий болгох талаар суралцсан.

    → Туршилтын эхний алхамууд - Уфа Програм хангамжийн QA ба Туршилтын уулзалт №1
    → UI/UX тест – Уфа Програм хангамжийн QA ба Туршилтын уулзалт №2
    → Аюулгүй байдлын туршилт, ачааллын туршилт, автомат туршилт - Уфа QA ба Туршилтын уулзалт №3

  3. Эцэст нь бид тестерүүдэд зориулсан хакатон зохион байгуулахаар шийдсэн

Бид тестерүүдэд зориулсан хакатоныг хэрхэн бэлтгэж, явуулсан

Эхлэхийн тулд бид энэ нь ямар төрлийн "араатан" бөгөөд үүнийг ихэвчлэн хэрхэн хийдэгийг ойлгохыг хичээсэн. ОХУ-д ийм төрлийн арга хэмжээ тийм ч олон удаа зохион байгуулагдаагүй бөгөөд санаа авах газар байдаггүй. Хоёрдугаарт, би анх харахад эргэлзээтэй мэт санагдсан үйл явдалд маш их хөрөнгө оруулалт хийхийг хүсээгүй. Тиймээс бид богино хэмжээний мини-хакатонуудыг QA ажлын бүх мөчлөгт биш, харин тус тусад нь хийхээр шийдсэн.

Бидний гол толгойны өвчин бол орон нутгийн тестерүүд тестийн тодорхой газрын зураг гаргах дадлага дутмаг байдаг. Тэд ашиглалтын өмнөх хэрэглэгчийн түүхийг судлах, функциональ болон функциональ бус шаардлага, UI/UX, аюулгүй байдал, ажлын ачаалал, оргил ачааллын хувьд хөгжүүлэгчдэд ойлгомжтой байх шалгууруудыг бий болгоход цаг зарцуулдаггүй. Тиймээс бид анх удаа тэдний ажлын хамгийн сонирхолтой, бүтээлч хэсэг болох төслийн өмнөх судалгааны явцад дүн шинжилгээ хийх, шаардлагыг бүрдүүлэхээр шийдсэн.

Бид оролцогчдын боломжит тоог тооцоолж, MVP гаргахад хамгийн багадаа 5 хоцрогдол, 5 бүтээгдэхүүн, бүтээгдэхүүний эзэмшигчийн үүргийг гүйцэтгэж, бизнесийн хэрэгцээг тайлж, хязгаарлалтын талаар шийдвэр гаргах 5 хүн хэрэгтэй гэж шийдсэн.

Эндээс бидэнд юу байна: хакатоны хоцрогдол.

Гол санаа нь оролцогчдын өдөр тутмын ажлаас аль болох хол байгаа сэдвүүдийг гаргаж, тэдэнд уран сэтгэмжийн боломжийг олгох явдал байв.

Бид яагаад тестерүүдэд зориулсан хакатон зохион байгуулсан бэ?

Бид яагаад тестерүүдэд зориулсан хакатон зохион байгуулсан бэ?

Бид ямар алдаа гаргасан, юуг илүү сайн хийж чадах вэ?

Худалдагч, доод түвшний менежерүүдийг ажилд авах чиглэлээр маш их алдартай үнэлгээний практикийг ашиглах нь асар их хүчин чармайлт гаргасан боловч оролцогч бүрт хангалттай анхаарал хандуулж, түүний чадварыг үнэлэх боломжийг бидэнд олгосонгүй. Ерөнхийдөө энэ сонголт нь компанийн сөрөг дүр төрхийг бий болгодог, учир нь маш олон хүмүүс хангалтгүй санал хүсэлтийг хүлээн авч, улмаар өөртөө болон бусдад ажил олгогчийн дарангуйллын үр дагаврыг бий болгодог (МТ-ийн нийгэмлэгийн харилцаа холбоо маш их хөгжсөн). Үүний үр дүнд бид маш хол ирээдүйтэй хоёр нэр дэвшигчтэй үлдлээ.

Уулзалт бол сайн зүйл. Боловсруулах өргөн үндэслэл бий болж, оролцогчдын ерөнхий түвшин нэмэгддэг. Тус компани зах зээлд улам бүр танигдаж байна. Гэхдээ ийм төрлийн ажилчдын хөдөлмөрийн эрч хүч тийм ч бага биш юм. Уулзалт хийхэд жилд ойролцоогоор 700-800 хүн цаг зарцуулагдана гэдгийг та тодорхой ойлгох хэрэгтэй.

Туршилтын хакатоны тухайд. Хөгжүүлэгчид зориулсан хакатонуудаас ялгаатай нь эдгээр арга хэмжээнүүд нь тийм ч бага байдаг тул уйтгартай болоогүй байна. Энэхүү санааны давуу тал нь тайван байдлаар та их хэмжээний практик мэдлэг солилцож, оролцогч бүрийн түвшинг маш нарийн тодорхойлох боломжтой юм.

Үйл явдлын үр дүнд дүн шинжилгээ хийсний дараа бид маш их алдаа гаргасан гэдгээ ойлгосон.

  1. Бидний хувьд 4-5 цаг хангалттай гэж итгэсэн нь хамгийн уучилж боломгүй алдаа байсан. Үүний үр дүнд зөвхөн танилцуулга, хоцрогдолтой танилцахад бараг 2 цаг зарцуулсан.
    Бүтээгдэхүүний эзэдтэй эхний шатанд ажиллах, тухайн сэдэв рүү ороход ижил хэмжээний цаг зарцуулсан. Тиймээс үлдсэн хугацаа нь туршилтын газрын зургийг иж бүрэн боловсруулахад хангалтгүй байсан нь тодорхой байна.
  2. Аль хэдийн шөнө болсон тул газрын зураг бүр дээр дэлгэрэнгүй санал хүсэлт гаргахад хангалттай цаг хугацаа, хүч чадал байхгүй байв. Тиймээс бид энэ хэсгийг бүтэлгүйтсэн нь тодорхой боловч анх хакатон дахь хамгийн үнэ цэнэтэй хэсэг байхаар төлөвлөж байсан.
  3. Бид хөгжлийн чанарыг бүх оролцогчдын энгийн санал хураалтаар үнэлэхээр шийдсэн бөгөөд баг тус бүрт 3 саналыг хуваарилж, хамгийн өндөр чанартай ажилд өгөх боломжтой. Шүүгчдийн бүрэлдэхүүнийг зохион байгуулсан нь дээр байх.

Та юунд хүрсэн бэ?

Бид асуудлаа хэсэгчлэн шийдэж, 4 хөгжлийн багийн ар талыг хамарсан зоригтой, царайлаг 4 залуу ажиллаж байна. Болзошгүй хүчтэй нэр дэвшигчдийн томоохон нөөц, хотын чанарын хяналтын нийгэмлэгийн түвшинд мэдэгдэхүйц өөрчлөлт гарахыг хараахан анзаараагүй байна. Гэхдээ зарим нэг ахиц дэвшил байгаа бөгөөд энэ нь баярлахаас өөр аргагүй юм.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх