Иногда в процессе разработки случается такое негативное явление, как регрессия кода.

Суть ее: негативные изменения в одной части кода, вызванные изменениями в другой части кода. Регрессия практически не поддается прогнозированию.

Почему возникают регрессии?

Вот классическая иллюстрация из книги Нассима Талеба «Черный лебедь»:

“

Взмах крыльев одной-единственной бабочки в Нью-Дели, несомненно, может быть причиной урагана в Северной Каролине, пусть даже этот ураган произойдет двумя годами позже. Однако сомнительно, что вы, имея в качестве исходных данных ураган в Северной Каролине, смогли бы хоть приблизительно установить причины урагана: ведь мелких вещей, которые могли бы его вызвать, вроде трепыхающихся бабочек в Тимбукту или чихающих диких собак в Австралии, миллиарды.

В приведенном примере рассматривается событие (появление урагана), которое:

• Вероятно.
• Имеет цепочку последовательных связей.
• Непрогнозируемо.

Теперь к практике.

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

Как победить регрессии?

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

Схема такая: разработчики дописали новую функцию ? код проекта «заморозили» (т.е. приостановили работу над ним) ? тестировщик провел полное тестирование проекта ? код «разморозили» ? разработчики исправили баги ? код снова «заморозили» ? тестировщик снова провел полное тестирование ? код «разморозили» ? разработчики дописали новую функцию ? код проекта «заморозили»...

Накладно? Определенно, да — ведь у тестировщика будет уходить масса времени на проверку проекта целиком (причем всё больше с каждым этапом).

В настоящее время мы используем автоматическое тестирование на внутреннем проекте SCRUMBAN (это инструмент для визуализации процесса управления, полностью интегрированный в Корпоративный портал 1С-Битрикс).

Как устроен процесс автоматического тестирования?

Затем мы готовим автотесты с помощью Selenium — инструмента для автоматического тестирования интерфейсов.

Алексей Ашихмин
QA Сибирикс

Selenium есть функция записи действий пользователя — то есть можно мышкой воспроизвести тест-кейс, а на выходе получить код автотеста. Но я предпочитаю вручную писать команды, а элементы интерфейса «отлавливать» в Firebug — так автотесты получаются стабильнее.

Когда автотесты готовы — они загружаются в Selenium IDE, запускается автоматическое тестирование и фиксируются результаты. Вот так всё выглядит, посмотрите (скорость воспроизведения 1:1):

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

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

Поэтому для автоматического тестирования SCRUMBAN мы используем виртуальные машины.

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

• Мы запустили 4 виртуальные машины с разными конфигурациями 1С-Битрикс на них (11-яи 12-я версии в кодировках win-1251 и UTF-8) — это позволило одновременно отслеживать работоспособность SCRUMBAN на разных платформах.
• Тестировщик ежедневно, перед запуском тестирования, создает «точку возврата» всей системы, что снизило риск остановки тестирования из-за сбоя ПО.
• Разработчики получили доступ к виртуальным машинам по IP-адресам — это дало возможность тестировщику не отвлекаться от работы для повторного воспроизведения бага в нужной пользовательской конфигурации.

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

Что делать клиенту?

Есть два варианта получения гарантированно качественного продукта.

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

Плюсы такого подхода:

• быстрое тестирование всего проекта без потери темпа разработки.
• предотвращение регрессий кода.

Минусы:

• высокая стоимость.

Второй — закладывать резервный бюджет на ручное тестирование + устранение найденных багов.

Плюсы:

• относительно низкая стоимость.

Минусы:

• не предотвращает появление регрессий, а только устраняет их последствия.
• процесс разработки «прерывается» на ручное тестирование.