Вопрос #8
Q: Приведите пример Use Case
A: Use Case. Регистрация пассажира на рейс.
Краткое описание
---—
Система: Система регистрации пассажира на рейс
Основное действующее лицо: Пассажир
Цель: Зарегистрироваться на рейс
Триггер: Пассажир решает зарегистрироваться на рейс и заходит на страницу регистрации сайта
Результат: Информация о регистрации пассажира сохранена. У пассажира есть посадочный талон.
Основной поток событий
---—
Шаг 1. [ Система ] Запрашивает фамилию и код бронирования
Шаг 2. [ Пассажир ] Вводит фамилию и код бронирования
Комментарий: Код бронирования: 7 символов, заглавные латинские и цифры. Например: MTDTC1
Шаг 3. [ Система ] Проверяет, что приобретен билет на этот рейс на имя этого Пассажира
Шаг 4. [ Система ] Сохраняет информацию о регистрации Пассажира на рейс
Шаг 5. [ Система ] Подтверждает Пассажиру, что он зарегистрирован на рейс
Шаг 6. [ Система ] Выводит для печати посадочный талон
Шаг 7. [ Пассажир ] Отправляет посадочный талон на печать
С помощью этого Use Case мы можем выявить большой набор функциональных требований: практически каждая строчка Use Case является отдельным функциональным требованием.
Q: Приведите пример Use Case
A: Use Case. Регистрация пассажира на рейс.
Краткое описание
---—
Система: Система регистрации пассажира на рейс
Основное действующее лицо: Пассажир
Цель: Зарегистрироваться на рейс
Триггер: Пассажир решает зарегистрироваться на рейс и заходит на страницу регистрации сайта
Результат: Информация о регистрации пассажира сохранена. У пассажира есть посадочный талон.
Основной поток событий
---—
Шаг 1. [ Система ] Запрашивает фамилию и код бронирования
Шаг 2. [ Пассажир ] Вводит фамилию и код бронирования
Комментарий: Код бронирования: 7 символов, заглавные латинские и цифры. Например: MTDTC1
Шаг 3. [ Система ] Проверяет, что приобретен билет на этот рейс на имя этого Пассажира
Шаг 4. [ Система ] Сохраняет информацию о регистрации Пассажира на рейс
Шаг 5. [ Система ] Подтверждает Пассажиру, что он зарегистрирован на рейс
Шаг 6. [ Система ] Выводит для печати посадочный талон
Шаг 7. [ Пассажир ] Отправляет посадочный талон на печать
С помощью этого Use Case мы можем выявить большой набор функциональных требований: практически каждая строчка Use Case является отдельным функциональным требованием.
Вопрос #9
Q: Что такое CRUD тестирование?
A: CRUD — акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (create), чтение (read), модификация (update), удаление (delete). Введён Джеймсом Мартином (англ. James Martin) в 1983 году как стандартная классификация функций по манипуляции данными.
CRUD тестирование представляет собой тестирование методом “Черного ящика”. Также в большинстве случаев понятие CRUD тестирование можно считать синонимом Тестирования БД. Очевидно, базы данных являются неотъемлемой часть любого современного приложения: неважно Web или Desktop - данные же должны где-то храниться. В настоящее время на рынке огромное количество вариантов систем управления БД, при этом каждая из них обладает своим набором характеристик.
Если говорить о CRUD операциях с точки зрения конечного пользователя, то можно представить их в таком виде:
1. Create: Сохранение пользователем новых данных
2. Read/Retrieve: Поиск или просмотр пользователем существующих данных
3. Update: Редактирование пользователем существующих данных
4. Delete: Удаление пользователем данных из системы
Q: Что такое CRUD тестирование?
A: CRUD — акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (create), чтение (read), модификация (update), удаление (delete). Введён Джеймсом Мартином (англ. James Martin) в 1983 году как стандартная классификация функций по манипуляции данными.
CRUD тестирование представляет собой тестирование методом “Черного ящика”. Также в большинстве случаев понятие CRUD тестирование можно считать синонимом Тестирования БД. Очевидно, базы данных являются неотъемлемой часть любого современного приложения: неважно Web или Desktop - данные же должны где-то храниться. В настоящее время на рынке огромное количество вариантов систем управления БД, при этом каждая из них обладает своим набором характеристик.
Если говорить о CRUD операциях с точки зрения конечного пользователя, то можно представить их в таком виде:
1. Create: Сохранение пользователем новых данных
2. Read/Retrieve: Поиск или просмотр пользователем существующих данных
3. Update: Редактирование пользователем существующих данных
4. Delete: Удаление пользователем данных из системы
Вопрос #10
Q: Что такое тест-план и из чего он состоит?
A: Тест-план является частью проектной документации и основным документом в тестировании, описывающим весь объем работ по тестированию.
При создании тест-плана можно использовать один из общепринятых шаблонов или создать свой собственный документ, подходящий под ваши нужды.
Варианты общепринятых шаблонов:
1. Темплейты стандарта ISO/IEC/IEEE 29119
2. Шаблон для подготовки плана по тестированию согласно методологии Rational Unified Process (RUP).
3. Тест-план в формате Mind map
В случае, если вами принято решение самостоятельно определить формат документа, то он должен как минимум отвечать на следующие вопросы:
1. [ Что надо ] тестировать (объект тестирования: система, приложение, оборудование)
2. [ Что будете ] тестировать (список функций и компонентов тестируемой системы)
3. [ Как ] будете тестировать (стратегия тестирования – виды тестирования и их применение по отношению к тестируемому объекту)
4. [ Тестовые окружения ], на которых необходимо проверять программный продукт
5. [ Когда ] будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, учёт зависимостей тестовых активностей от задач разработки и смежных групп)
6. [ Риски ] и стратегии по их разрешению
Q: Что такое тест-план и из чего он состоит?
A: Тест-план является частью проектной документации и основным документом в тестировании, описывающим весь объем работ по тестированию.
При создании тест-плана можно использовать один из общепринятых шаблонов или создать свой собственный документ, подходящий под ваши нужды.
Варианты общепринятых шаблонов:
1. Темплейты стандарта ISO/IEC/IEEE 29119
2. Шаблон для подготовки плана по тестированию согласно методологии Rational Unified Process (RUP).
3. Тест-план в формате Mind map
В случае, если вами принято решение самостоятельно определить формат документа, то он должен как минимум отвечать на следующие вопросы:
1. [ Что надо ] тестировать (объект тестирования: система, приложение, оборудование)
2. [ Что будете ] тестировать (список функций и компонентов тестируемой системы)
3. [ Как ] будете тестировать (стратегия тестирования – виды тестирования и их применение по отношению к тестируемому объекту)
4. [ Тестовые окружения ], на которых необходимо проверять программный продукт
5. [ Когда ] будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, учёт зависимостей тестовых активностей от задач разработки и смежных групп)
6. [ Риски ] и стратегии по их разрешению
Smartiqa - платформа о технологиях, программировании и тестировании ПО.
Сайт: https://smartiqa.ru
Канал YouTube: https://www.youtube.com/channel/UCk_7MNLSD0S2fxi0EQ-V6lQ
Vkontakte: https://vk.com/smartiqa
Vkontakte Python: https://vk.com/smartiqa_python
Сайт: https://smartiqa.ru
Канал YouTube: https://www.youtube.com/channel/UCk_7MNLSD0S2fxi0EQ-V6lQ
Vkontakte: https://vk.com/smartiqa
Vkontakte Python: https://vk.com/smartiqa_python
smartiqa.ru
IT Блог: Программирование и QA
Smartiqa - платформа о технологиях, программировании и тестировании ПО. Каждую неделю мы публикуем актуальные новости из мира разработчиков и QA, курсы, образовательные статьи и переводы — создаём поток информации для IT специалистов и всех, кто считает своим…
👍3
Programming & QA pinned «Smartiqa - платформа о технологиях, программировании и тестировании ПО. Сайт: https://smartiqa.ru Канал YouTube: https://www.youtube.com/channel/UCk_7MNLSD0S2fxi0EQ-V6lQ Vkontakte: https://vk.com/smartiqa Vkontakte Python: https://vk.com/smartiqa_python»
Вопрос #11
Q: Что такое уровни детализации тест-плана?
A: В зависимости от особенностей проекта и методологии работы, бывает достаточным создание одного тест-плана или нескольких наследуемых тест-планов. В случае создания иерархии планов, обобщающий называется Мастер тест-планом, а вложенные — просто тест-планом или детальным тест-планом.
[ Master Test Plan ]
Мастер тест-план создается в двух случаях:
1. Если продукт имеет множество релизов или итераций, между которыми сохраняется общая информация, которую нет смысла повторять
2. Если различные тестовые команды работают над одним продуктом, выполняя различные задачи, которые необходимо объединить в рамках одного документа
В Мастер тест-плане содержится следующая информация:
1. Общая информация о продукте, ссылки на документацию, баг-трекер и прочие проектные ресурсы
2. Общие правила тестирования: требования к заводимым дефектам, условия принятия сборки на тестирование
3. Критерии готовности продукта к выпуску, метрики качества
4. Используемые инструменты и техники
[ Test Plan / Level Test PLan ]
Детальный тест-план составляется на каждый релиз/итерацию или для каждой команды в рамках проекта. Его основная цель — кратко и доходчиво отразить задачи тестирования.
В детальном тест-плане содержится следующая информация:
1. Перечень областей тестирования с приоритетами
2. Стратегия тестирования
3. Проектные риски
4. Ресурсы, необходимые для выполнения задач
5. Проектный план (сроки готовности ключевых задач)
Q: Что такое уровни детализации тест-плана?
A: В зависимости от особенностей проекта и методологии работы, бывает достаточным создание одного тест-плана или нескольких наследуемых тест-планов. В случае создания иерархии планов, обобщающий называется Мастер тест-планом, а вложенные — просто тест-планом или детальным тест-планом.
[ Master Test Plan ]
Мастер тест-план создается в двух случаях:
1. Если продукт имеет множество релизов или итераций, между которыми сохраняется общая информация, которую нет смысла повторять
2. Если различные тестовые команды работают над одним продуктом, выполняя различные задачи, которые необходимо объединить в рамках одного документа
В Мастер тест-плане содержится следующая информация:
1. Общая информация о продукте, ссылки на документацию, баг-трекер и прочие проектные ресурсы
2. Общие правила тестирования: требования к заводимым дефектам, условия принятия сборки на тестирование
3. Критерии готовности продукта к выпуску, метрики качества
4. Используемые инструменты и техники
[ Test Plan / Level Test PLan ]
Детальный тест-план составляется на каждый релиз/итерацию или для каждой команды в рамках проекта. Его основная цель — кратко и доходчиво отразить задачи тестирования.
В детальном тест-плане содержится следующая информация:
1. Перечень областей тестирования с приоритетами
2. Стратегия тестирования
3. Проектные риски
4. Ресурсы, необходимые для выполнения задач
5. Проектный план (сроки готовности ключевых задач)
Вопрос #12
Q: Как правильно оценить риски по время составления плана тестирования?
A: Риск — это вероятность того, что дефекты в проекте повлекут за собой финансовые проблемы, нанесут урон репутации компании, снизят доверие клиентов, увеличат сроки исполнения проекта и затраты на его реализацию. Стратегия управления рисками — часть планирования тестирования.
Информация о рисках, влияющих на проект, используется при расстановке приоритетов при планировании тестирования. Например, если производительность системы — наиболее рискованная область, тестирование производительности может выполняться как можно раньше.
Определение рисков проекта:
1. Какие функции и атрибуты проекта являются критическим функционалом?
2. Насколько видимой будет проблема в функции/атрибуте для пользователей, заказчика и других заинтересованных лиц?
3. Насколько часто используется функция?
Риски также могут не относиться непосредственно к продукту, но влиять на приоритеты тестирования:
1. Проблемы с квалификацией персонала
2. Нехватка персонала
3. Проблемы с координацией и кооперацией
4. Нехватка инструментов
Q: Как правильно оценить риски по время составления плана тестирования?
A: Риск — это вероятность того, что дефекты в проекте повлекут за собой финансовые проблемы, нанесут урон репутации компании, снизят доверие клиентов, увеличат сроки исполнения проекта и затраты на его реализацию. Стратегия управления рисками — часть планирования тестирования.
Информация о рисках, влияющих на проект, используется при расстановке приоритетов при планировании тестирования. Например, если производительность системы — наиболее рискованная область, тестирование производительности может выполняться как можно раньше.
Определение рисков проекта:
1. Какие функции и атрибуты проекта являются критическим функционалом?
2. Насколько видимой будет проблема в функции/атрибуте для пользователей, заказчика и других заинтересованных лиц?
3. Насколько часто используется функция?
Риски также могут не относиться непосредственно к продукту, но влиять на приоритеты тестирования:
1. Проблемы с квалификацией персонала
2. Нехватка персонала
3. Проблемы с координацией и кооперацией
4. Нехватка инструментов
- - - - - - - - -
Собеседование на тестировщика (Junior QA) / Вопросы на собеседовании QA
- - - - - - - - -
В видео говорится о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное письмо? Именно правильно составленное резюме поможет вам без труда найти работу или как минимум попасть на интервью.
https://www.youtube.com/watch?v=UYZgZ2uYbfw
Собеседование на тестировщика (Junior QA) / Вопросы на собеседовании QA
- - - - - - - - -
В видео говорится о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное письмо? Именно правильно составленное резюме поможет вам без труда найти работу или как минимум попасть на интервью.
https://www.youtube.com/watch?v=UYZgZ2uYbfw
YouTube
Как создать резюме для тестировщика и других IT-специалистов
🚀 Забери интенсив по трудоустройству с личным разбором резюме https://stepik.org/a/248267
Сегодня поговорим о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное…
Сегодня поговорим о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное…
Вопрос #13
Q: Какие изменения произошли в выборе подходов к тестированию в последние годы?
A: Двадцать лет назад разработка почти всех систем происходила примерно одинаково. Между системами не было таких серьезных различий, как в наши дни. Вот основные изменения, которые произошли с тех пор:
1. Гибкость в разработке преобладает над четким планированием.
2. Мы больше ориентируемся на мастерство, чем на методы.
3. Цели важнее, чем процесс. Если раньше мы следовали двухсотстраничному руководству, в котором был пошагово описан весь процесс тестирования, сегодня в этом нет необходимости. Важно смотреть, какого результата мы хотим достичь, и делать все для этого.
4. Быстрое тестирование преобладает над основательным. Большинство организаций хотят выйти на рынок как можно быстрее.
5. Прагматичные методы преобладают над стандартами. Следование стандартам может увеличить время тестирования, количество необходимой документации и требуемого персонала более чем в три раза. Поэтому даже в организациях, которые занимаются стандартизацией, часто отказываются от тестирования по стандартам.
Q: Какие изменения произошли в выборе подходов к тестированию в последние годы?
A: Двадцать лет назад разработка почти всех систем происходила примерно одинаково. Между системами не было таких серьезных различий, как в наши дни. Вот основные изменения, которые произошли с тех пор:
1. Гибкость в разработке преобладает над четким планированием.
2. Мы больше ориентируемся на мастерство, чем на методы.
3. Цели важнее, чем процесс. Если раньше мы следовали двухсотстраничному руководству, в котором был пошагово описан весь процесс тестирования, сегодня в этом нет необходимости. Важно смотреть, какого результата мы хотим достичь, и делать все для этого.
4. Быстрое тестирование преобладает над основательным. Большинство организаций хотят выйти на рынок как можно быстрее.
5. Прагматичные методы преобладают над стандартами. Следование стандартам может увеличить время тестирования, количество необходимой документации и требуемого персонала более чем в три раза. Поэтому даже в организациях, которые занимаются стандартизацией, часто отказываются от тестирования по стандартам.
Вопрос #14
Q: Какие основные виды подходов к тестированию вы знаете?
A: Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).
Основная особенность сценарного тестирования заключается в том, что вы начинаете с того, что делите задачу на этапы (подготовка, выполнение, завершение и пр.) и затем стараетесь производить все действия согласно этим этапам. То есть этот подход можно охарактеризовать как «я думаю над этим заранее и затем выполняю».
Исследовательское тестирование подразумевает совершенно иной подход – разработка процесса тестирования происходит непосредственно во время работы. Тестирование начинается с некой важной точки, в процессе появляются другие важные точки тестирования, и каждый раз специалист решает, какая из них наиболее важна и в каком направлении двигаться дальше. То есть продумывание и запуск тестов происходят в постоянном взаимодействии.
Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Скорее всего, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.
Q: Какие основные виды подходов к тестированию вы знаете?
A: Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).
Основная особенность сценарного тестирования заключается в том, что вы начинаете с того, что делите задачу на этапы (подготовка, выполнение, завершение и пр.) и затем стараетесь производить все действия согласно этим этапам. То есть этот подход можно охарактеризовать как «я думаю над этим заранее и затем выполняю».
Исследовательское тестирование подразумевает совершенно иной подход – разработка процесса тестирования происходит непосредственно во время работы. Тестирование начинается с некой важной точки, в процессе появляются другие важные точки тестирования, и каждый раз специалист решает, какая из них наиболее важна и в каком направлении двигаться дальше. То есть продумывание и запуск тестов происходят в постоянном взаимодействии.
Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Скорее всего, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.
Приглашаем обсудить QA в финтехе на онлайн-конференции ЮMoneyDay: https://events.yoomoney.ru/yoomoneyday_2021.
🔍🐞 Сначала узнаем, как устроен наш процесс разработки. Затем тестировщики выступят с докладами:
— К каким выводам мы пришли, собирая метрики тестирования, и что из процессов удалось автоматизировать.
— Когда для полнотекстового поиска можно использовать PostgreSQL.
📍Регистрируйся по ссылке! Начало конференции 13 ноября в 10:00. Секция по тестированию стартует в 15:20.
🔍🐞 Сначала узнаем, как устроен наш процесс разработки. Затем тестировщики выступят с докладами:
— К каким выводам мы пришли, собирая метрики тестирования, и что из процессов удалось автоматизировать.
— Когда для полнотекстового поиска можно использовать PostgreSQL.
📍Регистрируйся по ссылке! Начало конференции 13 ноября в 10:00. Секция по тестированию стартует в 15:20.
Вопрос #15
Q: Выше мы поговорили про Сценарный (Scripted) и Исследовательский (Exploratory) подходы к тестированию. Существуют ли иные варианты?
A: Эти два подхода к тестированию – не единственные. Кроме них существуют и другие, которые находятся где-то между ними:
1. Detailed scripting (Подробное сценарное тестирование)
2. Global scripting (Общее сценарное тестирование)
3. Session based testing (Сессионное тестирование)
4. Bug hunts (Поиск багов)
5. Test tours (Тест туры)
6. Freestyle exploratory testing (Исследовательское тестирование)
Взгляните на схему - почему эти подходы расположены именно в таком порядке? Ответ прост: Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.
Профессиональный тестировщик должен знать о каждом из этих подходов и понимать, какой из них лучше всего подойдет в каждом конкретном случае.
В следующих постах разберем эти направления в тестировании подробнее.
Q: Выше мы поговорили про Сценарный (Scripted) и Исследовательский (Exploratory) подходы к тестированию. Существуют ли иные варианты?
A: Эти два подхода к тестированию – не единственные. Кроме них существуют и другие, которые находятся где-то между ними:
1. Detailed scripting (Подробное сценарное тестирование)
2. Global scripting (Общее сценарное тестирование)
3. Session based testing (Сессионное тестирование)
4. Bug hunts (Поиск багов)
5. Test tours (Тест туры)
6. Freestyle exploratory testing (Исследовательское тестирование)
Взгляните на схему - почему эти подходы расположены именно в таком порядке? Ответ прост: Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.
Профессиональный тестировщик должен знать о каждом из этих подходов и понимать, какой из них лучше всего подойдет в каждом конкретном случае.
В следующих постах разберем эти направления в тестировании подробнее.
- - - - - - - - -
QA из Silicon Valley
- - - - - - - - -
В интервью автор постарался детально разобраться в том, как прорваться в Кремниевую Долину и пополнить стройные ряды QA. Необходимые знание и навыки, лайфхаки и дух Долины - всё это в этом выпуске!
https://www.youtube.com/watch?v=V3O0_a4MeUw
QA из Silicon Valley
- - - - - - - - -
В интервью автор постарался детально разобраться в том, как прорваться в Кремниевую Долину и пополнить стройные ряды QA. Необходимые знание и навыки, лайфхаки и дух Долины - всё это в этом выпуске!
https://www.youtube.com/watch?v=V3O0_a4MeUw
YouTube
QA из Silicon Valley / Девушка в IT / Интервью с тестировщицей из Кремниевой Долины
Сегодня у меня в гостях QA Engineer из Silicon Valley - Катя Кравченко. В интервью с Катей я постарался детально разобраться в том, как прорваться в Кремниевую Долину и пополнить стройные ряды QA. Необходимые знание и навыки, лайфхаки и дух Долины - всё это…
Вопрос #16
Q: Чем похожи и чем отличаются следующие виды тестирования: Подробное сценарное и Общее сценарное тестирование (Detailed Scripting & Global scripting) ?
A: Объясняем на примере. Если мы тестируем, скажем, почту, то Подробное сценарное тестирование (Detailed Scripting) может выглядеть так:
1. Перейдите на стартовую страницу
2. Нажмите на кнопку «Новый»
3. В поле «Кому» напишите [email protected]
4. Нажмите на кнопку «Файл»
5. Выберите документ «Тест1»
6. В поле «Тема» напишите «Тестовое вложение <дата>
7. Откройте почтовый ящик [email protected]
8. Проверьте, доставлено ли сообщение и вложение.
Для этого же примера сценарий Общего тестирования (Global scripting) может выглядеть так:
1. Создайте и отправьте письмо с вложением одному получателю
2. Проверьте, доставлено ли сообщение и вложение
Если человек, который готовит тесты и выполняет их, – одно и то же лицо, не имеет никакого смысла делать их слишком детализированными. Поэтому подумайте, стоит ли тратить столько времени на подготовку подробного сценарного тестирования? Возможно, сценария общего тестирования будет вполне достаточно.
Q: Чем похожи и чем отличаются следующие виды тестирования: Подробное сценарное и Общее сценарное тестирование (Detailed Scripting & Global scripting) ?
A: Объясняем на примере. Если мы тестируем, скажем, почту, то Подробное сценарное тестирование (Detailed Scripting) может выглядеть так:
1. Перейдите на стартовую страницу
2. Нажмите на кнопку «Новый»
3. В поле «Кому» напишите [email protected]
4. Нажмите на кнопку «Файл»
5. Выберите документ «Тест1»
6. В поле «Тема» напишите «Тестовое вложение <дата>
7. Откройте почтовый ящик [email protected]
8. Проверьте, доставлено ли сообщение и вложение.
Для этого же примера сценарий Общего тестирования (Global scripting) может выглядеть так:
1. Создайте и отправьте письмо с вложением одному получателю
2. Проверьте, доставлено ли сообщение и вложение
Если человек, который готовит тесты и выполняет их, – одно и то же лицо, не имеет никакого смысла делать их слишком детализированными. Поэтому подумайте, стоит ли тратить столько времени на подготовку подробного сценарного тестирования? Возможно, сценария общего тестирования будет вполне достаточно.