Здравствуйте, дорогие читатели. Сегодняшний материал мы хотели бы приурочить к запуску курса "Python QA Engineer". Предвещая возможные вопросы, предупреждаем, что в статье нет ни слова о Python, но все же мы считаем этот материал полезным для тестировщиков, поэтому и решили поделиться им с вами.
Тестирование каждой мельчайшей детали кода – вещь неосуществимая, поэтому регрессионное тестирование должно осуществлять комплексную проверку и фокусироваться на определенной области во всем ее объеме. Основной целью при этом является уверенность в том, что ни одна регрессионная ошибка не повредит критически важному бизнес-процессу. Именно это усилие и позволяет извлекать выгоду из автоматизации. Автоматизированный подход к тестированию, ориентированный на уменьшение регрессионных ошибок, поможет пройти долгий путь к выстраиванию хороших отношений с клиентами и повышению ценности бренда.
Моя команда отвечает за тестирование приложения для учета, которое использует сложные вычисления и заносит записи бухгалтерской книги в систему учета. Все это представляет из себя рабочий поток, и закрытие книг каждый месяц в нем является самым важным.
С каждым релизом происходят некоторое изменения в расчетах, например, для счета может понадобиться увеличить дебет или кредит, или же имеющееся значение может разделяться между двумя счетами. Такие изменения в комплексном приложении, имеющем множество внутренних и внешних зависимостей, часто приводят к непредсказуемому поведению, в том числе и к ошибкам регрессии, в неожиданных и, казалось бы, никак друг с другом не связанных, местах.
Давайте разберемся с регрессионной ошибкой, ее еще иногда называют критическим инцидентом или проблемой продакшена. Проработав несколько лет в индустрии программного обеспечения, вы понимаете, что регрессионная ошибка просочившаяся на продакшен гораздо важнее неправильно работающей новой функции. Дело в том, что новая функция все еще скрыта, поэтому при ее поломке влияние на бизнес-составляющую оказывается минимальным, тогда как при регрессионной ошибке, пользователь полагается на рабочую функцию и, скорее всего, не имеет резервного варианта рабочей системы.
Регрессионные ошибки вызваны изменениями, которые не были учтены project-менеджером или product owner’ом при приемочных тестах; архитектором, разработчиком во время code review на этапе проектирования или реализации; или же QA-аналитиком и тестировщиком в тестовых кейсах. Все сети безопасности пропустили ошибку и на нее наткнулся пользователь. Если ошибка в недавнем обновлении была выявлена на любом из вышеперечисленных этапов, т.е. командами, заинтересованными сторонами или любым другим звеном, которое присутствует в вашей организации, то ее рассмотрели до релиза или, как минимум, оценили на критичность.
Регрессионные ошибки влекут за собой несколько издержек: срочное исправление, штрафы за потенциальное нарушение соглашения об уровне обслуживания и, самое главное, они наносят ущерб доверию ваших пользователей к вашему продукту. Они могут решить, что новый релиз сломает что-то, что уже работает.
Моей команде стало важно проверять абсолютно все.
Однако хорошо известно, что это невозможно, или по крайней мере слишком дорого и отнимает много времени. Поэтому «тестирование всего» сконцентрировалось на следующих двух вещах: критические бизнес-процессы и уверенность в том, что поведение в основных критических бизнес-процессах будет таким же, как и в последнем релизе, до изменения. В общем, мы хотели убедиться, что в последнем релизе в критическом бизнес-процессе не появилась регрессионная ошибка.
Мы провели оценку наших типичных подходов к автоматизированному тестированию для проверки вычислений и проверку того, что вся логика описана в коде для автоматизации тестирования. Такой подход вызывал классический вопрос: «Кто тестирует код тестировщика?» Если тестовый кейс выполнялся неуспешно, оставалась такая же вероятность, что проблема была в коде тестировщика. Помимо этого, при каждом изменении в приложении тестовый код тоже нуждается в обновлении, а такие изменения случались часто.
Также благодаря автоматизированному тестированию мы убедились, что у нас есть фиксированный набор входов и уже известный набор выходов. Из-за сложности приложения было невозможно было подать все возможные наборы входных данных за раз. Также необходимы были различные наборы данных за конец месяца, квартал, год. Серьезной проблемой было расписание, поскольку, чтобы сгенерировать огромный набор входных данных и соответствующие скрипты, нужно много времени.
Была еще одна переменная: данные пользователя. У нас имелась особая привилегия: мы получали резервные копии пользовательских данных каждый месяц. Качество теста напрямую зависит от данных, используемых для проведения тестирования, а данные с продакшена всегда лучше, чем сгенерированные данные, поэтому наша привилегия была огромным преимуществом, которое мы не хотели упускать.
Выявление и реализация регрессионных тестов
Наш идея заключалась в том, чтобы использовать автоматизированное тестирования, которое нуждается в минимально необходимом обслуживании, и которое укрепляет уверенность заинтересованных сторон в том, что релиз будет надлежащего качества.
Итак, нам нужна была стратегия тестирования для критических бизнес-кейсов, которая гарантировала бы отсутствие регрессионных ошибок и, конечно же, которую мы могли бы быстро применить на практике.
Наш процесс подготовки выглядел так:
- Резервная копия базы данных с продакшена, восстановленная дважды;
- Установлены две тестовые системы, которые работают параллельно:
- Одна с кодом продакшена;
- Другая с текущей версией тестируемого приложения.
Такой подход обеспечивает две идентичные системы с различиями в коде всего в одну версию:
Иметь две системы довольно важно, поскольку это помогает понять, что любая проблема возникает только благодаря последним изменениям кода.
Тесты разделяются, таким образом от стандартного процесса «выполнить действие и получить реакцию» мы переходим к тому, что действия выполняются от одной точки к другой с сохранением рабочего потока, после этого происходит сравнение отчетов об ошибках. Это ключ к выявлению неожиданных ошибок.
Когда тестировщик фокусируется на новой функции или каком-то изменении, тест получается ориентированным конкретно на него, т.е. проверяется уместность конкретного изменения. Регрессионное тестирование отличается тем, что оно должно проверять, что ничего больше не претерпело изменений. Такое различие отражается в сценариях автоматизации. Оно делает сценарии тестирования конкретных функций непригодными для поиска регрессионных ошибок, поэтому здесь необходим другой подход.
Например, если вы работаете с системой управления заказами, вам понадобится скрипт для размещения заказов с множеством входных данных, чтобы размещать заказы на две установленные тестирующие системы (желательно, работающие параллельно), затем вы получаете отчет о заказах за прошедший день и сравниваете в них каждое значение. Затем все заказы подтверждаются или одобряются (это действие), а отчеты, такие как ежедневные подтвержденные заказы, заказы по номенклатуре, отчеты со склада, заказы с каждого перевозчика, тип отгрузки, тип платежа и т.д. будут сравниваться в двух системах. Так продолжается в течение всего рабочего процесса. Вы можете объединять действия, такие как размещение и подтверждение заказов, а затем сравнивать отчеты на отдельных этапах.
Другим примером может служить система управления гостиницей, в которой отдельные действия определяются как критические бизнес-процессы, такие как регистрация заезда, выставление счетов в ресторане и получение инвентаря. За всеми этими процессами будут закреплены свои собственные действия и отчеты. Разница в этой системе, по сравнению с предыдущим примером заключается в том, что наборы тестов могут выполняться параллельно, и нет необходимости завершать шаг, прежде чем начинать следующий.
Сравнение двух отчетов – это момент истины, и он должен быть безупречным, в том смысле, что ни у кого из заинтересованных сторон не должно быть сомнений в его правильности. Разница в отчетах – это настоящая разница.
Для этой операции мы используем интерфейс веб-сервиса. Все отправки отчетов выполняются параллельно на двух системах, в итоге сравнивается пришедший ответ в формате JSON.
Сравнение происходит по трем фронтам:
- Источник (продакшен) минус цель (тестируемое приложение);
- Цель минус источник;
- Сравнение значений для получения пересечения.
Такой способ будет работать для XML, XLS, CSV фиксированной ширины или любого другого формата. Нам нужно убедиться, что нет лишних записей, нет отсутствующих записей и все значения записей совпадают.
В этом заключается суть подхода, о котором мы говорим. Все это — информация доступная для чтения в приложении, которая оформляется как отчет или, в некоторых случаях, работающая в качестве интерфейса к другим приложениям.
Успех такого подхода заключается в инструменте сравнения или утилите, которая обрабатывает кейсы, относящиеся к вашему приложению. Вы можете считать себя счастливчиком, если найдете что-то подходящее «из коробки», в противном случае, важно понимать, что инвестиции в такой инструмент стоят того, поскольку они принесут хорошие плоды.
После всех разговоров об автоматизации необходимо вставить ремарку. Поскольку некоторые различия в отчетах ожидаемы, так как они должны быть там в соответствии с требованиями, все результаты также должны быть проанализированы вручную. Должны быть четкие успешные результаты прохождения тестовых кейсов, однако неудачные результаты также должны быть проанализированы и их валидность необходимо подтвердить. Так как мы говорим об ошибках регрессионного тестирования, они должны быть исправлены до релиза. Конечно, присутствуют и некоторые исключения, которые обрабатываются в соответствии с приложением.
Настройка программы
Все приложения разные, и установка и настройка их тоже происходит по-разному. Для подготовки приложения к тестированию могут потребоваться некоторые дополнительные шаги, поэтому их нужно учитывать в нужное время и в нужном месте выполнения тестов. Вот набор типичных шагов:
«Запутать» данные с продакшена, удалив e-mail идентификаторы или другую конфиденциальную информацию, или же заменить ее фиктивными данными;
Получить данные в надлежащем виде для запуска теста;
Адаптировать настройки для QA-среды, например, изменив интеграционные связи.
Единственный момент, о котором стоит помнить, это то, что перечисленные действия должны быть выполнены для обеих установок. Помните, что перед началом выполнения набора тестов, настройки должны быть идентичными.
Нередко действия, отличные от запроса отчета, могут возвращать объект, например, действие, такое как создание или изменение заказа, может вернуть новый объект заказа. В таком случае нужно сравнивать два объекта и не ждать сравнения отчетов. Это может помочь выявить ошибку на ранних этапах в самом корне.
Также рекомендуется разбить весь набор на более мелкие наборы, например, сгруппировав транзакции и связанные с ними отчеты вместе. Наборы можно запускать параллельно, чтобы сэкономить время выполнения. Однако для приложения с характерным рабочим потоком это сработает, только если вы сможете разделить кейсы по вертикали и по горизонтали или наоборот.
Вариации могут начинаться с технологий – JSON, XML или скейлеров (int/string/float), и расширяться до того момента, пока тестируемое приложение и продакшен будут реагировать различными структурами, но все еще соответствовать архитектуре. Например, продакшен-версия может использовать старый JAR файл, который оперирует определенным форматом, а в новой версии JAR файл был обновлен и теперь формат ответа изменился, поэтому их сравнение покажет несоответствия. Для того, чтобы их сравнить надлежащим образом понадобится временный плагин.
Таких ситуаций, вероятно, будет немного. В таких случаях иногда проще подправить дизайн или рассматривать их в контексте обходного пути.
Существует несколько вариантов обработки таких сравнений:
Игнорировать некоторые поля, такие как идентификаторы и даты;
Игнорировать числовые различия менее 0,0001;
Игнорировать чувствительность к регистру;
Структурировать изменения в два ответа.
Улучшение регрессионного тестирования
Регрессионное тестирование должно быть целостным и фокусироваться на целой области. Этот баланс поможет извлечь выгоду из автоматизации. Автоматизированный подход к тестированию поможет уменьшить количество регрессионных ошибок и поможет на пути к хорошим отношениям с клиентами и повышению стоимости бренда.
Теперь, в ритме постоянного движения вперед, наша команда хочет попробовать отказаться от двух идентичных установок системы, которыми мы пользуемся сейчас, и реализовать ту же стратегию на одной установке. Мы хотим сохранить ответы прошлых выполнений и использовать их для сравнения. Поход к тестированию всегда можно улучшить. Пожелайте нам в этом удачи!
Перевод подготовлен специально для студентов курса "Python QA Engineer".
