Джерело
Затишна Галера | ЧарівнийКомпас 🧭2️⃣5️⃣5️⃣️️ Завдання 255Чим відрізняються soft delete ...
474 Охват/переглядів
2026-10-12 14:14
Повідомлення №3043
#ЧарівнийКомпас 🧭
2️⃣5️⃣5️⃣️ ️ Завдання 255
Чим відрізняються soft delete і hard delete з точки зору тестування?
Закриваємо нашу пʼятірку питань з QA теорії.
🤔 Hard delete - це фізичне видалення запису з бази даних.
Наприклад, якщо ми видалили користувача через hard delete, запис про нього більше не існує в таблиці. Відновити його можна тільки з бекапу або інших джерел, якщо вони є.
При тестуванні hard delete звертаємо увагу на:
➖ запис дійсно видалений з бази;
➖ він більше не повертається через API;
➖ його немає в UI, пошуку та списках;
➖ правильно оброблені пов’язані дані;
➖ немає orphan records (записи-сироти для кого цей запис був батькивскьим);
➖ повторне видалення обробляється коректно;
➖ видалення не ламає історичні дані та залежності.
🤔 Soft delete - запис фізично залишається в базі, але позначається як видалений.
Наприклад, це може бути поле is_deleted = true, статус deleted або deleted_at з датою видалення або інші варіанти.
Тут тестування складніше, тому що потрібно перевірити не тільки сам факт «видалення»:
➖ запис залишився в базі та отримав правильний статус;
➖ він більше не відображається користувачу там, де не повинен;
➖ API за замовчуванням не повертає soft-deleted записи;
➖ пошук, фільтри, пагінація і статистика їх правильно виключають;
➖ пов’язані сутності поводяться коректно;
➖ якщо підтримується відновлення запису - запис можна правильно відновити;
➖ повторне створення сутності з тим самим унікальним значенням працює відповідно до бізнес-логіки (може бути по різному).
🤓 Наприклад, користувача soft delete видалили, але його email залишився в базі. Якщо система дозволяє зареєструвати нового користувача з таким самим email, це окремий сценарій, який обов’язково потрібно перевірити.
#️⃣ Hard delete - перевіряємо, що дані фізично зникли і залежності не зламалися.
#️⃣ Soft delete - перевіряємо, що дані залишилися в системі, але всюди правильно поводяться як видалені.
@Zatishna_Galera
2️⃣5️⃣5️⃣️ ️ Завдання 255
Чим відрізняються soft delete і hard delete з точки зору тестування?
Закриваємо нашу пʼятірку питань з QA теорії.
🤔 Hard delete - це фізичне видалення запису з бази даних.
Наприклад, якщо ми видалили користувача через hard delete, запис про нього більше не існує в таблиці. Відновити його можна тільки з бекапу або інших джерел, якщо вони є.
При тестуванні hard delete звертаємо увагу на:
➖ запис дійсно видалений з бази;
➖ він більше не повертається через API;
➖ його немає в UI, пошуку та списках;
➖ правильно оброблені пов’язані дані;
➖ немає orphan records (записи-сироти для кого цей запис був батькивскьим);
➖ повторне видалення обробляється коректно;
➖ видалення не ламає історичні дані та залежності.
🤔 Soft delete - запис фізично залишається в базі, але позначається як видалений.
Наприклад, це може бути поле is_deleted = true, статус deleted або deleted_at з датою видалення або інші варіанти.
Тут тестування складніше, тому що потрібно перевірити не тільки сам факт «видалення»:
➖ запис залишився в базі та отримав правильний статус;
➖ він більше не відображається користувачу там, де не повинен;
➖ API за замовчуванням не повертає soft-deleted записи;
➖ пошук, фільтри, пагінація і статистика їх правильно виключають;
➖ пов’язані сутності поводяться коректно;
➖ якщо підтримується відновлення запису - запис можна правильно відновити;
➖ повторне створення сутності з тим самим унікальним значенням працює відповідно до бізнес-логіки (може бути по різному).
🤓 Наприклад, користувача soft delete видалили, але його email залишився в базі. Якщо система дозволяє зареєструвати нового користувача з таким самим email, це окремий сценарій, який обов’язково потрібно перевірити.
#️⃣ Hard delete - перевіряємо, що дані фізично зникли і залежності не зламалися.
#️⃣ Soft delete - перевіряємо, що дані залишилися в системі, але всюди правильно поводяться як видалені.
@Zatishna_Galera