В этой статье я расскажу, почему так важно не забывать о тестировании обновления продукта и, каким образом устроен данный процесс в нашей компании. Стабильность обновления — это вопрос репутации продукта и доверия пользователя к вашим нововведениям. По своему опыту могу сказать, что иногда перед запуском обновления, например, на телефоне, предпочитаю выждать хотя бы день и прочесть комментарии (они всегда актуальны только для последней версии). Если комментарии ругательные, то вероятность того, что я решусь на обновление, стремится к нулю. Рейтинг приложения за счет отрицательных комментариев падает, и восстановить его не так просто, ведь надо суметь заинтересовать пользователя в установке нового обновления, которого он теперь уже будет опасаться.

Чем обычно бывают недовольны пользователи?

• приложение после обновления не работает совсем. Например, оно попросту не знает, что делать с данными в старом формате;
• бонусы, скидки, сохраненки пользователя (игры, магазины, кафе) были утеряны;
• не работает новая фича, ради которой заявлено обновление;
• новая фича работает, зато отвалилась какая-то из старых;

Все эти проблемы актуальны как для мобильного приложения, так и для DLP-системы, которую мы тестируем у себя. Далее о том, с чем мы имеем дело.

Что мы выпускаем и что надо обновлять

Наша компания поставляет клиентам решение по защите от утечек корпоративной информации с возможностью настройки отдельно для каждой организации, исходя из ее потребностей. Основными элементы системы являются ее настройки (по каким критериям будет осуществляться поиск нарушителей) и события (зафиксированные инциденты).

Продукт состоит из нескольких частей, в этой статье рассмотрим сервер анализа и хранения инцидентов InfoWatch Traffic Monitor. Продукт работает на ОС семейства Linux, имеет свою базу данных. Офицер безопасности для работы использует веб-консоль. На данный момент поддерживается два разных дистрибутива Linux и две БД. Система может быть установлена несколькими способами: all-in-one, когда все компоненты на одной машине; и распределенная установка, когда компоненты системы существуют на разных физических машинах.

Помимо заявленного функционала системы, мы должны гарантировать обновление с мажорных версий N-1 и N-2 до N, а также обновление со всех минорных версий — патчей и хотфиксов каждой из версий. Это обусловлено тем, что у наших клиентов зачастую довольно сложная ИТ-инфраструктура, обновление может занять продолжительное время, поэтому важно ограничить количество обновлений, не проводить их слишком часто, избегая простоев в работе.

Все эти условия дают достаточно большой набор конфигураций нашего продукта, для каждой из которых мы должны гарантировать успешное обновление. Под этим подразумевается обновление, в результате которого:

• пользовательские данные не утеряны
• старые фичи не сломаны
• новые фичи доступны для использования

Приоритет требований из списка выше в данном случае расположен по убыванию важности. Например, если переводить приоритеты из плоскости работы с DLP-системами в плоскость пользовательских приложений, упомянутых выше, то сохраненка пользователю игры наверняка важнее, чем возможность начать новую игру. А пользователю приложений заказа еды все равно, насколько симпатично новое меню, если кнопка «Отправить заказ» перестала работать.

Рассмотрим пример с нашей таблицей обновлений при выпуске мажорной версии 3. Для версии 1.0.0 было выпущено два патча и три хотфикса, а для версии 2.0.0 было два хотфикса.

Итого в примере у нас указано девять версий, с которых мы должны обновиться до новой версии 3.0.0. Для каждой версии нашего продукта имеются две ОС и две БД. Т.е. в общей сложности выходит 27 обновляемых конфигураций. А если взять еще и разные способы установки, то это число смело можно умножить на два, в результате мы получаем 54.

Каждый наш релиз содержит некоторое число серьезных (с точки зрения влияния на продукт) фич. Могут меняться способы настройки системы, дорабатываться системы анализа, дополняться новыми данными инциденты, изменяться версия окружений, например, версия ОС или БД и т.п.

Исторически сложилось...

В незапамятные времена у нас сложился исследовательский подход при тестировании обновления продукта. Он оправдывал себя в условиях хорошего знания продукта и небольшого количества окружений и тестируемых конфигураций. Но время шло, команда росла и меняла состав: приходили и уходили как тестировщики, так и разработчики и некоторые недокументированные особенности благополучно забывались.

Планировать исследовательское тестирование без хороших знаний о продукте дело неблагодарное, это было чревато последствиями типа:

• Тестирование обновлений каждый раз занимало разное время. Чаще время выделялось по остаточному принципу, так как тестировалось обновление, когда продукт уже стабилизирован и перед выпуском остаются последние штрихи.
• Иногда забывались какие-то окружения.
• По сути, мы обновляли продукт с пустой базой и настройками по умолчанию и, далее начинался регресс. Учитывая, что времени выделялось немного, была вероятность, что тестировщик после обновления может «закопаться» в какой-то один функционал и проверить только его.

Предварительная подготовка также проводилась, в основном, на усмотрение тестировщика, которому досталась задача и порой без учета всех изменений версии.

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

