ФАКТОРЫ, КОТОРЫЕ СЛЕДУЕТ УЧИТЫВАТЬ ПРИ СОЗДАНИИ СВЕЖЕГО ПРОЕКТА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ/РАМКИ

В последней серии статей о платформе мы видели, как объяснять платформу автоматизации тестирования в интервью. Сегодня мы увидим факторы, которые следует учитывать при создании новой среды автоматизации тестирования.

Какие факторы следует учитывать при создании нового проекта автоматизации тестирования/фреймворка?

Честно говоря, сначала мне было трудно ответить на этот вопрос правильно.

Приведенный выше заголовок, являющийся очень известным вопросом на собеседовании по тестированию программного обеспечения, может иметь ответы, которые будут варьироваться от человека к человеку.

Основная проблема возникает, когда интервьюер, который считает некоторые конкретные факторы обязательными при разработке нового проекта/фреймворка автоматизации тестирования, может не удовлетвориться вашим представлением о «наиболее важных параметрах для разработки нового проекта/фреймворка автоматизации тестирования». Особенно, если вы пропустите цитирование, близкое к его/ее понятию.

Тогда будем считать, что этот вопрос субъективен?

Нет, это не так. Мы должны понимать, что, безусловно, есть некоторые важные факторы, которые всегда необходимо учитывать при создании нового проекта автоматизации тестирования.

Тем не менее, то, как человек взвешивает важность каждого фактора и имеет опыт создания одного проекта, добавляет небольшой оттенок различия в понимании.

С дюжиной личных интервью, находясь по обе стороны стола, я упомянули ниже исчерпывающий список вещей, которые следует учитывать при создании нового проекта/фреймворка для автоматизации тестирования.

Знайте все о тестируемом приложении

Поскольку вы будет автоматизировать тестовые случаи для конкретной системы, крайне важно, чтобы у вас было достаточно знаний об этом.

Вам важно знать ответы на следующие вопросы:

1. Стабильно ли приложение?
2. Выполняется ли достаточное количество ручных тестов на одном и том же?
3. Является ли тестируемое приложение является Web, Windows или Mobile?
4. Какие потоки данных, процессы и входные данные необходимы?

Ключевым моментом является то, что вы очень хорошо ознакомитесь с приложением, сделав заметки о требованиях и на основе этих двух одновременно думать о том, как автоматизация будет утверждать и проверять их.

Возможно, вы поняли требования и прочитали документы с описанием всего приложения, тем не менее, начав исследовательское тестирование, вы получите более полное представление о внутренних рабочих процессах системы.

Просто знать, как работает приложение, не должно быть вашей целью, вы также должны начать понимать, как все устроено внутри.

Выделенные ресурсы и целевая аудитория

Убедившись, что тестируемое приложение вас устраивает, попытайтесь получить ответы на такие вопросы, как

1. Есть ли специальная команда по автоматизации, и если да, то сколько ресурсов в нее вложено?< li>Какой будет структура команды?
2. Кто является аудиторией отчетов о тестировании?
3. Насколько велика целевая аудитория?
4. Какие отчеты о тестировании ожидаются?

Инженеру по автоматизации тестирования важно знать это с самого начала по следующим причинам:

• Если команда автоматизации будет ограничена, то, возможно, команда не столкнется с огромными трудностями при работе над повседневными задачами автоматизации. Однако если команда большая и распределенная, то при слаженной работе может возникнуть пара проблем. В таких случаях необходимо поддерживать версии фреймворка или скриптов. Это можно сделать либо в локальном репозитории, либо в инструменте управления версиями. Поскольку несколько человек будут работать над одной и той же структурой, можно легко отслеживать изменения, внесенные в программный код.
• Что касается отчета о тестировании, с учетом предпочтений целевой аудитории и технического воздействия, можно решить степень детализации отчетов, ведение журнала, возможность преобразования отчетов в другое хранилище/формат или даже отправлять их по почте отдельным лицам и т. д. На основе этого с самого начала можно разработать структуру тестирования.

Бюджетная стоимость и выбор правильных инструментов

Бюджетные ограничения являются одним из наиболее важных моментов, которые следует учитывать. Это связано с тем, что это будет напрямую связано с выбором инструментов автоматизации, поскольку стоимость будет включать лицензионные продукты, оплату обновленной версии, настройку тестовой среды (в случае необходимости внешнего программного и аппаратного обеспечения), а также обслуживание инструментов.

Следовательно, всегда рекомендуется иметь четкое представление о бюджете проекта и на его основе выбирать инструменты.

Реалистичные ожидания или тест Область автоматизации

Крайне важно, прежде чем приступить к разработке среды автоматизации тестирования, вы, а также руководство и команда проекта должны определиться с ожиданиями от среды автоматизации.

Разумно начать с сохраняя реалистичные ожидания и заранее определяя объем тестирования.

Ниже приведены некоторые указания, которые группа тестирования должна обсудить и согласовать.

