Какие тестовые сценарии для проверки обновлений ПО вы разрабатывали?

А, ну это ж классика, блядь! Обновления тестировать — это как в цирке с тиграми работать: одно неверное движение, и тебе уже не аплодируют, а звонят в скорую. Слушай, как это бывает на самом деле.

1. Прямое обновление (Incremental Update) Ну, то есть поставил новую версию поверх старой. Цель — не просрать всё, что у пользователя было. Вот он там год фотки котиков копил, настройки вылизывал, а ты пришёл со своим обновлением — и всё к хуям.

• Что проверяем, чтобы не стать врагом народа:
  • Данные пользователя на месте? Не слетели? Не превратились в кракозябры? Вот это вот «о, а где мой сохранённый пароль?» — это пиздец, а не баг.
  • Миграции базы данных прошли? Не получилось так, что вместо добавления колонки ты всю таблицу в рот себе завернул?

    -- Смотрим, новая колонка вообще жива? Или мы её только в миграции нарисовали, а заполнять забыли?
    SELECT COUNT(*) FROM users WHERE new_optional_column IS NOT NULL;

  • Всё после обновления работает? Не вылезла ошибка «Извините, но функция „сохранить“ теперь доступна только в премиум-версии, которую мы, блядь, ещё не написали»?

2. Откат обновления (Rollback) А это святое! Это твой щит и меч. Обновились — а там, сука, всё горит синим пламенем. Надо откатиться так, чтобы пользователь даже не спросил «а что это вы там обновляли-то?».

• Что проверяем:
  • Процедура отката не стирает фотки его тёщи с последнего корпоратива? Данные целы?
  • После отката система не лежит с сообщением «Версия 1.5 несовместима с вашими слезами, обновитесь до 2.0, от которой мы только что откатились»? Должно работать ровно так же, как и до всей этой движухи.

3. Совместимость (Backward/Forward Compatibility) О, ёпта, вот где начинается настоящая магия, а чаще — полная жопа. Представь: ты обновил сервер, а клиенты у половины пользователей старые. Или наоборот — выпустил крутого клиента, а сервер ещё старый.

• Цель: Чтобы они друг друга не послали нахуй при встрече. Чтобы новый клиент не требовал от старого сервера данных, которых у того отродясь не было. А старый клиент не падал в обморок, увидев ответ от нового сервера.

4. Сценарии прерывания процесса Это для смелых, блядь. Имитируем, что пользователь — самый большой мудак на планете. Начал обновление — и вырубил телефон. Или интернет пропал. Или батарейка села в самый ответственный момент.

• Цель: Система после этого не должна превратиться в кирпич. Идеал — чтобы она либо тихо дообновилась, когда всё появится, либо так же тихо откатилась в исходное состояние. Худший вариант — висит полчаса с надписью «Идёт обновление...», а на деле уже всё сломалось на втором шаге.

5. Чек-лист для мобильного приложения (здесь адок начинается):

• Обновление через магазины: Работает ли через App Store/Google Play? Не прилетает ли после этого «Приложение не установлено», блядь?
• Принудительное обновление (force update): Если версия критичная, и на старую заходить нельзя — работает ли этот механизм? Не даёт ли он пользователю просто выйти из приложения и больше не возвращаться?
• Обновление с пропуска версий: С v1.0 сразу на v5.0. Все промежуточные миграции отработали? Или мы пропустили шаг, где надо было данные преобразовать, и теперь они все в жопе?
• Release notes: А новый функционал из описания вообще работает? Или там, как обычно, написали «Улучшена стабильность», а на деле просто кнопку «Сохранить» перенесли в другое меню?
• Сохранность всего: Авторизация не слетела? Локальные настройки, кэш, сохранёнки — всё на месте? Чтобы пользователь не вошёл после обновления в чистый, блядь, лист бумаги.

Вот так вот, дружок. Тестирование обновлений — это не про то, «работает ли новая фича». Это про то, чтобы после всех этих телодвижений у пользователя не возникло желание найти тебя и ебать тебя в сраку твоим же зарядным устройством.