Тестування — це спосіб мислення. Як цей принцип дозволяє подолати труднощі в роботі

Тестування — це не просто тести. Це спосіб мислення. Саме цьому принципу й присвячено мою статтю. Спираючись на власний досвід, я, Гліб Остапенко, QA в IT-команді NIX, розповім, як варто підходити до роботи QA, щоб уникнути потенційних проблем на проєкті.

«Знати» та «усвідомлювати» — різні речі. Замало просто знати. Треба переконатися у правильності знань на практиці. Тестування саме про це. Для мене професія QA є способом мислення, який виступає головним інструментом в роботі. На власному досвіді я переконався: цей хист вирішує чимало проблем.

Усі проблеми на проєкті можна поділити на дві категорії: зовнішні та внутрішні. Перші зумовлені технічними питаннями та організацією робочого процесу. Другі — стосуються нас самих. Внутрішні проблеми на 100% залежать від нас, тому їх легше вирішити, ніж зовнішні. Давайте з усім цим розберемось детальніше.

Позбавляємось внутрішніх бар'єрів

Неуважність

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

Обмаль знань

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

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

Відсутність комунікабельності

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

Підписуйтеся на наші соцмережі

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

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

Йдеться про теми, які ви маєте знати, попри те, що ви джун. Деякі відповіді можна легко знайти у технічній документації або почути на початкових мітингах. Пам'ятайте: всі ваші колеги зайняті своїми справами. Постійно висмикувати когось із робочого процесу заради банальних питань недоречно. Спочатку вам скоріше дадуть відповідь із ввічливості, зважаючи на те, що ви нещодавно в команді. Потім, можливо, і ще кілька разів спрацює. Та регулярні питання про базові речі можуть сформувати в колег негативне уявлення про ваші здібності.

Щоб розмежувати (не)потрібні питання, уявіть собі сферу знань певного завдання. Розділимо її дві частини: синю та червону. Синя область покриває незнайомі вам знання, а червона — відомі. Коли ви тільки беретесь за роботу, то нічого не знаєте і перебуваєте у центрі сфери. Поки що для вас вона вся синя. Вивчаючи технічну документацію, червона зона знань, мов ядро, зростає. В якийсь момент ви досягнете «стелі» — бачите, що поточних знань для вирішення проблеми вам не вистачає. Саме тут варто звернутися про допомогу до колег. Це і є межа, що відокремлює слушні питання від непотрібних.

Невпевненість і страх

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

Розумію, це просто лише на словах. Будьте готові, що вам знадобиться час, чимало зусиль і терпіння. Треба буде призвичаїтись до проєкту, знайти спільну мову з командою, вивчити багато документації, опанувати нові інструменти. Але воно того варте, адже в підсумку ви станете класним QA. Вам як інженеру варто стежити не лише за якістю продукту, а й за рівнем власної кваліфікації.

Долаємо зовнішні проблеми

З ними рідше стикаються початківці і регулярно — досвідчені фахівці. Найбільш актуальними причинами таких проблем виступають:

Різниця в часових поясах

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

Як діяти? Можна заварити міцної кави і все-таки дочекатися відповіді пізно ввечері. Однак я б не назвав такі овертайми оптимальним рішенням. Якщо подібне спілкування з розривом у часі увійде в норму — фактично це перший крок до того, щоб перестати любити свою роботу. Краще попередити екстрену ситуацію. Намагайтеся дивитися на завдання ширше і заздалегідь побачити можливі прогалини. Тут допоможе уважне вивчення технічної документації, відстеження всіх процесів на проєкті, вміння ставити слушні питання у потрібний час. Так ви зможете виокремити слабкі місця та вимагати від людей уточнення не в останню мить. Одразу скажу: це не панацея. Цілко від прогалин ніхто не застрахований. Однак мінімізувати їх ймовірність та наслідки вам цілком до снаги.

Помилки не лише в ПЗ

Тестувальник може зіткнутися з помилками не тільки в програмі, а будь-де. Наприклад, у тестах іншого тестувальника. Тому я рекомендую впроваджувати на проєкті рев'ю технічної документації. Трапляються помилки і в робочому процесі. Скажімо, менеджер може призначити вам два важливі мітинги в один і той самий час. Помилки трапляються навіть у вимогах, які, здавалося б, мають бути догмою для тестувальника. Та інколи бізнес-аналітик чи інший QA припускається помилки під час написання документації. Ми всі люди, помиляється кожен. Тож і до цього треба бути готовим.

Робіть висновки не з прочитаного, побаченого чи почутого, а за результатами власного аналізу. Щоразу при вивченні вимог чи документації подумайте: чи логічні вони? Мені згадується дуже слушна фраза: правда завжди логічна, нелогічна лише неправда. У будь-якому документі шукайте логічні помилки. Якщо помітили хоча б один суперечний момент, копніть глибше. Можливо, там знайдеться чиясь помилка.

Відсутність вимог

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

Блокери

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

Постійні оновлення

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

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

Короткий висновок

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

Підписуйтеся на наші соцмережі