Home

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2017/01/16/catching-changes-before-they-become-problems/

Перевод: Ольга Алифанова

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

Чувствуете ли вы, что это неплохой фильтр, который изловит практически любой внедренный баг?

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

"Почему тесты этого не уловили?" Хм.

Причина

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

Я мог уже об этом писать где-то: код – это органическая структура.

Возможно, странно говорить так о коде. Но мы говорим о неодушевленных предметах, что у них есть личность – так и код впитывает природу и характер человека, который его пишет.

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

О многом просто забывают. Или в продукт вносятся изменения, а люди еще не в курсе, что автоматизация эти изменения не учитывает.

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

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

Это как контраварийное вождение – обычно вам оно не требуется, но неплохо уметь это делать на случай, если другие водители ведут себя на дороге, как уроды. Надеюсь, мысль понятна?

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

Если мы думаем, что у нас вполне приличный набор тестов, мы можем начать думать, что он не нуждается в добавлениях. Он полон, и мы, возможно, не стремимся к 100% покрытию, нам вполне достаточно 70-80%, и их мы получаем.

И даже в этом случае что-нибудь да просочится через нашу защиту.

Это происходит, как правило, редко, но если какой-нибудь "не тот" баг прокрадется в релиз, это станет проблемой для компании.

Пытаться решить вопрос "как протестировать добавленное" довольно сложно. Зато вполне легко решить вопрос "как определить, когда что-то добавлено".

Как определить, что добавлена новая функциональность

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

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

В тестировании вы делаете нечто похожее. Вот вам пример.

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

Если разработчик добавляет новую функциональность – например, новую страничку – как вы думаете, где он "спалится"?

Если вы ответили "в меню", вы абсолютно правы. Меню, скорее всего, изменится, чтобы отобразить появление новой страницы.

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

Это наше "палево", которое дает нам понять, что нам нужно добавить автотесты для этой странички. После этого мы обновляем наш тест, учитывая новое содержание меню.

Вот другие типы "палева", на которые можно обратить внимание в зависимости от того, что мы тестируем.

Web-интерфейс

• Посчитайте, сколько пользовательских вводов существует на странице. Новые места, куда пользователь может ввести данные, означают, что где-то появилась новая функциональность.
  • Вы можете отслеживать только количество текстовых полей, переключателей, чекбоксов, и т. д.
  • …если вы мастер Javascript, вы можете добавить аутлайн вокруг всех элементов, для которых у вас еще нет локаторов, и сделать скриншот.
• Проверьте содержание меню.
  • Меню помогают пользователю ориентироваться в вашей системе.
  • Если добавлена новая функциональность – скорее всего, это будет отражено в меню.
  • Если порядок не так важен, вы можете сделать эту проверку немного более устойчивой к изменениям, если порядок элементов заставит ваш тест упасть.
• Убедитесь, что все элементы, которые ведут на другую страницу, имеют href-атрибут.
  • Изменения могут привести вас в новое место, и множество тестов в результате упадет.
  • Знание, что тесты упали, потому что попали на новый сайт, помогут решить проблему позднее.

Для баз данных

• Возьмите список таблиц и хранящихся в них процедур.
  • Новые таблицы и процедуры могут вызвать неизвестные изменения.
  • Проверьте, что колонки в каждой таблице все еще совпадают с предыдущим вариантом.
• Убедитесь, что количество и тип данных в каждой колонке не изменился.
  • Иногда изменение размера данных может привести к обрезанию данных позднее, к примеру, если длина текстового поля – 30 знаков, а колонка установлена на 25, потому что 30 показалось малореалистичным значением.

Для вебсервисов:

• Если ваши вебсервисы оснащены списком того, какие конечные точки get/post/put/delete у них есть, сравните этот список с последними данными.
• Парсите данные и убеждайтесь, что ответные поля именно такие, как ожидается:
  • Вы получаете больше или меньше полей в ответе?
  • Не меняют ли поля имена?
  • Не меняют ли поля типы? К примеру, раньше возвращался хэш, а теперь массив?

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

Когда проводить такое тестирование

Его неплохо проводить между smoke-тестами и всеми остальными. Ваши smoke могут все еще срабатывать, но они не тестируют на предмет всех внедренных изменений.

Другие достоинства

Если расширять ваши тесты, чтобы они учитывали изменения, очень сложно, это сигнал, что вам нужен рефакторинг.

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

Что еще?

Есть ли у вас проблемы с падающими из-за изменений тестами? Замедляет ли это вашу работу? Какие типы перемен вызывают эту проблему у вас?

Обсудить в форуме.