среда, 21 мая 2014 г.

Проверка удаления данных - что происходит с системой?

Что самое важное, что мы проверяем во время первого тестирования системы, регрессионного или smoke на PROD-е?

Операции CRUD - create, edit, update, delete. Это базовая функциональность многих приложений. И, если она у вас есть, обязательно ее проверяйте!

А мы сейчас, как вы, наверное, уже догадались, остановимся на операции delete.


Как ее нужно тестировать? Что проверять?

  • Само удаление - минимальная проверка.
  • Влияние на связанные сущности - интеграционная проверка. Был ли с чем-то связан удаленный объект? Не перекосило ли зависимую карточку?
  • Логирование (если есть) - запись действия в лог файл.
То есть, допустим, я некий провайдер, который обслуживает определенный район. У меня в системе учета есть карточки моих клиентов, которым я делаю рассылку счетов и акций по email, и карточки зданий, в которых есть мой интернет.

Так вот, в здании А у меня подключен только Иванов. И вот он приходит ко мне и говорит "Не хочу больше у вас интернет брать, я уезжаю в Штаты на ПМЖ". Я его карточку удаляю (ну вот такая у меня система, нету списка "бывших", всех удалять надо).

Что мы проверяем? Мы проверяем, что карточка Иванова действительно удалилась, то есть:
  1. Выполняем действия на открытой заранее карточке (открываем ее в двух вкладках браузера, в одной удаляем, во второй пытаемся что-то сделать) - прямая проверка удаленной сущности.
  2. Пытаемся открыть карточку по прямой ссылке, которая вела туда раньше - тоже прямая проверка.
  3. Поиск по фамилии Иванов - если он был один в системе, должен вернуть пустоту. Это уже косвенная проверка зависимой сущности - списка клиентов. Удаленная карточка была связана со списком, в котором отображалась, так что проверяем его обязательно.
  4. Проверка карточки здания - если у нас не может быть в системе здания, к которому никто не привязан, оно должно удалиться. Если может, то должно корректно отображаться без ошибок. Тоже косвенная проверка зависимой сущности (карточка клиента была связана с карточкой здания)
  5. Проверка того, что следующая рассылка почты НЕ уйдет на почту удаленного клиента. А то вдруг мы список для рассылки в другом месте храним, получается еще одна сущность, зависимая от карточек клиентов. И тоже косвенная проверка, но мега важная! Потому что клиент, разорвавший с нами контракт, врядли порадуется пришедшему ему счету за интернет Smile :)
Ну и в завершение этого поста-напоминалки расскажу историю из жизни (не зря же здесь стоит тег "повсюду баги"). Вчера удалила свой твит, на который ответили или ретвитнули. Сегодня наслаждаюсь залипанием уведомления. Оно горит "у тебя есть одно", переключаюсь на уведомления, там ничего нового. Возвращаюсь обратно, снова появляется "у тебя есть уведомление", вот, можно посмотреть на 11-секундном видео.

Так что, ребята, баги - они повсюду! Иногда даже не надо специально искать Smile :)
Поэтому отмазка начинающих "не знаю, где применить свои навыки" ни разу не отмазка - да везде!

3 комментария:

  1. Стоит еще добавить:
    * Проверку удаления также стоит проводить напрямую просматривая БД.
    * С объектами, связанными с удаляемым могут происходить разные вещи. Искать по "каскадное удаление".
    * В последнее время все больше систем, в которых данные не удаляются, а помечаются, как неактивные. Так гораздо проще.

    А вообще контроль целостности данных это весьма сложный вид тестирования.

    ОтветитьУдалить
    Ответы
    1. Да, согласна :)

      Просто доступ к БД есть не всегда, а неактивными тоже не везде делают, мой пример просто тестовый, там то понятно, что стоит сделать "неактивным" ))

      Удалить
  2. Ольга, прошу извинить за оффтоп: почему исчез предыдущий пост-разоблачение негодяя "тренера"? Он пообещал, что больше не будет?? )))

    ОтветитьУдалить