Согласитесь, неприятная ситуация, когда рабочие будни начинаются с открытия того, что некоторые тесты либо полностью не работают, либо работают, но не должным образом. Усугубляет ситуацию и то, когда вы пытаетесь объяснить руководству, что сбой произошел из-за некоего разработчика, который сменил тестовые данные на другую информацию.
Острая проблема тестовых данных – постоянный источник дополнительных задач для QA-инженеров. И не важно, проверяете вы мануально или заняты процессом автоматизации – когда настроенные вами тесты дают сбой, вы точно будете тратить время на выяснение, почему что-то не так с итоговыми результатами проверок.
Далее в статье мы разберем наиболее часто встречающиеся проблемы, которые могут возникнуть при взаимодействии со случайными тестовыми данными.
1. Пользователи могут переписывать информацию друг друга
Разберем на примере. Условно, у нас есть API 1. Оно разработано под цели создания пользовательских автотестов на основе тестового пользователя (виртуального).
API 1 ушло к другой команде тестировщиков, а мы начали работу над API 2. Под него тоже были созданы автотесты. К большому сожалению, в нем (API 2) использовался тот же пользователь и email, что и для API 1. Другими словами, во время каждого старта автотестов под API 1 будет изменяться адрес тестового пользователя, и все тесты для API 2 просто дадут сбой.
2. Не ваша команда сменила конфигурации
Если две и более QA-команды занимаются редактированием одного и того же тестового окружения, то изменения одной группы могут повлиять на деятельность другой. Это очень часто встречается при взаимодействии с фича-флагами. Одна группа тестировщиков работает с функционалом для включенного фича-флага, а другая ждет, что он будет на выключен.
3. Порча информации
Порой бывает так, что валидная информация в один момент может стать вообще непригодной для последующей обработки. Наглядный пример, дата в простом календаре. Если вашему автотесту понадобится будущая дата, вы можете выбрать дату, которая наступит через несколько лет после текущей. Но в будущем эта выбранная вами дата станет прошедшей и, к сожалению, произойдет сбой в проверке.
Какую стратегию выбрать, чтобы такого не допустить?
Применяйте Docker
Только применение определенного виртуального окружения дает пользователям контроль над некоторым тест-окружением, куда входят конфигурации ПО и БД. Для старта тестов требуется просто запустить виртуальную машину и провести тесты. А, когда все необходимые проверки будут выполнены, закрыть машину.
Создавайте свежую версию БД для проверок
При желании можно создавать оригинальные версии БД для целей прогона группы автоматических тестов. Например, в Windows это можно выполнить путем создания SQL DACPAC. Пользователь самостоятельно может настраивать схему персональной БД, добавляя только актуальные тестовые данные, создавать базу со всеми своими тестами, удалять БД, когда все проверки будут проведены.
Каждая проектная группа должна иметь в своем распоряжении тест-пространство
Даже при условии, что несколько тестовых групп должны применять одно тестовое окружение или аккаунт в тестовой программе, необходимо предоставлять разные тестовые наборы пользователей. При такой ситуации они точно не смогут переписать данные друг друга случайно. Просто используйте специфические имена, которые легко запомнить и трудно пропустить.
Создавайте оригинальные данные при каждом шаге прогона тестов
Хороший способ управлять всем тестовым окружением – разработка тестовой информации непосредственно перед стартом прогона тестов. Например, для теста требуется покупатель. Автор создает покупателя, использует его для проведения проверок, а затем просто удаляет его. При подобном подходе вся информация будет в таком виде, который вам нужен, и лишние данные не будут переполнять вашу БД.
Пробуйте применять «+1» для всех дат в будущем времени
Вместо того чтобы ставить дату Х в будущем, лучше взять сегодняшнюю, и использовать функцию DateAdd для того, чтобы иметь возможность добавлять интервал от месяца до дня. В такой ситуации, дата постоянно будет находиться в будущем времени.
В завершение стоит отметить, что работа с тестовыми данными может быть крайне сложной и утомительной. Но если заручиться эффективным планированием и стратегическими подходами, то все можно организовать так, что информация будет всегда корректной на протяжении выполнения всех тестов.
Оставить комментарий