Test rails что такое
BYTEX BLOG
Подробный гайд по TestRail: тестирование ПО
Современный человек ежедневно пользуется различными программами на телефоне и компьютере, практически не задумываясь об особенностях разработки этого софта. В данном процессе важную роль играет тестирование, помогающее устранить ошибки в функционале, которое, в свою очередь, необходимо контролировать. В этом могут помочь специальные «инструменты управления тестированием», одним из которых является TestRail.
Предназначение TestRail
Во время тестирования выполняются различные процессы, направленные на улучшение качества продукта: анализ требований, составление плана тестирования, разработка тест-кейсов и т.д. Среди всех этих действий подготовка тест-кейсов играет очень важную роль.
Многие тестировщики предпочитают записывать тест-кейсы в Excel или другие таблицы. Но в эпоху автоматизации использовать Excel немного старомодно. Причем, существует немалая вероятность потери данных.
Чтобы избавиться от этой проблемы, немецкая компания Gurock Software разработала TestRail — специальное программное обеспечение, помогающее специалистам QA и разработчикам наладить процесс тестирования. Оно помогает контролировать и отслеживать все процессы тестирования программ и организовывать деятельность отдела QA. TestRail обладает простым веб-интерфейсом, что облегчает создание тест-кейсов, управление тестовыми прогонами и т.д. Благодаря ему легко следить за состоянием отдельных этапов тестирования, используя информационные панели и отчеты. Специальные фильтры, уведомления и списки задач помогают получать полную информацию о ходе тестирования.
Особенности TestRail
Основные вкладки TestRail
DashBoard
После авторизации в TestRail открывается стартовая страница. Это рабочий стол, на котором отображаются все проекты и диаграмма активности за последнее время (от 7 до 90 дней). При нажатии на проект открывается страница управления проектом.
Вкладка «Overview» представляет собой сводку по текущему состоянию проекта, которая содержит список недавно завершенных проверок, а также последние тестовые прогоны и предстоящие майлстоуны. На специальной диаграмме активности отображается общий результат тестирования за определенный промежуток времени. Можно посмотреть все пройденные тест-кейсы и их статусы: passed (пройден), failed (не удалось пройти), blocked (заблокирован) и retest (нуждается в повторном тестировании). Всякий раз, когда требуется переключиться на другой проект, нужно вернуться на стартовый экран, нажав на “Return to Dashboard” в верхнем левом углу.
Todo
TodoРаздел Todo является важной частью TestRail и считается отправной точкой для тестировщиков. В чем же заключаются его особенности? Todo-раздел:
Milestone
MilestoneТестировщики могут создавать и работать над несколькими тестовыми прогонами одновременно, более того, некоторые команды работают с различными версиями, итерациями, спринтами и майлстоунами в течении реализации проекта.
Пользователи могут использовать вкладку Milestone для создания отдельных этапов проекта, в которых поэтапно тестируются различные версии.
При создании нового этапа (майлстоуна) можно установить дату его начала и завершения, что помогает отслеживать сроки выполнения и порядок тестирования версий. Также можно добавить описание и пометить завершенные этапы, что поможет сконцентрироваться на активных задачах.
В этом разделе при необходимости можно создать тестовые планы и прогоны для конкретной версии, чтобы легко отслеживать прогресс в этой области. Если команда тестировщиков работает одновременно с несколькими папками, их прогресс отображается параллельно.
Test Runs & Results
Здесь осуществляется управление тест-кейсами и их выполнение в основной части тестирования. TestRail старается как можно сильнее упростить процесс ввода результатов и отслеживания прогресса тестирования.
Тестировщик может создать прогон чек-листа, благодаря кнопке “Add Test Run”. В начале ему потребуется указать имя для теста и по необходимости дополнительные данные:
Test Run можно редактировать и после его создания, изменять майлстоун или добавлять дополнительные кейсы.
После создания тестового прогона можно перейти к его непосредственному выполнению. Нужно будет на странице тест-рана указать статус отдельного тест-кейса, его исполнителя (проверяющего тестировщика) и следить за текущими результатами, статистикой и статусами кейсов. Для проверки кейса и добавления результата его необходимо открыть, ознакомиться с предложенными условиями и, после проведения теста, проставить статус. Также тестировщик может добавить собственный комментарий, указать время, потраченное на проверку, и выявленные баги. Поскольку TestRail может подключаться к Jira, Bugzilla и Firebug в пункте результата под названием “Defects” можно указать идентификатор конкретного бага, заведенного в данных сервисах.
Test Suites and Cases
Данная вкладка является неотъемлемой частью TestRail, здесь создаются и хранятся все тест-кейсы и чек-листы тестируемого приложения, которые необходимо проверять. В проекте может содержаться более тысячи тест-кейсов для различных версий, которые группируются в подразделы для удобного использования. Как правило, это позволяет разбить тестирование проекта на различные группы с определенными типами заданий. Например, одни отвечают за проверку механики или серверной части проекта, другие за проверку интерфейса, локализации и т.д.
Для того, чтобы добавить новый раздел, необходимо нажать на кнопку Add Subsection, и после создания перейти на его страницу, где уже создать необходимые тест-кейсы с помощью «Add Case».
Во время создания тест-кейса по необходимости заполняются следующие поля:
Сервис позволяет изменять или добавлять новые поля, настраивая функционал максимально практично для каждого проекта. Кейс может содержать не только текстовую информацию, но и графическую (картинки).
Также можно создавать таблички внутри кейса еще больше расширяя его возможности.
Готовые кейсы можно переносить между разделами, копировать, экспортировать в XML, Excel/CSV или импортировать из XML или CSV-файла в TestRail.
Report
Отчеты по тестированию важны как и сами задания. Функционал сервиса позволяет генерировать отчетности, отправлять их по почте, а также использовать для их создания готовые шаблоны.
Результат о проделанной работе состоит из фактической информации о проведенном тестировании. TestRail позволяет максимально детализировать отчет, указав в нем статусы кейсов и выявленные ошибки.
Заключение
TestRail — один из самых важных инструментов для управления тестированием программного обеспечения, который помогает в управлении всеми необходимыми процессами. Он включает в себя: создание проекта, подготовку тестовых кейсов, выполнение тестовых прогонов и генерацию подробной отчетности о тестировании.
Подведены итоги IT-конкурса «Мордовия глазами детей»
Артём Здунов поздравил программистов с профессиональным праздником
C 26 по 28 августа 2021 в Уфе проходит финал IХ Национального чемпионата «Молодые профессионалы» (WorldSkills Russia)
В Саранске прошло главное киберспортивное событие этого лета
Артём Здунов посетил BYTEX
© ООО “Байтэкс”, 2004-2021. Все права защищены
TestRail — Индивидуальные настройки под проект
Введение
Во многих проектах, с которыми я работал, люди не настраивали под себя TestRail и обходились стандартными настройками. Поэтому в данной статье я постараюсь описать пример индивидуальных настроек, которые могут помочь Вам повысить эффективность своей работы. Для примера возьмем проект разработки мобильного приложения.
Небольшой дисклеймер. В данной статье нет описания базового функционала TestRail (на это есть много гайдов) и продающих выражений красочно описывающих почему нужно выбрать именно этого вендора для создания репозитория с тестами.
План-обоснование (что будет реализовано)
Кейс должен смочь пройти абсолютно любой человек
Кейсы должны сохранять актуальность как можно дольше
Кейсы должны максимально тщательно покрывать функционал мобильного приложения в той мере, в которой это не противоречит первым двум пунктам
Разделение на TestCase и TestScenario
Быстрое формирование TestRun различных типов
Impact тестирование и т.д.
Оптимизация поддержки кейсов
Отказ от «мертвых» захардкоженных скриншотов и переход на «movable data»
Requirements
Для редактирования полей Вам потребуется администраторский доступ
Выбор типа проекта
Можно выбрать три типа проекта:
Мы выберем тип по умолчанию. В нем будут доступны одновременно все кейсы. Мы будем пользоваться умной фильтрацией и динамически управлять всеми кейсами сразу.
Добавление полей для просмотра списка тест кейсов
Добавим поле для отображения priority тест кейсов:
Также можно добавить и другие поля.
Настройка полей и тегов тест кейса
Открываем меню настройки:
Нам потребуются такие поля:
Поле «Summary» (шапка тест кейса)
Данное поле уже существует, мы только систематизируем его использование. Будем разделять кейсы на TestCase и TestScenario. Для лучшей читаемости большого списка кейсов лучше заранее договорится по регламенту написания summary.
TestScenario:
TestCase:
Итого мы видим в summary кейса классическое понимание: “что, где, когда”. Также визуально мы разделяем верхнеуровневые тестовые сценарии и низкоуровневые тест кейсы в наиболее подходящем для автоматизации виде.
Тег «StartScreen» (экран с которого начинается TestScenario, также многие тест кейсы могут задевать соседние экраны)
Для чего может понадобится: мы будем удалять из текста текст кейсов типовые шаги приводящие пользователя на экран текущего тест кейса. (типовые шаги для создания определенной тестовой ситуации) Все типовые шаги для всех тест кейсов будут прописаны в одном файлике. О нём более подробно напишу отдельно.
Создаем новое поле:
Заполняем компоненты нового поля:
В данном случае мы создаем поле выбора из списка значений. Вводим значения этого поля:
Обратите внимание, что id значений начинаются не с единицы и идут не подряд. Почему так сделано? Дело в том, что если у нас будут записаны тесткейсы с введенным id,
и после этого нам потребуется создать третий экран между двумя существующими,
то нам придется переписать id, и так как к нему уже привязаны теги существующих текст кейсов, то они просто удаляться. Это будет очень неприятно.
Тег «Screen» (наименование экрана который затрагивает TestCase)
Для чего может понадобится: один из якорей для импакт тестирования. Например, разработчики сделали новую крутую фичу. Нам нужно её протестировать, но для это нужно понять, что именно эта фича могла затронуть. По умолчанию мы может отталкиваться от парадигмы, что разные экраны (Activity) приложения имеют разные классы и следовательно составляют различные компоненты приложения. Конечно же в данном случае нужен индивидуальный подход.
Пример: home_screen, MapScreen, PayScreen и т.д.
Поле «MovableData» (cсылка на прокси БД c изменяемыми тестовыми данными)
Далее мы постараемся решить проблему поддержки актуальности данных в тесткейсах:
Ссылки на актуальные макеты (это гораздо лучше чем делать мертвые скриншоты)
Типовые шаги до экрана с тестовой ситуацией
Ссылки на внешние данные и прочие данные
Вместо прописывания тестовых данных внутри каждого тест кейса мы создадим один внешний файл, и на всех тест кейсах сделаем ссылку на него. При обновлении этих данных нам не придется перебирать все тест кейсы и изменять их, а можно будет изменить эти данные только в одном месте. Если кто-то неподготовленный откроет тест кейс, он увидит в теле тест кейса ссылку на файлик и подсказку, что нужно в него идти за тестовыми данными.
Все эти данные мы упакуем в один внешний файлик, который будет доступен всем желающим на проекте. Например можно использовать Google Sheet или Excel и настроить внутри файла поиск. Почему именно эти вендоры? Дело в том, что мы отталкиваемся от парадигмы, что открыть и пройти тест кейс должен смочь любой человек в команде без необходимости предварительно всякие тулзы устанавливать.
Для Google Sheet можно использовать SQL запросы. Пример:
Для Excel можно настроить удобные макросы мгновенного поиска. (фильтрации) Пример по ссылке.
Собственно идея не нова и описана в первой книжке тестировщика “Тестирование dot com”. (автор Савин Роман) Мы лишь только интегрируем в TestRail предложенные Романом Савиным методики. Для этого создадим поле со ссылкой на созданный файлик:
заполняем дефолтное значение ссылки, чтобы в каждом новом тест кейсе уже ссылка была:
Если местоположение внешнего файла изменится (мы предусматриваем любой форс мажор) то можно удобно во всех тест кейсах сразу изменить одно или несколько полей:
Поле “Descriptions” (описание или идея тест кейса, типовые инструкции)
Для чего может понадобится: В данное текстовое поле мы поместим краткое описание тест кейса и типовые инструкции.
Пример: Все тестовые данные (актуальные макеты, использование тулов и прочие данные) из данного тест кейса обозначены ссылками <…>и находятся в файле MovableData. Ссылка на MovableData в соответствующем поле вверху.
Тег «Component» (компонент мобильного приложения)
Для чего может понадобится: для импакт тестирования. Если мобильное приложение можно разделить на компоненты (которые как можно меньше друг друга аффектят) то изменения в одном компоненте будет достаточно (с какими-то рисками) проверить в рамках этого же компонента, и будет меньше оснований для проведения всеобщих регрессов всего и вся. Если есть информация, что один компонент может аффектить другой, то составляется матрица импакт тестирования.
Пример компонентов: GooglePay, Order, Users, Map, Authorization и т.д.
Тег «TAG» (Прочие теги для фильтрации)
Тегирование тест кейса метками для произвольной фильтрации.
быстрого составления TestRun для различных типовых задач: smoke, регресс и т.д.
будут ли тесты автоматизированы или уже автоматизированы
Пример: Smoke, Automated, WhiteLabel, ForDelete и т.д.
Настраиваем порядок отображения полей в тест кейсе
Мы создали много новый полей, пришло время расположить их в удобном порядке:
Создание TestRun
Теперь мы создадим новый test run с актуальными кейсами для проведения smoke тестирования в три клика:
Другие полезные советы
Если в TestRail несколько проектов, то не забывайте создавать новые поля только под Ваш проект иначе коллеги из соседних комманд очень сильно удивятся появлению новых необычных полей. Возможны локальные обмороки.
2. Кейсы с большим количеством полей проще копировать из аналогичной группы\типа чем создавать новые:
3. Можно использовать учетные записи совместно. Например: одна администраторская, несколько пользовательских.
Заключение
Вышеописанные примеры были внедрены на несколько проектов и показали свою эффективность. Надеюсь они помогут улучшить Ваше понимание данной тулы и помогут создавать эффективные и удобные“тестохранилки”. Буду очень благодарен, если Вы в комментариях опишите Ваш опыт использования TestRail и полезные советы.
TestRail: как сначала подумать, а потом протестировать
Надеюсь, многие из вас знают, что в тестировании тоже есть документация. И вести ее можно по-олдскульному, в xls-файлах да в папочках или же, как настоящие джедаи, использовать специализированный инструмент.
Вот об одном из таких инструментов под названием TestRail, который мы недавно внедрили у себя в TestLab², я и хочу сегодня рассказать. Инструмент оказался настолько удачным, что молчать сил не было и я решил наконец-то сделать что-то полезное для общества.
Для всех проектов, которые мы тестируем, всегда обязательно пишется тестовая документация, от небольшого чеклиста до развесистого test suite с кросс-ссылками и сотнями кейсов. От идеи хранить документацию в локальных файлах отказались сразу и напрочь, это неудобно и просто непрофессионально. Пробовали «универсальное» решение, wiki (DokuWiki), но она не прижилась. Тут сложно сказать почему, пожалуй, дело привычки, и можно было бы «насадить добро палками», но тут подвернулся TestRail и понеслась.
Установка и системные требования
Два варианта: типичный LAMP или «IIS+SQLServer+FastCGI/PHP». Также потребуется ionCube и cURL, но это не редкость. Работает достаточно быстро, а после включения gzip через mod_deflate стало вообще пулей летать.
Основные возможности
Многопользовательская многопроектная система для ведения тестовой документации и учета результатов выполнения тестов. В продукте предусмотрено место для всех: для тест-менеджеров, которых больше интересует «когда будет» и «сколько багов», для простых тестировщиков, которым удобно отчитываться о пройденных кейсах, для аналитиков, которые смогут вгрызаться в самые дебри и выяснять чего ж оно всё так хреновов чем соль.
Как выглядит рабочий процесс
Сравнение с конкурентами
Личные впечатления
Для нас система оказалась практически идеальной и в плане минимально необходимого набора фич, и в плане удобства ежедневного использования. Мы занимаемся аутсорс-тестированием и ведем достаточно много небольших проектов, что отлично ложится в лицензионную политику вендора: лимит ограничивает только количество активных пользователей системы, поэтому мы деактивируем клиентские эккаунты по окончании проектов.
Из недостатков стоит отметить два: в текущей версии TestRail не поддерживает Unicode что означает, что вести документацию на русском/украинском языке в текущей версии без хаков невозможно. Но соответсвующий feature request уже заявлен, должны скоро добавить. Для нашей команды это непринципиально потому, что пока все проекты, достойные попадания в TestRail, ведутся на английском языке.
Вторая проблема — это отсутсвтие какого-то wysiwyg-редактора во всех text edit-полях. Это радует инженеров, но регулярно смущает заказчиков.
Резюме
Если вы ведете тестовую документацию по большому проекту, или уже теряетесь в тоннах doc- и xls-файлов с кейсами — вам стоит обратить внимание на TestRail. Это продукт, который не нужен всем и каждому, но если вы занимаетесь тестированием профессионально, то запомните это название, возможно, TestRail пригодится вам в следующем проекте.
Если будет интересно — я готов развивать тему различных тулов для тестирования и, к примеру, внимательно изучить ту же Testopia, чтобы рассказать вам о ней. Пишите в комменты.
*Умеющие гуглить могут найти в интернетах купоны на скидки.
Подробный гайд по TestRail: тестирование ПО
Современный человек ежедневно пользуется различными программами на телефоне и компьютере, практически не задумываясь об особенностях разработки этого софта. В данном процессе важную роль играет тестирование, помогающее устранить ошибки в функционале, и которое, в свою очередь, необходимо контролировать. В этом могут помочь специальные «инструменты управления тестированием», одним из которых является TestRail.
Предназначение TestRail
Во время тестирования выполняются различные процессы, направленные на улучшение качества продукта: анализ требований, составление плана тестирования, разработка тест-кейсов и т. д. Среди всех этих действий подготовка тест-кейсов играет очень важную роль.
Многие тестировщики предпочитают записывать тест-кейсы в Excel или другие таблицы. Но в эпоху автоматизации использовать Excel немного старомодно. Причём существует немалая вероятность потери данных.
Чтобы избавиться от этой проблемы, немецкая компания Gurock Software разработала TestRail — специальное программное обеспечение, помогающее специалистам QA и разработчикам наладить процесс тестирования. Оно помогает контролировать и отслеживать все процессы тестирования программ и организовывать деятельность отдела QA.
TestRail обладает простым веб-интерфейсом, что облегчает создание тест-кейсов, управление тестовыми прогонами и т. д. Благодаря ему легко следить за состоянием отдельных этапов тестирования, используя информационные панели и отчёты.
Специальные фильтры, уведомления и списки задач помогают получать полную информацию о ходе тестирования.
Особенности TestRail:
— удобное разделение и эффективное управление тест-кейсами, сьютами и тест-планами; — простой и удобный пользовательский интерфейс; — графическое отображение тестового прогона; — предоставление информации о ходе тестирования в реальном времени; — интеграция с такими баг-трекерами, как Jira; — гибкость и настраиваемость под любые нужды; — развитая система генерирования отчетности; — организация и отслеживание действий всех сотрудников; — лицензируется по количеству реально пользующихся им пользователей.
Основные вкладки TestRail
DashBoard После авторизации в TestRail открывается стартовая страница. Это рабочий стол, на котором отображаются все проекты и диаграмма активности за последнее время (от 7 до 90 дней). При нажатии на проект открывается страница управления проектом.
Вкладка «Overview» представляет собой сводку по текущему состоянию проекта, которая содержит список недавно завершённых проверок, а также последние тестовые прогоны и предстоящие майлстоуны. На специальной диаграмме активности отображается общий результат тестирования за определённый промежуток времени.
Можно посмотреть все пройденные тест-кейсы и их статусы: passed (пройден), failed (не удалось пройти), blocked (заблокирован) и retest (нуждается в повторном тестировании). Всякий раз, когда требуется переключиться на другой проект, нужно вернуться на стартовый экран, нажав на «Return to Dashboard» в верхнем левом углу.
Todo Раздел Todo является важной частью TestRail и считается отправной точкой для тестировщиков. В чём же заключаются его особенности?
Todo-раздел: — отслеживает и фильтрует текущие активности; — помогает отследить и распределить нагрузку между пользователями; — отображает текущий прогресс тестирования проекта с помощью цветовой шкалы; — является лучшим способом для тестера работать над конкретными задачами; — страница Todo интегрирована со страницей запуска тестовых прогонов, чтобы тестировщик сразу мог перейти к выполнению своих задач.
Milestone Тестировщики могут создавать и работать над несколькими тестовыми прогонами одновременно. Более того, некоторые команды работают с различными версиями, итерациями, спринтами и майлстоунами в течение реализации проекта.
Пользователи могут использовать вкладку Milestone для создания отдельных этапов проекта, в которых поэтапно тестируются различные версии.
При создании нового этапа (майлстоуна) можно установить дату его начала и завершения, что помогает отслеживать сроки выполнения и порядок тестирования версий. Также можно добавить описание и пометить завершённые этапы, что поможет сконцентрироваться на активных задачах.
В этом разделе при необходимости можно создать тестовые планы и прогоны для конкретной версии, чтобы легко отслеживать прогресс в этой области. Если команда тестировщиков работает одновременно с несколькими папками, их прогресс отображается параллельно.
Test Runs & Results Здесь осуществляется управление тест-кейсами и их выполнение в основной части тестирования. TestRail старается как можно сильнее упростить процесс ввода результатов и отслеживания прогресса тестирования.
Тестировщик может создать прогон чек-листа, благодаря кнопке «Add Test Run». В начале ему потребуется указать имя для теста и по необходимости дополнительные данные: — Milestone: чтобы связать тестовый прогон с нужным этапом тестирования; — AssignTo: в этом параметре назначается ответственный за осуществление прогона; — Description: подробное описание тестового прогона; — All test cases include (select cases): по умолчанию все хранящиеся в проекте тест-кейсы включаются в тестовый прогон, но пользователь может вручную выбрать из общего списка необходимые для проверки кейсы.
Test Run можно редактировать и после его создания, изменять майлстоун или добавлять дополнительные кейсы.
После создания тестового прогона можно перейти к его непосредственному выполнению. Нужно будет на странице тест-рана указать статус отдельного тест-кейса, его исполнителя (проверяющего тестировщика) и следить за текущими результатами, статистикой и статусами кейсов.
Для проверки кейса и добавления результата его необходимо открыть, ознакомиться с предложенными условиями и, после проведения теста, проставить статус. Также тестировщик может добавить собственный комментарий, указать время, потраченное на проверку, и выявленные баги. Поскольку TestRail может подключаться к Jira, Bugzilla и Firebug в пункте результата под названием “Defects” можно указать идентификатор конкретного бага, заведённого в данных сервисах.
Test Suites and Cases Данная вкладка является неотъемлемой частью TestRail, здесь создаются и хранятся все тест-кейсы и чек-листы тестируемого приложения, которые необходимо проверять. В проекте может содержаться более тысячи тест-кейсов для различных версий, которые группируются в подразделы для удобного использования. Как правило, это позволяет разбить тестирование проекта на различные группы с определёнными типами заданий. Например, одни отвечают за проверку механики или серверной части проекта, другие за проверку интерфейса, локализации и т. д.
Для того чтобы добавить новый раздел, необходимо нажать на кнопку Add Subsection, и после создания перейти на его страницу, где уже создать необходимые тест-кейсы с помощью «Add Case».
Во время создания тест-кейса по необходимости заполняются следующие поля: — Title: название кейса; — Section: раздел, к которому будет относиться задание; — Type : определяет тип тестирования: смоук, функциональное, юзабилити, регрессия и т. д.; — Priority: установка приоритета тест-кейса; — Template: установка шаблона (exploratory session, steps, text); — Estimate: оценка задачи; — Milestone: выбирается этап, к которому относятся задания; — Reference: сюда указывается ссылка на таск из Jira или другого сервиса; — Description: подробное описание задачи; — Precondition: предварительные условия, которые необходимо осуществить перед выполнением задачи; — Steps: шаги, которые необходимо осуществить для проверки кейса и выявления багов; — Expected Result: ожидаемый результат, описывающий как должно работать приложение без дефектов.
Сервис позволяет изменять или добавлять новые поля, настраивая функционал максимально практично для каждого проекта. Кейс может содержать не только текстовую информацию, но и графическую (картинки).
Также можно создавать таблички внутри кейса, ещё больше расширяя его возможности:
Готовые кейсы можно переносить между разделами, копировать, экспортировать в XML, Excel/CSV или импортировать из XML или CSV-файла в TestRail.
Report Отчёты по тестированию важны, как и сами задания. Функционал сервиса позволяет генерировать отчётности, отправлять их по почте, а также использовать для их создания готовые шаблоны.
Результат о проделанной работе состоит из фактической информации о проведённом тестировании. TestRail позволяет максимально детализировать отчёт, указав в нём статусы кейсов и выявленные ошибки.
Заключение
TestRail — один из самых важных инструментов для управления тестированием программного обеспечения, который помогает в управлении всеми необходимыми процессами. Он включает в себя: создание проекта, подготовку тестовых кейсов, выполнение тестовых прогонов и генерацию подробной отчётности о тестировании.
Что-то осталось непонятным? Задавайте вопросы в комментариях!