В итоге из отчета о тестировании обновления нельзя было точно понять, какие проверки были проведены, на каких значениях и т.д.

Тем не менее, какое-то время нас устраивали результаты исследовательского тестирования: боевых дефектов на обновление было не так много, а на изменения ради теоретического преимущества ресурсов не было.

Что-то пошло не так

Ситуация изменилась, когда критичные дефекты обновления к нашим клиентам все-таки прокрались. Чаще всего они были найдены где-то в стороне от основных сценариев обновления и были связаны с ситуациями, когда, например, элемент технологии анализа, созданный и работающий в предыдущей версии, блокировал обновление, либо терялась часть событий в БД клиента, либо самый критичный сценарий, когда после обновления не запускалась часть сервисов и мы получали неработоспособный продукт. Также начали появляться базозависимые дефекты у наших клиентов.

В такой ситуации текущий процесс нас уже не удовлетворял. Что-то надо было менять.
Мы начали с формулировки проблем, которые по нашему мнению мешали нам тестировать обновление более качественно. По результатам обсуждений сформировался следующий список проблем:

• Недостаточно информации об изменениях в текущей версии;
• Недостаточное знание системы, недостаточно информации о системе;
• Тестирование обновления превращается в регресс, что, по сути, является избыточным тестированием, но качество не повышает;
• Производится тестирование функционала, а не объектов системы и операций над ними;
• Непонятная отчетность;
• Процесс непрозрачен. Как оцениваем задачу? Какие проверки делаем? Какие окружения покрываем? С каких версий обновляемся?

Решение

Далее для каждой обозначенной проблемы мы попытались найти достойное решение. Помимо решения конкретных проблем, которые мы сами для себя сформулировали, мы решили по ходу обсуждений выдвинуть требования к самому процессу тестирования, по которому мы дальше хотели бы работать.

Процесс следует сделать более открытым и наглядным, для этого мы полностью отказываемся от исследовательского тестирования в пользу тест-кейсов.

Для создания необходимых тест-кейсов нам потребуется информация об изменениях между версиями. Эту информацию нужно запросить у разработчиков и аналитиков продукта.

В новом подходе мы используем комбинацию проверок над объектами системы (неизменяемыми и изменяющимися в ходе обновления) + smoke-проверки функционала (как старого, так и нового или измененного старого).

Для обновления будет выбран самый сложный вариант установки системы — распределенная установка. Для всех ОС и БД. Более простые варианты опустить как частные случаи.

Данная комбинация проверок даст нам возможность проверки следующих компонент системы:

• БД;
• Web (frontend, backend);
• Linux-компоненты

В итоге решение для каждой из наших проблем было представлено следующим образом:
Недостаточно информации об изменениях в текущей версии. Недостаточное знание системы, недостаточно информации о системе. Совместно с аналитиками и разработчиками определяем изменяющиеся области продукта между обновляемой и текущей версиями.

Тестирование обновления превращается в регресс. Производится тестирование функционала, а не объектов системы и операций над ними. Будем тестировать обновление по тест-кейсам в виде smoke-тестов функционала + проверки данных.



Непонятная отчетность. Покрытие и результаты можно взять из тест-кейсов.

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

Новый процесс

В результате мы выстроили довольно эффективный процесс.

Тестирование мы разделили на несколько этапов, что дало еще больше незапланированных бонусов, о которых ниже:

1. Подготовка.
   
   • Проводим анализ изменений в системе, подготовленный совместно с аналитиками и разработчиками на предмет изменяющихся областей.
   • В соответствии с результатами анализа составляем список подготавливаемых для тестирования обновления объектов системы.
   • Для каждого объекта системы определяется необходимый набор состояний, статусов и параметров.
   • Создаем стенды с необходимой (обновляемой) версией продукта.
   • На стендах создаем объекты, определенные выше.
   • Делаем снапшот стенда (это позволяет повторно использовать уже подготовленные данные раз за разом).
   • Изменяем или создаем smoke-тесты для проверки функционала, проверяемого после обновления.
   
   Итого по завершении этапа подготовки у нас готовы:
   
   
   • статьи с описанием подготовленных сущностей;
   • наполненные этими сущностями стенды со старой версией продукта в требуемых конфигурациях (БД, ОС, способ установки, версия);
   • тесты, использующие в качестве тестовых данных сущности из статей.
   
   
2. Обновление системы
   
   
   • Производим обновление подготовленного стенда на новую выпускаемую версию продукта.
3. Выполнение тестирования
   
   • Анализ лог-файлов, конфигурационных файлов на предмет ошибок.
   • Проверки неизменности объектов после обновления.
   • Проверки, что изменения объектов прошли в соответствии с ожиданиями.
   • Проверки операций над объектами (создание, редактирование, удаление).
   • Проверки взаимодействия объектов с другими объектами (детектирование).
   
   

Плюсы и минусы подхода

Своего мы добились, а именно:

