Стадії QA процесу

Аналіз вимог

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

Планування тестування

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

Дизайн тестів

На цій стадії тестувальники мають розробити тест кейси та чеклісти, які покривають всі вимоги до розробки програмного забезпечення. В тест кейсах мають бути чітко сформульовані кроки для перевірки тих чи інших сценаріїв, обов’язково вказаний очікуваний результат. Якщо потрібно, то мають бути вказані передумови, які потрібно виконати перед початком перевірки або ж підготовлені спеціальні тестові дані. Також на цій стадії важливо приміняти техніки тест дизайну та комбінаторики, про що я доречі багато розповідаю та на практиці показую на своєму курсі 👨‍💻. На цій стадії також розробляються сценарії для автоматизованого тестування та пишуться API тести для кожного ендпоінта.

Виконання тестів та заведення баг репортів

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

Ретестування та регресійне тестування

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

Тест репорт

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