4.7. Техники тестирования требований
4.7.1. Анализ требований
Анализ требований – это проверка требования, в ходе которого его изучают и проводят последующий анализ и оценку качества.
Пример
В ходе разработки системы по управлению задачами в проекте одно из требований говорит, что система позволяет пользователям создавать задачи без указания даты начала и даты конца. В то же время другое требование четко гласит, что каждая задача обязана иметь определенный срок. В ходе анализа этих требований становится ясно, что они противоречат друг другу, а значит перед тем, как их реализовывать, необходим пересмотр.
4.7.2. Прототипирование
Прототипирование – это процесс, при котором создаются рабочие модели ключевых особенностей системы. Такие прототипы можно использовать для проверки требований и их уточнения.
Пример
Создан прототип веб–интерфейса корзины покупок. Хоть это только первоначальный набросок того, что реализуют в будущем, уже можно понять, удобен ли функционал для пользователя и правильно ли определён механизм выполнения покупок. Имея прототипы, можно понять, какие требования были ошибочны или недостаточно проработаны. Это позволит в дальнейшем эффективнее пройти валидацию.
4.7.3. Проверка на соответствие
Проверка на соответствие – это техника, в ходе которой проводят проверку требований на предмет соответствия нормативным актам, стандартам и внутренним документам компании.
Пример
При разработке мобильного приложения для банка важно шифровать данные в соответствии с международными стандартами. Такая проверка подтвердит или опровергнет соответствие приложения этим требованиям до того, как с ним начнут работать пользователи.
4.7.4. Анализ проблем
Анализ проблем – это техника, ориентированная на поиск возможных проблем и сложностей в реализации требований с целью предложить решения и альтернативы.
Пример
Вы разрабатываете мобильное приложение для отслеживания точного маршрута пользователя с помощью GPS. При анализе потенциальных проблем становится ясно, что в густонаселенных районах и внутри зданий GPS сигнал может быть слишком слабым для того, чтобы данные оставались точными, к тому же он может полностью исчезнуть. Возможным решением станет использование алгоритма, объединяющего информацию GPS и позиционирование с помощью вышек сотовой связи.
Такие техники помогают обеспечить качество требований на разных уровнях и этапах создания продукта, минимизируя риски, недопонимания и уменьшая расходы на разработку.
4.8. Тест–дизайн и техники тестирования
Тест–дизайн – это процесс создания планов тестирования и тестовых случаев на основе требований и других критериев.
Одна из проблем тестирования – огромное, стремящееся к бесконечности, количество вариаций состояния программного обеспечения. Однако математическая статистика показывает, что количество проверок можно многократно сократить, при этом полностью или почти не ухудшая их качество. С этой задачей и помогают справиться техники тест–дизайна. Все они на самом деле довольно просты и логичны, а вместе на практике составляют мощный инструмент тестирования.
4.8.1. Техника разделения на классы эквивалентности
Техника делит все тестовые данные на группы. Использование любого значения из отдельной группы будет равносильно использованию любого другого значения из этой же группы.
Пример
Если приложение принимает ввод числа от 1 до 100, то можно определить три класса эквивалентности: числа меньше 1, числа от 1 до 100 и числа больше 100. Достаточно протестировать по одному значению из каждого класса. Таким образом, вместо огромного количество вариантов остается только три, что существенно сократит время тестирования.
4.8.2. Техника граничных значений
Эта техника заключается в тестировании граничных значений классов эквивалентности. Это связано с тем, что статистически ошибки часто могут возникать именно на границах между классами.
Пример
Продолжаем пример с приложением, принимающим числа от 1 до 100. У нас имеется две границы целых чисел: 1 и 100. Применяя технику граничных значений, можно сделать вывод, что необходимо проверить значения 0, 1, 100 и 101. То есть, используется одно значение из группы значений выше правильных данных, одно – ниже их и два значения из одной группы, которые являются границами.
Во время тестирования важно также учитывать тот факт, что в приложение можно попытаться ввести не числа, а совсем другие данные, например, специальные символы и буквы. В этом случае они будут частью некорректных данных, которые нужно проверить.
Техники разбиения на классы и граничных значений обычно применяют вместе, причем не только на данных в виде чисел. Например, группами эквивалентных значений могут быть алфавиты двух языков или две группы форматов файлов: изображений и всех остальных форматов, не относящихся к ним.
4.8.3. Техника попарного тестирования
Не все данные можно разделить, устанавливая между ними границы. В этом случае для качественного тестирования пришлось бы проверять все вариации. Однако часто в таких ситуациях существует два и более отдельных параметра, в каждом из которых надо проверить все значения.
Техника попарного тестирования позволяет значительно уменьшить количество комбинаций за счет эффективного использования тестовых данных. Она основана на статистическом утверждении: ошибки чаще возникают, когда тестируемое приложение использует два и более отдельных параметра, например, два поля ввода информации.
Пример
При тестировании формы вам необходимо проверить, корректно ли она работает в нескольких операционных системах, браузерах и языках.
Набор данных будет такой:
– Операционные системы (Windows, macOS, Linux).
– Браузеры (Firefox, Chrome, Safari).
– Языки (Английский, Русский, Испанский).
Вычислить все варианты проверок несложно: 3 (Операционные системы) × 3 (Браузеры) × 3 (Языки) = 27 тестов.
Попарное тестирование дает высокую вероятность того, что при правильной комбинации данных качество проверок не пострадает. Для этого нужно, чтобы каждая пара значений была проверена хотя бы один раз. В таком случае результатом будут 9 тестов, представленные ниже.
4.8.4. Техника таблицы принятия решений
В примере попарного тестирования система имела только один ожидаемый результат поведения: форма работает корректно. Однако отклик системы нередко имеет множество вариантов, которые зависят от самых разных факторов, и при тестировании сложного функционала есть вероятность упустить один из результатов корректной работы приложения. Техника таблицы принятия решений переиспользует технику парного тестирования и расширяет ее описанием того, какой отклик системы ожидается. Цель техники – акцентироваться на результате работы системы, ее задача – визуализировать, систематизировать и не упустить все отклики системы при различных наборах данных.
Пример
Вам необходимо протестировать работу системы скидок в магазине. Она принимает только два параметра, каждый из которых имеет несколько вариантов:
– Тип аккаунта пользователя: стандартный аккаунт, Премиум аккаунт.
– Итоговая сумма покупки пользователя: сумма покупки ниже 500$, сумма покупки от 500$.
После применения попарного тестирования таблица будет такой:
После применения техники таблицы принятия решения:
4.8.5. Техника состояний и переходов
Эта техника призвана визуализировать и делать акцент на состояниях с переходами между ними в приложении (если такие есть). Она необходима, чтобы эффективнее тестировать сложные системы, не забывая обо всех их частях. Примерами такой системы могут быть состояния заказанного товара на маркетплейсе или состояния заявки на открытие банковского счета.
Пример
Рассмотрим систему управления доступом, которая позволяет попадать в здание при успешном сканировании допустимого идентификатора (сканирование ID карты или ввода кода доступа) и блокирует вход при неудачной попытке. Система может находиться в различных состояниях, в зависимости от операций пользователя и её внутренних событий.
Состояния:
– Ожидание: система находится в покое и ожидает от пользователя ввода ID карты.
– Аутентификация: система получила ID и проверяет его на предмет подлинности и достаточности уровня прав доступа.
– Доступ разрешен: система закончила проверку ID и разрешает пользователю вход.
– Доступ запрещен: система закончила проверку ID и отказала пользователю в возможности входа.
– Блокировка: система временно заблокирована после трёх подряд неудачных попыток ввода.
Визуализация состояний ниже
Чтобы система начала менять свои состояния, необходимо совершать с ней определенные действия (переходы), либо же она должна выполнять их сама.
Переходы:
– Ожидание –> Аутентификация: при вводе ID и отправке его в систему.
– Аутентификация –> Доступ разрешён: если ID успешно прошел проверку системой.
– Аутентификация –> Доступ запрещён: если ID прошел проверку системой неуспешно.
– Доступ разрешён –> Ожидание: после успешного входа.
– Доступ запрещён –> Ожидание: после отклонения доступа.
– Доступ запрещён –> Блокировка: если число неудачных попыток превышает допустимый лимит.
– Блокировка –> Ожидание: после истечения времени блокировки.
Визуализация состояний с переходами ниже
Тестовые случаи, которые можно создать:
Тест ожидания ввода:
Тест использования допустимого ID:
Тест использования недопустимого ID:
Тест неудачных попыток ввода:
Тест разблокировки системы:
Тест повторного доступа после успешного входа:
Как вы могли заметить, техники тест-дизайна очень тесно связаны и позволяют всесторонне сократить количество тестовых проверок, при этом статистически не ухудшая их качество. И несмотря на то, что существует небольшая вероятность упустить ошибку из–за использования значительно меньшего количества проверок, эти техники уже много лет крайне эффективны и более чем оправдывают такой небольшой риск.
4.9. Ошибка, дефект и сбой
Обычно любое зарегистрированное несоответствие между ожидаемым и фактическим поведением системы называют “Баг”. То есть, место в коде, которое работает некорректно, называют “Баг” и сам Bug Report называют “Баг”. Качественное понимание того, как возникают “Баги” и где их можно ожидать, помогает находить эти самые несоответствия более качественно.
Ошибка обычно относится к проблеме в исходном коде, созданной программистом или любыми другими членами команды, участвующими в разработке требований или их реализации. Это может быть логическая ошибка, опечатка, неправильное использование API или любая другая проблема, приводящая к некорректному поведению программы. Ошибка указывает на расхождение между ожидаемым и фактическим поведением программы.
Примеры
– Программист случайно использует при сравнении значений оператор «>» вместо «>=», что приводит к непредвиденным результатам операции.
– Системный аналитик неверно понял требование заказчика к системе и создал такой алгоритм расчета цены на товар в магазине, работа которого приводит к погрешностям в вычислениях.
Дефект – это формально зарегистрированная проблема, обнаруженная в программном продукте, которая указывает на то, что программа не соответствует своим спецификациям или требованиям. Дефекты возникают, когда зарегистрированные результаты работы программы не соответствуют ожиданиям или когда в программе обнаруживают ошибку, влияющую на ее функциональность.
Примеры
– Функция калькулятора, которая должна складывать два числа, выдаёт неверный результат при сложении больших чисел из–за ошибки в коде.
– При заполнении формы регистрации, в систему не отправляются данные домашнего адреса пользователя, хотя для него все выглядит так, будто данные отправлены полностью.
Сбой – это событие, при котором система не выполняет одну или несколько заявленных функций. Сбой происходит, когда программное обеспечение перестает правильно функционировать из–за одного или нескольких дефектов. Сбои видны конечным пользователям и могут привести к потере данных, нарушению работы системы или другим критическим последствиям.
Примеры
– Веб–сайт выдает ошибку сервера и перестает обрабатывать запросы пользователей из–за дефекта, влияющего на этот процесс.
– Нельзя нажать на кнопку выхода из системы из-за дефекта в коде, который отрисовывает кнопку под другим элементом на веб-странице, то есть кнопка есть, но ее не видно.
Коротко, в чем разница?
– Ошибка – это неправильное действие или решение человека (не обязательно разработчика) на этапе разработки, которое потенциально может привести к дефекту.
– Дефект – это обнаруженный недостаток в программном продукте, который указывает на расхождение между фактическим и ожидаемым поведением программы.
– Сбой – это ситуация, когда из–за одного или нескольких дефектов программное обеспечение не выполняет требуемую функцию, видимую конечному пользователю.
4.10. Приоритетность и критичность
Приоритет и критичность (серьезность) дефекта – это две ключевые характеристики, которые помогают определить важность дефекта и срочность (порядок) его исправления.
Критичность (серьезность) – указывает на то, насколько сильно дефект влияет на систему. Это способ оценки того, насколько серьезно отклонение текущего поведения системы от нормального (ожидаемого).
Уровни критичности:
– Критическая: дефект приводит к аварийному завершению работы приложения или потере данных. Например, уязвимость безопасности, позволяющая выполнять произвольный вредоносный код.
– Высокая: дефект серьезно влияет на функциональность приложения, но не приводит к сбою всей системы. Например, функция сохранения важного и часто используемого документа не работает.
– Средняя: дефект влияет на функциональность, но существуют обходные пути. Например, некорректно работает отображение всплывающих подсказок, но основная функциональность доступна.
– Низкая: дефект имеет минимальное влияние на пользовательский опыт или представляет собой малозначимый визуальный недостаток. Например, опечатка в тексте пользовательского интерфейса.
Обратите внимание, что критичность довольно легко определить, когда речь именно о сбоях в работе приложения. Однако есть дефекты, к примеру, безопасности и производительности, с которыми сделать это может быть сложней. Это связано с тем, что у каждой компании и проекта свое представление о том, какой уровень производительности приложения считать критичным. Не всем проектам важна очень высокая производительность и ее ухудшение. Также и с безопасностью: не все проекты нуждаются в поддержке самых передовых способов шифрования, многофакторных аутентификациях и подтверждении личности по сканированию лица.
Приоритет определяет скорость и порядок, с которыми команда разработки должна решить проблему. Он учитывает как серьезность ошибки, так и стратегическую важность ее исправления.
Уровни приоритета:
– Высокий: дефект требует немедленного исправления, поскольку блокирует разработку или выпуск продукта. Например, сбой при запуске приложения.
– Средний: исправление дефекта важно, но не критично для непосредственного выпуска продукта. Работу можно временно продолжать с этой ошибкой. Например, одна из второстепенных ветвей алгоритма по расчету цен на товары работает с ошибкой в вычислениях.
– Низкий: дефект нужно исправить после устранения всех высоких и средних приоритетов. Например, косметический дефект интерфейса пользователя, не влияющий на функциональность.
При этом бывают ситуации, когда дефект имеет низкий уровень критичности влияния на систему, но высокий приоритет исправления. К примеру, опечатка в тексте пользовательского соглашения, которая потенциально может принести огромные убытки, абсолютно не влияет на работу функционала, уровень безопасности и производительности приложения.
5. ДОКУМЕНТАЦИЯ ТЕСТИРОВАНИЯ
5.1. Checklist и Test Case
Test Case (тест-кейс) и Checklist (чек-лист) – это одни из документов, с которыми вы как QA инженер будете чаще всего сталкиваться. В них указано, какие проверки вы будете выполнять в ходе тестирования.
Пройденный чек-лист представляет собой гибкий документ с высоким уровнем абстракции, показывающий, какие важные аспекты были протестированы. Пройденный тест-кейс дает более точное понимание проверок конкретного аспекта системы.
Тест-кейсы и чек-листы пишут одни QA инженеры, а качество написанной документации такого вида на практике проверяют другие QA инженеры или аналитики (не часто). Однако аналитики в силу особенностей своей специализации не знают тонкостей действительного качественного тест-дизайна и скорее всего не сталкиваются с контролем большой системы множества тест-кейсов, ее внутренней согласованности, согласованности с матрицами покрытия требований и планами на будущие изменения. Поэтому желательно чтобы проверкой занимались другие QA инженеры.
5.1.1. Checklist
Checklist (чек-лист) – это список задач или пунктов, которые необходимо проверить, но без детального описания того, как это сделать. Его можно использовать на высоком уровне. В этом случае задача чек-листа – не упустить главные пункты проверок.
Пример
Их также можно использовать на низком уровне. В этом случае анализ входных значений и применение техник тест-дизайна можно выполнять прямо во время тестирования.
Пример
Преимущества чек-листа очевидны:
– Простота и широта применения.
– Написание проверок низкого уровня в таком виде позволяет не тратить время на документацию и заниматься непосредственно тестированием системы.
Недостатки чек-листа заключаются в следующем:
– Отсутствие конкретики на низком уровне тестирования требует от QA инженера навыков, соразмерных сложности задачи. И даже в таком случае есть заметный риск пропустить некоторые проверки.
– В случае любых вопросов к тому, как именно проводится тестирование функционала, нет четкого понимания, как и с какими данными его проводили или будут проводить.
5.1.2. Test Case
Test Case (тест-кейс) – это документ, направленный на проверку конкретного функционала или требования к системе с высоким уровнем подробностей.
Применение техник тест-дизайна порождает несколько наборов тестовых данных, которые можно описать одним или группой тест-кейсов. Каждый из них имеет определенные атрибуты:
– Название – оно должно быть коротким, но отражающим цель описанных в тест-кейсе проверок.
– Предварительные условия (могут быть пустыми) – описывают состояние всего приложения или его частей, а также необходимость выполнить предварительные шаги перед началом тестирования.
– Шаги – набор последовательных действий для получения ожидаемого отклика системы.
– Ожидаемый результат – состояние системы, которое должно получиться после выполнения шагов, обычно напрямую связано с конкретным требованием к приложению.
– Фактический результат (заполняется после прохождения тест-кейса) – фактическое состояние системы после выполнения шагов.
Пример
Фактический результат обычно отражается не полноценным описанием состояния системы, а статусами: «Успешно», «Заблокировано», «Неуспешно». Это связано с тем, что более подробное описание в случае неуспешного прохождения отражается в Bug Report.
Тест-кейс является достаточно сложным и одновременно важным документом для того, чтобы иметь критерии, по которым можно определить его качество. Глобально тест-кейсы неразрывно связаны с требованиями к системе и потому имеют схожие критерии качества.
Понимание уровня качества тест-кейсов на проекте на самом деле может сказать о многом. Во-первых, факт того, что на проекте отслеживают уровень качества, говорит о желании стремиться к эффективным проверкам или хотя бы стабильности в этом вопросе. Во-вторых, это означает, что кому-то на проекте важно иметь прозрачные и контролируемые проверки. В-третьих, это говорит о выстроенных вокруг этой потребности процессах и ответственных за это сотрудников компании. Однако понять то, насколько заботятся об уровне качества и какие процессы для этого выстроены, может быть сложно без погружения в контекст проекта.
Критерии качества тест-кейсов:
– Следование цели – документ должен указывать на определенную цель проверок, а все его атрибуты должны вести к выполнению этой цели.
– Точность – формулировки документа точно и не двусмысленно указывают на необходимость выполняемых действий, ожидаемый результат или объекты, использующиеся в документе.
– Единообразие – в тест-кейсе должны быть одинаковые формулировки и единый формат. Также стоит учитывать другие рекомендации, установленные на проекте.
– Непротиворечивость – все атрибуты документа не противоречат сами себе, то есть полностью согласованы между собой.
– Модифицируемость – формулировка и структура документа написаны таким образом, чтобы в будущем из-за обычных изменений не приходилось исправлять значительную часть тест-кейса.
– Отсутствие избыточности – отсутствие лишних действий или проверок, не относящихся достижению цели, а также длинных формулировок, которые можно сократить без потери смысла. Это свойство также касается согласованности проверок с другими тест-кейсами: нет необходимости выполнять одни и те же проверки в нескольких документах.
– Полнота – документ должен содержать абсолютно всю информацию, чтобы достичь цели тестирования, ради которой он создан, и сравнить ожидаемый результат с фактическим.
– Прослеживаемость – свойство тест-кейса, которое позволяет понять, какое именно требование к системе в нем проверяют. Лучше всего этого можно достигнуть с помощью матрицы трассировки требований, о которой будет сказано позже.
Немного практических советов
Обратите внимание на формулировки в вашем тест-кейсе и то, в каком времени они указаны. Описывая предварительные условия вашего документа, лучше придерживаться формулировки, отвечающей на вопросы «Что сделано?» или «Что должно быть сделано?». Шаги проверок стоит описывать, отвечая на вопрос «Что сделать сейчас?». Ожидаемый результат лучше описывать как завершенное сбывшееся действие, отвечая на вопрос «Что сделано/получено/запущено?»
Почему формулировки важны? Для начала они, конечно же, говорят о вашем уровне владения языком. Если у вас в документе используются разные склонения, то такой тест-кейс просто сложно читать. Второе и не менее важное: правильные формулировки дают больше определенности в восприятии текста.
Пример разного ожидаемого результата
В первом варианте мы ожидаем законченных действий, когда пользователь уже полностью вошел и перенаправление на главную страницу завершено. Во втором варианте мы ожидаем переходного состояния, когда пользователь только в процессе вхождения в систему и перенаправление на главную страницу не завершено, то есть условного «лоадера», указывающего на то, что система в процессе загрузки главной страницы.
Если вы имели в виду первый вариант, но использовали формулировки из второго, то поймет ли это тот, кто будет проходить ваш тест-кейс или же он воспримет текст буквально? Лучше избегать подобных разночтений.
Об атомарности и сложности тест-кейса
Атомарность тест-кейса – это принцип разработки тест-кейсов, который может быть полноправным набором атрибутов их качества, но не обязан быть таковым. Это связано с тем, что не на всех проектах есть возможность делать тест-кейсы атомарными.
Атомарность (как принцип) – это принцип разработки тест-кейсов, при котором каждый из них должен проверять только один конкретный аспект функциональности и быть как можно более простым и сфокусированным, чтобы в случае его неудачного выполнения можно было легко определить причину сбоя.
Атомарность (как набор атрибутов) – это максимально независимые от других повторяемые тест-кейсы с одним, четко описанным ожидаемым результатом. Под ним имеется в виду соответствие вышеупомянутым критериям «Точность», «Непротиворечивость» и «Полнота» в месте описания ожидаемого результата. Один ожидаемый результат означает, что во всем тест-кейсе есть только одно место с описанием ожидаемого результата, и оно в самом конце. После могут быть только постусловия и фактический результат (если его необходимо указывать). В обычных тест-кейсах ожидаемых результатов может быть несколько, включая самый конец документа. При этом единственность ожидаемого результата не говорит о том, что вам надо проверить только одно условное поле с информацией в форме на экране. Таких проверок может быть несколько, но они входят в один ожидаемый результат, если не надо совершать дополнительных действий для их выполнения.
Повторяемость – свойство тест-кейса всегда приводить к одним и тем же результатам при многократном выполнении. По своей сути это указывает на соблюдение вышеупомянутых критериев «Точность», «Непротиворечивость» и «Полнота» в отношении всех атрибутов, помимо ожидаемого результата.
Независимость от других тест-кейсов означает, что выполнение данного тест-кейса не влияет на прохождение других тест-кейсов, не зависит от них и от порядка их выполненния. Независимости можно достигнуть разными способами. Какие-то системы или часть их функционала подходят для достижения этого свойства и не требуют особых усилий. Какие-то напротив нуждаются в четком контроле за всеми аспектами состояния системы и, следовательно, учитывании этого при написании тест-кейсов.
Говоря о сложности тест-кейсов, можно сказать, что атомарные тест-кейсы сами по себе короткие, простые в понимании и проверках. Однако при таком подходе сложно контролировать аспекты системы и согласованность тест-кейсов. На практике далеко не каждый проект может позволить себе атомарные тест-кейсы. Это может быть связано как со спецификой тестируемого продукта, так и с бюджетом проекта.
Говоря о простой, но не самой подходящей специфике продукта, представьте себе приложение, которое позволяет одному пользователю иметь множество сессий и может обновлять происходящее на экране сразу для всех сессий. Такая специфика усложняет не только тестирование атомарными тест-кейсами, а тестирование вообще. Следовательно, чтобы все тест-кейсы выполнялись атомарно, надо проводить их под разными пользователями, которых стоит также подготовить к началу тестирования.
Бюджет проекта в свою очередь ограничивает количество задействованных в тестировании сотрудников и уровень их подготовки. Это реальность, с которой сталкиваются многие QA инженеры. Нередко можно увидеть огромный сложный тест-кейс с множеством целей и ожидаемых результатов. Высокая сложность убирает необходимость готовить систему к многократному тестированию и сокращает время на написание тест-кейса. Также она может устранять необходимость выполнения шагов, которые в атомарных тест-кейсах были бы одинаковыми и необходимыми.
Такой подход к написанию тест-кейсов – часто вынужденная мера на уровне баланса ресурсов и качества. Это приводит к множественности целей и понимания приоритета тест-кейса. Одна цель может быть с высоким приоритетом, а вторая с низким, какой тогда общий приоритет имеет тест-кейс? В какой именно своей части он чаще всего отлавливал ошибки?
Также это влияет на модифицируемость документа в случае обновлений функционала. Объемные тест-кейсы сложны для чтения и понимания сути их действий и проверок. Иногда необходимо удерживать в голове тонкости нескольких таких больших тест-кейсов, чтобы они оставались согласованными после обновления.
Однако в вопросе модифицируемости атомарные тест-кейсы имеют свои недостатки. Да, они легко читаются, но их много, и обновление может затрагивать множество тест-кейсов. Некоторые системы управления тест-кейсами позволяют частично избежать этого с помощью создания наборов шагов, пред- и постусловий, на которые можно ссылаться. Таким образом, можно вносить изменения в один набор, который будет автоматически использоваться множеством тест-кейсов.
Здесь можно сделать логичный вывод: в ситуациях, когда атомарные тест-кейсы по какой-то причине нельзя использовать, лучше сохранять баланс в сложности тест-кейсов.