что такое тестовые данные в тестировании
Создайте свои тестовые данные
Что такое тестовые данные? Почему это важно?
Тестовые данные на самом деле являются входными данными для программы. Он представляет данные, которые влияют или зависят от выполнения определенного модуля. Некоторые данные могут использоваться для положительного тестирования, как правило, для проверки того, что данный набор входных данных для данной функции дает ожидаемый результат. Другие данные могут использоваться для отрицательного тестирования, чтобы проверить способность программы обрабатывать необычный, экстремальный, исключительный или неожиданный ввод. Плохо спроектированные данные тестирования могут не проверять все возможные сценарии тестирования, которые будут ухудшать качество программного обеспечения.
Что такое генерация тестовых данных? Почему тестовые данные должны быть созданы до выполнения теста?
В зависимости от среды тестирования вам может потребоваться СОЗДАТЬ тестовые данные (в большинстве случаев) или, по крайней мере, определить подходящие тестовые данные для ваших тестовых случаев (если тестовые данные уже созданы).
Обычно тестовые данные создаются синхронно с тестовым набором, для которого они предназначены.
Тестовые данные могут быть сгенерированы —
Ниже описаны несколько типов тестирования, а также некоторые предложения относительно их потребностей в данных тестирования.
Тестовые данные для тестирования белого ящика
В White Box Testing управление данными тестирования выводится из непосредственного изучения кода, подлежащего тестированию. Тестовые данные могут быть выбраны с учетом следующих вещей:
Тестовые данные для тестирования производительности
Тестовые данные для тестирования безопасности
Тестирование безопасности — это процесс, который определяет, защищает ли информационная система данные от злонамеренных действий. Набор данных, который необходимо спроектировать для полного тестирования безопасности программного обеспечения, должен охватывать следующие темы:
Тестовые данные для тестирования черного ящика
В Black Box Testing код не виден тестеру. Ваши функциональные тесты могут иметь тестовые данные, соответствующие следующим критериям:
Инструменты автоматического создания тестовых данных
Чтобы генерировать различные наборы данных, вы можете использовать гамму инструментов автоматического создания тестовых данных. Ниже приведены некоторые примеры таких инструментов:
1) Генератор тестовых данных GSApps можно использовать для создания интеллектуальных данных практически в любой базе данных или текстовом файле. Это позволяет пользователям:
2) Генератор тестовых данных DTM — это полностью настраиваемая утилита, которая генерирует данные, таблицы (представления, процедуры и т. Д.) Для тестирования базы данных (тестирование производительности, тестирование качества, нагрузочное тестирование или тестирование удобства использования).
Datatect является генератором данных SQL от Banner Software, генерирует различные реалистичные тестовые данные в плоских файлах ASCII или напрямую генерирует тестовые данные для СУБД, включая Oracle, Sybase, SQL Server и Informix.
Вывод
В заключение, хорошо разработанные данные тестирования позволяют выявлять и исправлять серьезные недостатки в функциональности. Выбор выбранных тестовых данных должен быть переоценен на каждом этапе многофазного цикла разработки продукта. Поэтому всегда следите за этим.
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Тестовые данные (Test Data)
Тестовые данные – это часть Датасета (Dataset), проверяющая основа Модели (Model) Машинного обучения (ML). Является одной из составляющих разделенного набора данных наряду с Тренировочными (Train Data) и Валидационными (Validation Data) данными.
Типы разделений датасета
Пример. Мы создаем модель, предсказывающую потребление электроэнергии в городе. Если на тренировочных данных она, подобно человеческому мозгу, учится видеть скачки потребления электричества, то на тестовой Дата-сайентист (Data Scientist) проверяет качество обучения.
Тестовую часть информации используют в качестве золотого стандарта для сравнения различных конкурирующих моделей (например, на соревнованиях Kaggle). Наивысший результат во время такого теста и определяет наиболее эффективную модель. Набор для тестирования обычно формируется случайным способом и содержит Наблюдения (Observation) различных классов, с которыми может столкнуться модель при использовании в реальном мире.
Тестовые данные и Scikit-learn
Стоит отметить также, что не во всех случаях простое случайное разделение датасета на части уместно: если речь идет о небольшом датасете, применяется так называемая Кросс-Валидация (Cross Validation): данные делят на k частей, и как бы попеременно используют каждую из них то в тестовых, то в валидационных целях, то как часть тренировочного компонента.
Для начала импортируем необходимые библиотеки
Посмотрим, что мы «положили» в объект X :
Элегантная функция range() позволила нам сгенерировать вот такой ряд максимально кратко и без циклов, и это прекрасно:
В первую очередь, алгоритм функции выбирает тестовые 33% случайным образом:
Треть данных – это всего две строки, когда речь идет о датасете 5 x 3:
Вызовем тестовую часть данных целевой переменной – это Ярлыки (Label) двух рядов X_test :
Ряды [2, 3], [8, 9] принадлежат классам 1 и 4 соответственно:
Разделив датасет на четыре части, мы вызываем тренировочную часть предикторов:
Этот компонент – остаток тренировочных данных после выборки 33% тестовых Наблюдений (Observation):
Тоже самое для тренировочной части целевой переменной:
y_train – это Ярлыки (Label), которые соответствуют порядковому номеру рядов X_train:
Ноутбук, не требующий дополнительной настройки на момент написания статьи, можно скачать здесь.
Тестирование данных: требования и уровни
Меня зовут Алексей Чумагин, я тестировщик в Provectus. В этой статье я расскажу, как формируются требования к качеству данных и какие могут быть уровни тестирования данных.
Upd:
В статье речь идет о больших (или не очень) данных, на основе анализа и агрегации, которых строятся разные процессы, выводятся закономерности для использования в дальнейшем анализе или для принятия решений. Данные могут быть собраны под конкретный проект с нуля, либо могут использоваться базы, собранные ранее для других проектов либо в коммерческих целях. Источники этих данных разнообразны и включают не только ввод операторами, но и автоматизированные и/или автоматические измерения, сохраняемые в базы системно или бессистемно (кучей, “потом придумаем что с этим делать”).
Почему тестирование данных важно
Данные играют все большую роль в принятии решений как в повседневной жизни, так и в бизнесе. Современные технологии и алгоритмы позволяют обрабатывать и хранить огромные массивы данных, преобразуя их в полезную информацию.
Что это за данные? Например, история вашего браузера, транзакции по вашей карте, точки перемещения какого-то девайса. Они обезличены, но эти данные все равно принадлежат определенному устройству. Если их собрать и обработать, то можно получить довольно интересную информацию о хозяине этого девайса. Например, куда он любит ходить, какой у него пол и возраст. Так постепенно мы «очеловечиваем» устройство и наделяем его какими-то характеристиками.
Потом эту информацию можно использовать для таргетированной рекламы. Если вы женщина, то с большой долей вероятности можно сказать, что вас не интересует реклама бритвенных станков для мужчин. Вам нужно показывать рекламу, связанную с вашими интересами. Качество таргетирования рекламы может быть повышено благодаря тому, что известно о девайсах, на которых её показывают. Вам показывают рекламу, которую вы хотите видеть. Значит, вы будете на нее кликать. Люди, которые показывают вам эту рекламу, будут получать за это деньги, а заказчик рекламы получит профит от того, что вы узнаете о его продукте.
Всё это базируется на тех данных, которыми владеют разные компании и люди. Для эффективного использования этих данных нужно, чтобы они были достоверными и мы знали, что именно этому аккаунту принадлежат эти транзакции.
Так как данных становится очень много, их хранение требует значительных ресурсов. Очистка данных — отдельная задача, которую надо решать. Мы хотим хранить только те данные, которые нам действительно нужны. И не хотим, чтобы у нас в базе данных хранились дубликаты или записи, которые не соответствуют нашим критериям. Например, записи с пустыми полями. Поэтому возникают требования к качеству данных и встает вопрос об их тестировании.
Что такое качество
Мне нравится такое определение: качество продукта — это мера удовлетворенности пользователя. Понятно, что всё зависит от контекста использования продукта. Если вы пользуетесь каким-нибудь известным продуктом, например, Facebook или Skype, то у вас одни требования к качеству. Вы будете мириться с какими-то ошибками, но всё равно продолжите пользоваться этим продуктом. А если вы являетесь заказчиком какой-то программы и заплатили за нее деньги, то требования к качеству будут выше. Вы будете придираться, смотреть какие-то мелочи. У разных людей разные представления о качестве, и у разных программ тоже свои требования к качеству.
Поэтому перед разработкой и тестированием люди обычно определяют, что будут считать качественным продуктом. Все это можно описать формально. Например, мы будем считать наш продукт качественным, если в нем не будет критических ошибок. Или если он проработает две недели без сбоев.
Определение этих требований — непростая задача. Обычно требования к ПО формирует бизнес, и если мы спросим у бизнеса, какими должны быть данные, то можем получить ответ, что данные должны быть хорошими и чистыми. Задача тестировщика — выяснить или уточнить, что это за данные и по каким критериям мы определяем их качество и чистоту. Эти критерии нужно формализовать и зафиксировать, сделать измеряемыми.
Как формируются требования к качеству данных
Тестировщик начинает выяснять, что ему непонятно и что он хотел бы узнать об объекте тестирования. Тестировщик составляет список вопросов и начинает брать «интервью» у заказчика. Он, по идее, должен знать, какими должны быть данные. Например, я спрашиваю: допустимы ли пустые ячейки или повторяющиеся строки.
Пример требований — если у нас есть список людей, то имя, фамилия и отчество могут повторяться. Но вся совокупность строк повторяться не может. По одной ячейке могут быть допустимы повторения, а по целой строке или по совокупности нескольких ячеек — уже нет. Полного совпадения не должно быть.
Дальше мы начинаем спрашивать о формате данных в определенной ячейке. Например, в номере телефона должно быть 12 цифр, в номере банковской карты — 16. У нас может быть критерий, что не всякая последовательность этих знаков является номером банковской карты. Или мы понимаем, что в фамилии могут быть только буквы. У нас может возникнуть много вопросов по поводу формата данных. Таким образом, мы выясняем всё, что нам нужно знать о предмете тестирования.
Что такое качественные данные
Качественные данные должны обладать несколькими характеристиками.
Уровни тестирования данных
Мы можем сгруппировать данные по так называемым слоям — здесь работает хорошая аналогия с пирамидой тестирования. Это распределение по количеству тестов на разных уровнях приложения.
Синтетические vs реальные тестовые данные: плюсы, минусы, подводные камни
Начнём со сладкого и приведём примеры из практики тестирования.
Представьте себе готовый к запуску интернет-магазин. Ничего не предвещает беды. Маркетологи разработали стратегию продвижения, были написаны статьи в профильные интернет-ресурсы, оплачена реклама. Руководство ожидало до 300 покупок еженедельно. Проходит первая неделя, менеджеры фиксируют 53 оплаты. Руководство магазина в ярости.
Менеджер проекта бегает в поисках причин: непродуманность usability? нецелевой трафик? что-то еще? Начали разбираться, изучили данные системы аналитики. Оказалось, что до оформления заказа дошли 247 человека, а оплатили только 53.
Анализ показал, что остальные не смогли оформить покупку из-за адреса электронной почты!
Тестирование формы заказа отдали начинающему специалисту. Он старался изо всех сил, вводил в поля «ФИО», «Email», «Телефон» все возможные и невозможные варианты, которые давали ему онлайн-генераторы. Спустя неделю все баги были найдены и пофикшены. Релиз состоялся. Но в числе рассмотренных вариантов не было ни одного адреса электронной почты, содержащей менее 8 символов после @.
Так счастливые обладатели почт @ mail.ru, @ ya.ru (и аналогичных) не смогли ввести свою почту и покинули сайт без покупок. Владельцы недополучили порядка 600 тысяч рублей, весь рекламный бюджет был слит в пустоту, а сам интернет-магазин получил кучу негативных отзывов.
Думаете это единичный случай? Тогда вот ещё одна страшилка для заказчика.
На волне всеобщего интереса к безналичным расчетам, компания по выдаче займов решила ввести новый способ перечисления денежных средств — на банковскую карту заемщика. Реализовали соответствующую форму в личном кабинете менеджера, протестировали разные варианты ошибок в полях для ввода данных карты, пофиксили, начали работать. Спустя месяц до руководства дошла информация, что 24% потенциальных заемщиков, которые уже получили одобрение, не оформили займ до конца. Почему? Они предоставляли банковскую карту, номер которой содержал 18 цифр, вместо заложенных и протестированных 16. Ни система, ни менеджеры не могли зарегистрировать такие карты, и клиенты уходили ни с чем.
Пилотный проект был внедрен в 3 офисах города. Среднее количество ежемесячных займов по трём офисам равнялось 340. Итог: организация потеряла, как минимум, 612 тыс. руб. выручки.
Это лишь пара примеров, когда синтетические данные могут стать причиной серьёзных убытков на проекте. Многие тестировщики вводят синтетические данные для того, чтобы протестировать различные проекты – от мобильного приложения до ПО. В таком случае тестеры сами придумывают тестовые ситуации, пытаясь предугадать поведение пользователя.
Однако, чаще всего они видят пользователя не многомерным, как в кинотеатре с 3D-очками, а схематичным, как будто ребёнок нарисовал человечка на альбомном листе.
Это приводит к тому, что тестировщик не покрывает все возможные тестовые ситуации и не может работать с большим объёмом данных. И, хотя тестирование может быть проведено хорошо, нет никаких гарантий, что система не упадёт, когда самый настоящий пользователь (чаще всего нелогичный и даже непредсказуемый) начнёт взаимодействовать с продуктом.
Сегодня мы поговорим о том, каким данным отдать предпочтение в процессе тестирования: синтетическим или реальным.
Разберёмся в терминах
Каждый раз, когда мы берёмся за тест, мы решаем, какими тестовыми данными мы будем пользоваться. Их источниками могут быть:
Например, когда мы присоединяемся к проекту по разработке веб-продукта для производственной компании, мы можем для тестирования воспользоваться копией существующей БД 1С, которая на протяжении нескольких лет собирала и обрабатывала все данные об операциях и клиентах. С помощью модуля формирования и отображения отчетов о выполненных заказах мы получаем информацию из 1С в нужном формате и работаем с реальными тестовыми данными.
Источники из пунктов 3 и 4 мы называем «синтетическими тестовыми данными» (такой термин можно встретить в зарубежном тестировании, но в русскоязычном сегменте он используется редко). Такие данные мы создаём сами для целей разработки и тестирования.
Например, мы получили заказ от новой электронной торговой площадки для проведения закупок государственными и муниципальными организациями по 44 ФЗ. Здесь соблюдаются очень строгие правила защиты информации, поэтому у команды нет доступа к реальным данным. Единственный выход для проведения тестирования: создать весь набор тестовых данных с нуля. Даже физические электронно-цифровые подписи, которые предназначены исключительно для тестирования.
В нашей практике редко используется один тип данных, обычно мы работаем с их комбинацией в зависимости от задачи.
Для проверки ограничений и исключений в той же системе для производственной компании мы дополнительно задействовали синтетические данные. С их помощью мы проверили, как поведет себя отчет, если в одном из заказов будут отсутствовать продукты. На электронной торговой площадке мы комбинировали синтетические данные с реальными справочниками ОКПД2 и ОКВЭД2.
Возможности синтетических данных
В ряде ситуаций без синтетических данных просто не обойтись! Посмотрим, для каких задач из арсенала тестировщика они могут использоваться:
1. Упрощение и стандартизация
Часто реальные данные представляют собой однородные массивы данных: представьте, что в системе регистрируются тысячи физических лиц с одним набором атрибутов, юридические лица, отличающиеся по типу, стандартные операции и множество других типов сущностей. Тогда зачем тратить часы на тестирование одинаковых входных данных, если можно объединить их в группы и для каждой группы назначить «представителя»?
На одном из прошлогодних проектов заказчик решил усилить команду тестировщиков перед очередным релизом, для чего была привлечена команда из наших специалистов. Продукт содержал доработанную форму регистрации с множеством полей. Мы заложили на тест формы 30 минут и потратили примерно столько же времени. Параллельно же вскрылось, что ранее эту форму уже тестировал другой тестер, потратив на это 7 часов. Почему? Просто он решил прогнать тест по реальным данным 12 сотрудников из штатного расписания и не учёл, что тест по одному сотруднику покрывает все атрибуты, одинаковые для каждого регистрируемого профиля.
Профит: 6 часов 30 минут и это только на одном тесте.
2. Комбинаторика и покрытие тестами
Несмотря на зачастую большой объём реальных данных, они могут не содержать ряд возможных кейсов. Для того, чтобы гарантировать работоспособность системы при различных комбинациях входных данных, нам приходится генерировать их самостоятельно.
Вернёмся к предыдущему примеру. Форма регистрации в новом релизе дорабатывалась не просто так. Команда заказчика, исходя из норм корпоративной культуры, решила сделать область отчества обязательной. Итог, у всех иностранных специалистов в штате резко появился один отец — Иван (кто-то сказал писать Иванович, пока не починят). Случай забавный, но если вы не учитываете какие-то хотелки или параметры своих клиентов в тестах, то не обижайтесь, если эти люди потом не будут учитывать вас в своих затратах/отзывах.
3. Автоматизация
В автоматизированном тестировании без синтетических данных не обойтись. Даже кажущиеся незначительными изменения в данных могут повлиять на работу целого набора тестовых прогонов.
Тут наглядным будет пример из банковской сферы. Чтобы проверить правильно ли приложение проставляет номера банковских счетов в генерируемых им документах, мы потратили 120 человеко/часов на написание автотестов. Доступа к БД не было, потому номер счёта был указан в самом автотесте. Тесты отлично себя показали и мы уже готовы были рисовать в отчёте 180%+ ROI от автоматизации. Но через неделю произошло обновление БД с изменением номера счёта. Все автотесты, как и наши усилия по автоматизации благополучно попадали. После доработки автотестов, итоговый ROI снизился до значения 106%. С тем же успехом мы могли сразу начать тестировать руками.
4. Повышение управляемости
Используя синтетические данные, мы знаем (в худшем случае, предполагаем), какого отклика ждать от системы. Если в функциональность вносятся изменения, мы понимаем, как изменится отклик на те же самые данные. Или мы можем подкорректировать данные, чтобы получить желаемый результат.
В одном из проектов наша команда приступила к тестированию с использованием реальных данных из БД контрагентов заказчика. БД активно дорабатывалась, но на тот момент она была составлена крайне небрежно. Мы теряли время, пытаясь понять где ошибка, в функционале или в БД. Решение было простым, составить синтетичекскую БД, которая стала короче, но адекватнее и информативнее. Тестирование этого функционала было закончено за 12 человеко/часов.
Так в чём же недостатки?
Может показаться, что синтетические данные всесильны. Так оно и есть, пока вы не столкнётесь с человеческим фактором. Синтетические данные преднамеренно создаются людьми и в этом их главный недостаток. Мы физически не можем продумать все возможные варианты развития событий и комбинации входных факторов (да и форс-мажоры никто не отменял). И тут преимущество остаётся за реальными данными.
Преимущества работы с реальными данными
Какие же преимущества мы видим в работе с реальными данными? 4 пруфа из нашего опыта:
1. Работа с большими объёмами информации
Реальная работа системы предоставляет нам миллионы операций. Повторить одновременную работу тысяч пользователей или автоматическую генерацию данных не сможет ни одна команда специалистов.
Пруф: мы создали синтетическую мини-БД, которая, как нам казалось, соответствовала всем критериям существующей у заказчика базы. С синтетической базой всё работало великолепно, но стоило запустить тесты с реальной базой, как всё посыпалось. Итог: если не можете учесть все нюансы реальной выборки данных, не тратьте время на генерацию синтетических данных.
2. Использование разнообразных форматов данных
Текст, звук, видео, изображения, исполняемые файлы, архивы — невозможно предугадать, что пользователь решит загрузить в поле формы. Подсказки о принимаемых форматах могут игнорироваться, а запрет на загрузку может быть не реализован командой разработки. В итоге тестируются желаемые сценарии. Например, что в поле загрузки звука, действительно, можно загрузить файл формата mp3 и что загрузка исполняемого файла не навредит системе. Отслеживать же исключения нам помогают реальные данные.
Пруф: мы тестировали поле загрузки фотографии в профиль пользователя. Попробовали самые распространенные графические форматы из базы, плюс несколько видео- и текстовые файлы. Синтетическая подборка загружалась отлично. При реальной эксплуатации выяснилось, что любая попытка загрузить звуковой файл вызывает ошибку. Вся регистрационная форма крашилась без возможности заменить файл. Не спасало даже обновление страницы.
3. Непредсказуемость поведения пользователей
Хотя многие QA-специалисты преуспели в создании и анализе исключительных ситуаций, давайте признаемся честно — мы никогда не сможем точно спрогнозировать, как поведет себя человек и окружающие его факторы. Причём начинать можно с отключения интернета в момент выполнения операции, а заканчивать операциями с кодом программы и внутренними файлами.
Пруф: у нас в компании каждый год сотрудники проходят аттестацию, где, в числе прочего, оценивают свои навыки в специальной анкете. Оценки согласовываются с руководителем, и на основе их рассчитывается грейд (уровень) специалиста. Перед релизом модуль был полностью проверен, всё работало как часы. Но однажды именно в момент сохранения результатов на систему была совершена ddos-атака, в результате которой сохранилась только часть данных, а последующие попытки сохранения только дублировали ошибки. Без реальной ситуации мы бы не отследили такую серьезную ошибку.
4. Обновления систем
Очень важно понимать, как поведёт себя система при обновлении, какие возможны риски, что может «не взлететь». В программах типа 1С, где огромное количество справочников и связей, вопрос обновлений стоит особенно остро. И здесь лучшим вариантом будет иметь свежую копию продакшен-версии, тестировать обновление на ней, и только потом релизиться.
Пруф: случай достаточно распространенный. Проект в сфере факторинговых услуг. Критичность потери и искажения данных зашкаливает, а любое подозрение к актуальности воспроизводимых системой данных может остановить работу всего офиса. И тут наш спец криво выкатывает очередное обновление сразу на прод, не захватив при этом последние 10 версий билдов.
Выкатили в 18-00 пофиксили на утро, часов в 11. Из-за несостоявшейся доработки и непоняток с версиями, целых 2 часа была полностью заморожена работа подразделений компании. Менеджеры не могли обрабатывать текущие договоры и регистрировать новые.
С тех пор мы в обязательном порядке работаем с тремя стендами:
Так с какими данными и когда работать?
Делимся 3 инсайтами нашей работы с реальными и синтетическими данными:
1. Помните, что выбор типа данных зависит от целей и этапа тестирования. Так, разрабатывая новую систему, мы можем оперировать только синтетическими данными. Для покрытия различных комбинаций входных условий, тоже, чаще всего, обратимся к ним. А вот воспроизводство какого-нибудь хитрого исключения, связанного с поведением пользователя, потребует уже реальных логов. Это же относится к работе с общепринятыми справочниками и реестрами.
2. Не забывайте оптимизировать свою работу с тестовыми данными. Где можно, используйте генераторы, формируйте общие реестры основных сущностей, вовремя сохраняйте и используйте бэкапы системы, разворачивая их в нужный момент. Тогда подготовка к очередному проекту будет для вас не источником тоски и уныния, а одним из этапов работы.
3. Не переходите на сторону сплошной синтетики, но и не зацикливайтесь на реальных данных. Используйте комбинированный подход к тестовым данными, чтобы не пропускать ошибки, экономить время и показывать максимальные результаты в своей работе.
Несмотря на то, что синтетике пророчат большое будущее, а учёные увидели в синтетических данных новую надежду искусственного интеллекта, синтетика в тестировании никакой панацеей не является. Это лишь очередной подход к генерации тестовых данных, который может помочь решить ваши проблемы, а может привести к появлению новых. Знание сильных и слабых сторон реальных/синтетических данных, а также умение в нужный момент их применить, вот что защищает вас от убытков, простоя в работе или судебного иска. Надеюсь сегодня мы помогли вам стать чуть-чуть защищеннее. Или нет?
Давайте обсудим. Расскажите в комментариях о своих кейсах работы с синтетическими и реальными тестовыми данными. Давайте разберёмся, кого среди нас больше: реалистов или синтетиков? 😉
Виктория Соковикова.
Тест-аналитик at «Лаборатория качества»