10 способів провалити проєкт

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

1. Нехтувати тайм-менеджментом

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

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

2. Концентруватися на одному виді тестування

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

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

3. Не приділяти увагу тестовій документації

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

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

4. Не запитувати і не робити висновки у процесі роботи

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

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

5. Не комунікувати з командою

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

Ефективна, оперативна та вичерпна комунікація є і завжди буде базовим принципом синергії командної роботи.

6. Сприймати команду як роботизоване обладнання

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

7. Тестувати поспіхом

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

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

8. Концентруватися на кількості знайдених дефектів, а не на якості 

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

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

9. Замовчувати особисті помилки

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

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

10. Зациклюватися на невдачах 

Дефекти, збої та баги неминучі. Саме через їх стабільне існування зародилася професія QA Engineer. Головною причиною дефектів можна назвати людський фактор, адже програмні продукти створюються людьми, тестуються людьми та використовуються людьми. Навіть у, здавалося б, ідеально протестованому програмному забезпеченні завжди будуть існувати баги. 

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

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