• Невозможно достичь 100% автоматических тестов.
• Автоматизировать каждый а каждый тест – недостижимая цель.
• Преимущества автоматизации тестирования можно пожинать только после нескольких циклов выполнения теста,
• и ожидать немедленной окупаемости инвестиций — это миф
• На выбор инструмента и создание инфраструктуры должно быть выделено отдельное время для запуска.

< h3>Дизайн

Определение дизайна типа Framework — еще одна ключевая задача. В основном это определяется типом ввода тестовых данных в тестовые сценарии.

Ниже приведены некоторые из наиболее часто используемых сред автоматизации тестирования,

• Data-Driven Automation Framework
• Платформа автоматизации на основе ключевых слов
• Модульная платформа автоматизации
• Гибридная платформа автоматизации
• Структура линейных сценариев
• Среда разработки на основе поведения
• Хорошо организованная платформа
• Параметры конфигурации
• Управление версиями платформы
• Расширяемость и Обслуживание

Подробнее о типах платформ автоматизации тестирования

Передовой опыт написания тестовых сценариев

Наконец, переходим к самому базовому, но наиболее важному моменту: тестовым сценариям и задачам обработки данных.

Настоятельно рекомендуется, чтобы обработка тестовых сценариев, тестовых данных, библиотек и других служебных файлов делается отдельно, и код в основном предпочтительно писать в объектно-ориентированной манере. Это позволяет повторно использовать код наряду с другими преимуществами, получаемыми от концепций ООП.

Некоторые из широко используемых стандартов сценариев:

• Создание репозитория объектов: (пример: локаторы веб-элементов, хранящиеся в файле OR.properties)
• Для разработки общей библиотеки функций: (пример: хранить все общие операции в одном файле)
• Для написания тестов с использованием интегрированного инструмента управления тестами: (пример TestNG)
• Для параметризации теста: (пример: для сохранить отдельный файл источника данных)
• Чтобы сохранить сгенерированный файл и скриншоты
• Чтобы создать отчет о тестировании
• Интеграция среды автоматизации тестирования с инструментами CI/CD: (пример: возможность интеграции с такими инструментами, как Jenkins или TeamCity)

Я надеюсь, что это поможет вам всем. Бонус: чем лучше вы понимаете концепции, тем лучше вы объясните свои ответы.

Биография автора:

старший инженер по тестированию программного обеспечения в государственном учреждении, базирующемся в Сингапуре. Автор, Сайни Банерджи Пал, имеет обширный опыт работы в индустрии программного обеспечения более 6 лет в таких областях, как SAP, электроника, телекоммуникации, AFC, электронная коммерция, и пишет для нескольких ведущих веб-сайтов. Вы часто можете найти ее заметки, чтение статей, страстное объяснение концепций другим или на https://medium.com/@sainy.banerjee09.

Здесь я выбрал несколько постов, которые помогут чтобы узнать больше о собеседованиях:

• Где вы применяли OOPS в Automation Framework
• Data Driven Framework в Selenium WebDriver
• Объектная модель страницы с Page Factory в Selenium
• Учебное пособие по Selenium
• Учебное пособие по ручному тестированию
• Учебное пособие по SQL для тестировщиков программного обеспечения
• Учебное пособие по тестированию производительности
• Учебное пособие по тестированию безопасности
• Учебное пособие по тестированию API
• Учебное пособие по Postman

TAG: qa

Еще об этом:

150+ ЛУЧШИХ ВОПРОСОВ И ОТВЕТОВ НА ИНТЕРВЬЮ О ТЕСТИРОВАНИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ЛУЧШИЕ ИНСТРУМЕНТЫ ТЕСТИРОВАНИЯ ВЕБ-ПРИЛОЖЕНИЙ (БЕСПЛАТНЫЕ И ПЛАТНЫЕ) НА 2022 ГОД ЛУЧШИЕ ИНСТРУМЕНТЫ ТЕСТИРОВАНИЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ В 2024 ГОДУ ДЛЯ ANDROID И IOS ЛУЧШИЕ ИНСТРУМЕНТЫ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ (БЕСПЛАТНЫЕ И ПЛАТНЫЕ) | август 2022 г. 100 САМЫХ ПОПУЛЯРНЫХ ПРОДВИНУТЫХ ВОПРОСОВ И ОТВЕТОВ НА ИНТЕРВЬЮ ПО SELENIUM ЛУЧШИЕ ИНСТРУМЕНТЫ УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ (БЕСПЛАТНЫЕ И ПЛАТНЫЕ) НА 2022 ГОД 100+ ВИДОВ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ – ПОЛНЫЙ СПИСОК УСЛОВИЯ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, КОТОРЫЕ ДОЛЖНЫ ЗНАТЬ ВСЕ НОВЫЕ ТЕСТЕРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ЛУЧШЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ УПРАВЛЕНИЯ МАРКЕТИНГОВЫМИ ПРОЕКТАМИ В 2022 ГОДУ ЛУЧШИЕ АЛЬТЕРНАТИВЫ СЕЛЕНА (БЕСПЛАТНЫЕ И ПЛАТНЫЕ) В 2022 ГОДУ