Тестувальник vs розробник

Сьогодні я б хотів торкнутися теми процесу розробки програмного забезпечення. Якщо точніше, ця стаття про те «Як не перетворити офіс у полі битви тестувальників і розробників».

Півроку тому я поринув у тестування ПО, мені було цікаво і я зрозумів, що це справді моє. Годинами залипал на форумах тестувальників, читав літературу і вивчав процес розробки ПЗ. На форумах, в групах і бесідах я частенько помічав приколи про взаємодію тестувальників і розробників, але я не розумів цих жартів і не звертав на це увагу. Принаймні, поки не потрапив на стажування в одну компанію з розробки пз.

Через пару місяців я почав наздоганяти сенс цих приколів і активних обговорень «Tester vs Developer». Так як я був першим тестувальником в цій компанії, освоїтися було складно. Завдань з порожнім описом, але з назвами «протестуй та отпишись», «перевір сайт», «не працює додаток» не було кінця, а розробники і проджект менеджер взагалі не знали поняття QA. Всім знайома ця фраза «Без ТЗ – результат ХЗ», так от там було теж саме. Плюс до всього цього, нікого не хвилювало те, що продукт м'яко кажучи «кривоват». У більшість випадків було так: ти отримуєш завдання «перевір» — тестируешь, робиш звіт про знайдені дефекти і передаєш їх розробнику, ну а у розробника ця задача могла висіти місяцями. В результаті шеф вважав, що тестувальник в штаті зайвий і для мене цей кошмар закінчився, ну а продукт так і залишився «кривим».



Бувають різні спори, розбіжності, але мені здається, що вже давно пора придумати який-небудь простий підхід, щоб уникнути подібних випадків.

Скріншот з бесіди тестувальників З:



Знайти дефект — задокументувати — передати розробнику для виправлення. Але знову-таки, начебто все просто, якби не реакція розробника на свої помилки. Напевно він просто забув про те, що завдання тестувальника це пошук помилок і збоїв у функціонуванні об'єкта. У підсумку ми як дружнє співтовариство почали давати різні поради бідної пані. Багато пропонували вирішувати питання через тимлида, а деякі навіть пропонували набити обличчя за таке ставлення. Ну а я запропонував свій варіант, але багатьом він здався дивним.

Через деякий час я потрапив на один цікавий проект, в якому проджект менеджер був мостом між тестувальником і розробниками. Я не знаю, наскільки ця концепція ефективна, але ми за весь час жодного разу не посварилися. Як баг трекинговую систему ми використовували Trello. Ця система зручна тим, що вона вся побудована на основі дошки і все, що в ній є, знаходиться на одному екрані: і завдання, і історія змін, і будь-які коментарі. Але це ж і головний мінус програми. Вона дуже проста і не призначена для великих команд.

Від проджект менеджера прилітала завдання, під час тестування кожен баг оформлявся в окрему картку і прикріплявся у блок «Баги» з міткою «Недолік» і з докладним описом. Потім проджект менеджер ставив пріоритет картці і закидав одному з розробників. Іноді таке буває, що терміни горять і до зустрічі з замовником потрібно перевірити найважливіші моменти. У такому разі проджект менеджер ставив високий пріоритет багам пов'язаних з бізнес логікою, а баги пов'язані з UI відкладалися на потім. У багатьох виникне питання " Хто тоді буде відповідати за втрачені баги в прод? ", на жаль, ми сам не в курсі.

Найважливіше в такому процесі, це те, що тестувальник не взаємодіє з командою розробників, отже, ні криків, сварок і суперечок:

— Та це ж баг!
— Ні, це фіча!
<img src=«habrastorage.org/files/bb1/f8c/c30/bb1f8cc30a21462e87bd548a8effdc8d.png» alt=«image » alt" />
Якщо у вашій команді адекватний project manager або product owner, спробуйте протестувати такий підхід. Я думаю, що багатьом сподобається.

Звичайно ж, є компанії, у яких ставлення розробників і тестувальників ідеальне. Наприклад, в яких за втрачені баги в продакшн і скарги користувачів відповідає розробник. В такому випадку розробник сам буде зацікавлений у хороших відносинах з тестувальником. Але знову-таки виникає питання " А скільки компанії працюють за таким принципом? "



Всім дякую за увагу.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.