Чому тестувальники іноді нервують розробників і як цього уникнути?

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Про що стаття?

Розробка програмного забезпечення — це складний процес, який вимагає уваги, залученості та активності. Це стосується всіх членів команди. Коли хтось не дотримується вимог, інші відчувають на собі наслідки безвідповідального ставлення до своїх завдань.

Сьогодні я пропоную обговорити важливу тему спілкування між командами Розробників та Тестерів, зокрема, розглянути основні скарги розробників щодо роботи інженерів з якості, а також як їх вирішити, щоб уникнути конфліктів.

Трошки про авторку статті.

Мене звати Маша. Я працюю мануальним тестуальником більше 10 років. Починала в G5 закінчили свою карьеру в Ciklum як Lead QA та зараз працюю сама на себе, опоновуючи нову апрофесію. Але мій унікальгний досвід не може залишитися непоміченим, тому я вирішили ним поділитися.

Я зібрала підбірку невдоволень від розробників на підставі свого особистого досвіду спілкування з ними та опитування підписників у своєму Instagram: www.instagram.com/masha.it.travels

Отже, давайте розглянемо детальніше, що саме нервує розробників і як запобігти конфліктів та зменшити невдоволення.

Можливі конфлікти мід розробниками та тестувалниками та способи їх вирішити

Причина 1

Коли в баг-репорті відсутні чіткі описи кроків для відтворення проблеми, актуального та очікуваного результатів. Я додам, що це також дратує інших тестувальників, коли вони знову зіштовхуються з таким багом під час перевірки.

Рішення:

• розбийте кроки багу на менші, особливо, якщо ПЗ має нетривіальний інтерфейс;
• надайте якомога більше додаткової інформації, яка буде корисною розробникові та прискорить виправлення помилки (логи, скріншоті, мокапи, відповіді на запити, вибірки з бази даних тощо);
• додайте скріншоти не тільки актуального результату, але й проміжних кроків, якщо це необхідно для конкретного баг-репорту;
• іноді одного відео демонстрації проблеми вистачить замість тисячі скріншотів, щоб розробник зрозумів суть проблеми

Причина 2

Тестувальник дуже повільно проводить тестування та повільно створює баг-репорти та доповідає про помилку в останній момент.

Рішення:

• правильно розставте пріоритети своїх задач
• спершу створіть баг-репорт, не затримуючи роботу інших, а потім перейдіть до виконання своїх завдань по пріоритету
• якщо немає часу створювати баг-репорти, сповістіть розробника через корпоративний зв’язок, можливо, баг можна виправити вже під час роботи над ним
• Ідеальною була б ситуація, коли життєвий цикл багів був документований та озвучений всім членам команди, щоб зрозуміти, як діяти з багами, виявленими під час перевірки спринтів, регресій, смоук-тестувань та інших тестових активностей та уникнути витрачання часу та непорозумінь.

Причина 3

Коли тестери створюють купу баг-репортів, не переконавшись, що всі вони стосуються однієї й тієї ж проблеми, і достатньо було б просто додати коментар до вже існуючого бага, щоб не «захламлювати» простір.

Рішення:

можна позичити з попереднього пункту. Домовтеся і задокументуйте життєвий цикл бага на Confluence, включаючи всі статуси, мітки, компоненти та іншу інформацію, за якою можна знайти і відстежити існуючі баги, перевірити закритий баг або додати інформацію до існуючого, щоб уникнути дублікатів.

⠀

Причина 4

Тестувальник створює баг, який створений 100 років тому.

Рішення:

всі баги, що лежать у загальному беклозі, краще постійно моніторити. Час від часу проводьте очищення багів. Перевіряйте їх на актуальність. Баги повинні бути актуальними. Якщо баг старий, але не критичний і він дійсно заважає процесу тестування, варто підняти питання про його виправлення на одному з мітингів.

Причина 5

Тестувальник створює баг і лінкує його до поточної сторінки/задачі, яку тестує, хоча цей баг ніяким чином до неї не відноситься.

Рішення:

гарною практикою є лінкування багів до відповідного тестового кейсу, а тестових кейсів — до відповідних User Story. Тоді одразу стане зрозуміло, до якої сторінки відноситься цей баг, але для цього треба лінкувати ці кейси до сторінки на етапі тест-дизайну. Якщо ви не впевнені, куди лінкувати баг, обговоріть це з вашим РО. Якщо для багу немає тестового кейсу, краще додати такий кейс, лінкувати його до потрібної User Story і додати до регресійного списку, щоб перевірити його ще раз перед релізом.

⠀

Причина 6

Тестувальник чомусь вважає себе UI/UX дизайнером і створює баг, щоб виправити, з його точки зору, косметичний дефект, при цьому не знаючи жодного принципу дизайну.

Рішення:

добре, коли в команді є дизайнер, з ним завжди можна обговорити той або інший, на вашу думку, дефект. І від його рішення буде залежати, створювати баг-репорт з посиланням на його рішення чи ні. Якщо такої людини немає, всі ці, на вашу думку, UI/UX баги краще обговорювати з РО або ВА, і тільки після їх затвердження створювати баги. Гарною практикою є створити Google Doc або Excel для таких ситуацій і зазначати їх на ретро-мітингах.

⠀

Причина 7

Тестувальники створюють баги, пов’язані з логікою системи, не переконавшись у бізнес-аналітика або PO, чи є його припущення вірними.

Рішення:

ну тут рішення очевидне: спочатку обговоріть цей кейс з ВА або PO, потім створюйте баги або хоча б не відправляйте його відразу розробнику, якщо раптом поспішили створити баг-репорт. Після обговорення може виявитися, що цей кейс для імпрувмента або окремої User Story

Причина 8

Тестувальник тестує систему в останній день спринту або в ніч перед релізом.

Рішення: якщо тестувальник мав тиждень на регресію, а насправді тестувати він сів в ніч перед релізом, то це безвідповідальність тестувальника. Тім ліду краще тримати руку на пульсі і питати статус тестування у таких тестувальників заздалегідь.

Але трапляється і так, що баги дійсно знаходять під дату релізу, і тут треба швидко реагувати всім членам команди. Добре мати Mitigation Risk Plan, в якому буде прописано, що робити в цьому випадку (овертайми, зміна дати релізу тощо)

Причина 9

Тестувальник, пройшовши один курс на Udemy/прочитавши статтю на DOU/подивившись мануал на YouTube, починає надмірно підвищувати свої повноваження і захищати свою точку зору, грунтуючись лише на недавно отриманих знаннях, без досвіду впровадження цих знань.

Рішення:

амбіції — це добре, але все повинно бути в міру. Дуже похвально, що людина займається самоосвітою, дізнається новинки і взагалі не сидить на місці. Але висувати свої нові ідеї і пропозиції потрібно розумно. Діліться всім цим на спеціальних зборах для цього або ініціюйте самі обговорення нововведень з командою, а потім з замовниками. Не забувайте, що ви командний гравець, а не фрілансер.

Причина 10

Тестувальник «робить з мухи слона», нагороджуючи свій баг Critical або Blocker severity, хоча для цього немає явних передумов і замість менеджера або продакт-власника додає високий пріоритет, щоб його виправили якнайшвидше.

Рішення:

тестувальник може виставляти лише severity (серйозність) дефекту, а priority (пріоритет) — PO (продакт-власник). Так працює в ідеальному світі. На практиці ж ці обов’язки падають на тестувальника. Бувають неоднозначні дефекти і, щоб не помилитися, тестувальник виставляє більш високий пріоритет та серйозність багу. Якщо є такі сумніви, краще уточнювати це у тім лідера, РО або особи, відповідальної за ці обов’язки.

Причина 11

Тестувальник перебільшує проблему в багу під час спільних зустрічей з замовником, показуючи таким чином, що він знайшов «нереально серйозну» проблему, а розробники її чомусь не можуть виправити

Рішення:

покращуйте комунікацію в команді. Спілкуйтеся з девелоперами, донесіть цю проблему до тім ліда врешті решт. Старайтеся почути думку інших учасників проекту. Буде добре організувати спільний тімбілдинг та налагодити контакт. Чим ближчі відносини всередині команди, тим краще для проекту.

Причина 12

Тестувальник надто звертає увагу на «косметику» системи (кнопка не того розміру, колір не той або шрифт), ніж на функціональне тестування системи.

Рішення:

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

Я думаю, список можна ще доповнити, тому прошу вас написати це у коментарях.

Висновки:

Один мій знайомий розробник якось сказав дуже важливі слова «Більш за все в тестувальнику мене дратує відсутність PO або BA на проекті»

Наявність компетентного PO (власника продукту) або бізнес-аналітика на проекті дійсно важлива для успішної комунікації і взаєморозуміння між розробниками і тестувальниками.

PO або бізнес-аналітик повинні глибоко розуміти предметну область та потреби замовника. Їх роль полягає в формулюванні чітких вимог до продукту, створенні корисних сценаріїв тестування і плануванні пріоритетів роботи з розробниками і тестувальниками. Це допомагає уникнути непорозумінь і поглядів з різних точок зору на те, як має працювати продукт і які функції він має містити.

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

Вміння чітко і ефективно спілкуватися між собою допомагає вирішувати проблеми швидше і більш ефективно, забезпечує взаєморозуміння і збільшує продуктивність всієї команди.

Зважаючи на все сказане, можна підкреслити важливість роботи в команді, де всі учасники розуміють свої обов’язки, мають відповідні знання і комунікують один з одним. Це допомагає забезпечити успіх проекту, задоволення всіх учасників і виконання поставлених завдань в строк і з необхідною якістю.

Я дуже відкрито та правдиво розповідаю про работу в IT в своєму інстаграм.

Буду рада новим людям у себе в інста блозі @masha.it.travels www.instagram.com/masha.it.travels