1
5.0

Оцінити

Статті читати 3 хв. 5.0 4 голоси 5951

Від тест-кейса до баг-репорта: що повинен знати професійний тестувальник

Протягом 3 років я працював на посаді QA та вважаю, що в IT-індустрії тестувальник, будучи частиною scrum-команд, такий саме цінний, як і будь-який інший член команди.

Мені доводилося бачити різні аутсорсингові компанії, працюючі в сфері тестування, які надають повні інтенсивні учбові курси, щоб перетворити початківців в експертів QA. Більшість курсів QA здебільшого пов’язані з тестуванням ПО та ведуть до того, щоб у перспективі стати розробниками.

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

Основні навички тестування.

В якості базових знань студенти повинні вивчати тестові артефакти (тестову документацію) такі як: чек-лист, тест-кейс, тест-стратегія, тест-план, баг-репорт та тест-репорт.

Що це таке? Давайте розберемося коротко.

Базова теорія тестування

  • Чек-лист (Check list) — це набір тестових ідей; простий, іноді поверхневий, лаконічно (але інформативно) описаний список ідей для перевірок. В більшості випадків чек-лист використовується тестувальником як “чернетка”, щоб задокументувати всі ідеї та думки в голові, так як дуже часто продукти достатньо складні, з великою кількістю функцій, та кількість перевірок може досягати сотен, а такий об’єм інформації з деталями достатньо складно втримати в голові особисто мені.
  • Тест-кейс (Test case) — покроковий детальний опис перевірки, з таким рівнем деталізації, щоб будь-який студент першого курса зміг його виконати.
  • Тест-стратегія (Test strategy) — опис стратегії тестування. Мета її написання - документування того, як буде проходити процес тестування. Наприклад, дуже зручно новій людині на проекті (не тільки QA, але й розробнику, проектному менеджеру, бізнес-аналітику, тощо) дати її на читання, після чого людина буде мати загальне бачення та розуміння процесу тестування та як тестування взаємопов’язане з рештою процесів на проекті.
  • Тест-план (Test plan) — детальний опис процесу тестування. Звичайно це дуже об’ємний документ на шістдесят та більше сторінок. В наш час він майже не використовується (в класичному розумінні терміну існує декілька стандартів тест-планів з детальним описом того, що повинно бути задокументовано в тест-плані).
  • Баг-репорт (Bug report) — звіт про помилку/баг. Заводиться (записується) в результаті виконання тест-кейсів, або іншому її знаходженні: ми можемо побачити помилку і, не виконуючи тест-кейс, а випадково натрапивши на неї.
  • Тест-репорт (Test report) — звіт про виконання тест-кейсів, в ньому звичайно відмічається статистика, кількість виконаних тест-кейсів та кількість знайдених помилок.

Техники тест-дизайну

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

Класифікація тестування

Тестові активності можна класифікувати за різними параметрами, поділити на види, розкласти на класи, розподілити за уровнями, організувати в “родини” та інше.

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

Напрямки тестування ПЗ

Існує декілька основних напрямків тестування (в залежності від природи додатку): тестування мобільних додатків, тестування web-додатків, коли інтерфейс програм відображається в браузері, тестування desktop-додатків, які необхідно встановлювати у ОС. Також, можна виділити ще достатню кількість більш вузьких спеціалістів-інженерів, які забезпечують якість: перевірка ігор, перевірка безпеки, перевірка навантаження тощо.

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

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

По завершенні курса студенти повинні знаходити ефективні рішення проблем та спілкуватися зі всіма членами команди розробки однією мовою.

Agile та Scrum для QA-фахівця

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

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

Схожі матеріали

Подпишитесь на рассылку
Компьютерной школы Hillel

Ви отримаєте:

  • Інформацію про корисні галузеві заходи
  • Цікаві статті IT-сфери
  • Новини Комп'ютерної школи Hillel