1. Процесс стал прозрачным. Мы знаем, что тестируем, как, сколько времени это займет, и какие артефакты будут на выходе. Мы получили объективные критерии, по которым можно было давать свой вердикт о рабочем или нерабочем обновлении продукта.
2. Отчеты стали наглядными. Наличие тест-кейсов и отчет о результатах их прохождения дали возможность быстро отчитываться перед проектным менеджером и техническим директором о качестве созданной сборки.
3. Большее и более понятное покрытие, чем при исследовательском подходе.
4. Теперь мы тестируем изменение в данных и функционале. Благодаря отзывчивости аналитиков и разработчиков мы с высокой степенью точности можем сказать, что менялось в системе и где есть риск поймать дефект.

Но обкатывая новую стратегию тестирования, мы не могли не столкнуться и с очевидным минусом нового подхода — существенным увеличением времени тестирования.

Мы стали тратить время не только на непосредственное тестирование, как это было при исследовательском тестировании. Новые временные затраты были связаны в первую очередь с подготовкой к тестированию, а именно:

• анализ изменений;
• создание, наполнение, поддержание стендов для обновления;
• актуализация старых тест-комплектов и создание новых.

Этот минус вполне мог бы стать решающим для принятия решения об отказе от новой методики, если бы не одно «но».

Всю подготовку, а это самый объемный по времени этап, можно было осуществлять как только сформирован окончательный состав релиза, даже еще без готового продукта. Таким образом, мы «размазали» подготовку по плану тестирования, не перегружая чрезмерно и без того насыщенный предрелизный период. На него по-прежнему приходилось лишь прохождение тестов на готовом стабилизированном продукте.

Итого по результатам первого этапа улучшений мы получили следующее: мы стали тратить больше времени на тестирование, но при этом мы имеем прозрачный процесс, наглядное отображение результатов и большее покрытие, что позволяет нам:

• обнаруживать большее количество дефектов в результате проверки обновления продукта у себя в отделе;
• снизить количество дефектов при обновлении у наших заказчиков силами инженеров внедрения;
• снизить количество дефектов, получаемых от техподдержки.

Что дальше? — про оптимизацию

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

Мы пошли двумя путями:

1. оптимизация на основе анализа прогонов тестов: тут мы занимались выявлением очевидных и неявных зависимостей результатов проверок от используемых окружений. Это путь, по которому пошло функциональное тестирование.
2. автоматизация тестирования. Тут нам на помощь пришла наша команда автоматизаторов.

Чуть подробнее расскажу о каждом пути.

Путь первый: оптимизация на основе анализа прогонов тестов

Этот путь мы выбрали для оптимизации тестирования обновления между мажорными версиями, т.е. между теми, где было существенное изменение функционала.

Первым делом обратили внимание на тесты, зависящие от БД и только от БД. Мы смогли понять, какие проверки достаточно провести один раз на каждой базе, а потом уже исключить их из нашей комбинаторики с ОС совсем.

Вторым шагом стало «схлопывание» объемных проверок старого функционала в чек-лист. В первых итерациях функционалу вне зависимости от того, появился он в текущем релизе, в предыдущем или был всегда, полагался свой полноценный тест. Теперь же полноценные тесты полагаются только новым фичам, старый же функционал проверяется по чек-листу.

Более того, этот же чек-лист нам сильно пригодился при выпусках патчей и хотфиксов, где кроме обновлений между мажорными версиями важно также проверять обновление внутри версии.

Путь второй: автоматизация тестирования

Прежде всего, хочу оговориться, что автоматизацию тестирования обновлений мы задумали не потому что так принято и вообще хороший тон, а потому, что обновление – это тот тип тестирования, который невозможно было исключить ни при одном выпуске, будь то мажорный релиз, патч или хотфикс. Этот путь мы выбрали для сокращения времени тестирования обновлений для минорных версий, а именно, патчей и хотфиксов, т.е. версий, между которыми состав функционала не меняется. В этом случае автоматизация тестов выглядела весьма эффективно.

На данном этапе тестирование обновлений при выпуске патчей и хотфиксов практически целиком автоматизировано.

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

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

Резюме

У нас был исследовательский процесс тестирования обновлений. В какой-то момент он перестал нас удовлетворять по причине заметного падения качества обновления. Замену исследовательскому тестированию мы не выбирали как готовую методику, а формировали его исходя из выявленных нами проблем. На формирование новой методики, которую мы используем и продолжаем совершенствовать повлияли подготовленные решения проблем, а также общие пожелания к ходу тестирования.

Я не думаю, что в этой ситуации мы изобрели велосипед, когда пошли по пути создания своего процесса, заточенного именно под наш проект и особенности нашего продукта. Если разобрать процесс на составные части, то получим, в общем-то, общепринятые и широко используемые методики.

Несмотря на то, что результаты работы мы собрали в одной не слишком объемной статье, весь процесс от осознания проблемы до внедрения новых решений и оптимизации тестирования занял у нас практически два года.

Мы постарались честно описать здесь все плюсы и минусы, а также подводные камни принятых нами решений, чтобы повествование не выглядело исключительно как success story «было плохо — стало хорошо».

Надеемся, наш опыт окажется вам полезным.

Автор материала: tryzhova (Рыжова Татьяна).