Дякую! Гарна стаття:)

Дякую за запитання!

Типу обидва типи тестування проводяться після виявлення помилок?

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

Моє бачення:
регрешн після зміни. Якщо регрешн знайшов баг, то після фікса проводимо ретестінг

Погоджуюсь з вашим баченням.
Re-testing також може бути після регресії, для дефектів, які були виявленні під час регресії.

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

Так

Дякую за питання. Мала на увазі неможливість автоматизувати Retesting тестування.

Дякую вам! 🙂