Що робить тестувальник? Приклад.

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

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

Більше прикладів розбираємо на наших заняттях у IT Testing School. І, якщо ви зрозумієте, що тестування - професія саме для вас, то рекомендуємо записатися на наш курс "Тестувальник з нуля", де ми детально вивчаємо всі інструменти для роботи, розкладаємо всі ваші запитання по поличках, даємо тільки необхідні знання без води і робимо із вас професіоналів своєї справи.
Перший крок до тестування – аналіз вимог.

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

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


Далі план тестування (документ, який описує весь обсяг тестування) складається старшим менеджером з тестування (Team Lead QA), він також розподіляє бюджет на тестування, складає графіки тестування, розподіляє ролі між молодшим персоналом (коли в команді кожен тестувальник виконує лише певні перевірки: тестування безпеки, тестування юзабіліті, функціональне тестування та інші).

Сценарії тестування.

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

Сценарії тестування роблять виходячи з функціонала користувача, тобто цей тип документа є поверховим і не вимагає спеціалізованих знань. Наочним прикладом пункту зі сценарію тестування буде: "Протестувати форму реєстрації на сайті для ____ девайсів, ____ операційних систем, ____ браузерів."

Чек-листи і тест-кейси перевірок.

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

  1. Перевірити поля користувача на введення нестандартних символів (; / : " * & та інші).
  2. Перевірити відсутність введення доменної форми у рядку адреси електронної пошти.
  3. Перевірити виконання входу без реєстрації.
  4. Перевірити виведення інформації про помилки під час введення неправильних даних у форми.
  5. Перевірити заповнення лише обов'язкових форм для реєстрації.
  6. Перевірити чек-бокси (наприклад, форма "запам'ятати мене" під час реєстрації та відтворення під час авторизації, інші).
  7. Перевірити орфографії у формі авторизації.
  8. Тестування сумісності різної роздільної здатності екрану для девайсів, ОС, браузерів.
  9. Перевірити функціональності зміни мови.
  10. Перевірити швидкої авторизації через Google/Facebook/Telegram та інші.
У цьому чек-листі буде значно більше перевірок. Вони складаються для кожного елементу, який підлягає тестуванню. Документ з тест-кейсами або чек-листами вноситься до Testrail або TestLink для зручності роботи з перевірками. У деяких компаніях тест-кейси зберігають у Confluence або в Google-таблицях (що ми не дуже рекомендуємо робити).

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

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

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

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

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

Важливою складовою звітності для Team Lead QA є збір метрик тестування та їх аналіз. Деякі з метрик вимірюють ефективність як тестувальників, так і команди проекту в цілому. Обговорення метрик виноситься на мітинги та розглядається для покращення якості роботи.

Вище перераховано, що робить тестувальник на прикладі та його основні обов'язки на проекті. У деяких моментах ми згадали роботу Team Lead QA, оскільки не у всіх командах він може бути присутнім. Якщо ж ви потрапляєте на проект, де є єдиним тестувальником, то цей функціонал також буде вашим. Не варто цього боятися, оскільки у вас не буде ментора, який вам допомагатиме і коригуватиме всю роботу на початковому етапі.

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

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

З усіх питань зв'яжіться з нами будь-яким зручним способом:

Телефони:
E-mail:
Ми в соцмережах: