Как проводить тестирование программы

Стратегия тестирования (или тестовая стратегия) — высокоуровневый документ, описывающий техники тестирования, используемые в STLC-цикле, и подтверждает виды и уровни тестирования в данном проекте.

Стратегия тестирования в сущности неизменяемый документ, после того как создана, согласована и утверждена проджект-менеджером.

Тестовая стратегия содержит ответы на следующие вопросы:

• Какие техники тестирования будут применяться?
• Какие модули будут протестированы?
• Какие критерии входа и выхода?
• Какая область тестирования?

То есть это «стратегический» высокоуровневый документ, объясняющий и направляющий процессы тестирования, учитывающий также следующие вопросы:

• Степень автоматизации процессов
• Какие человеческие и другие ресурсы будут задействованы

Стратегия создается на основе документация по дизайну проекта:

• Документация дизайна системы в целом — главным образом используется она.
• Второстепенная документация по дизайну приложения — как вспомогательная и для будущих версий.
• Документация на концептуальном уровне — редко используется.

Из чего состоит тестовая стратегия

Описания области тестирования (test scope), распределения сил и средств, тестовых окружений, инструментов тестирования, используемые для проверки и утверждения набора функций, описаны в стратегии тестирования, и многое другое. Также включаются графики занятости сотрудников, прикрепленные задачи и подобные рабочие моменты, чтобы QA-команда была максимально структурированной и эффективной.

Тестирование Программного Обеспечения — урок №1 — Введение

Стратегия тестирования не представляет собой «расширенную версию плана тестирования» — тест-план является документом нижнего уровня; в то время как Стратегия это «общий, целеполагающий» документ. Оба документа являются важными артефактами в QA, направленными на расширение тестового покрытия и повышение качества продукта.

Составляющие тестовой стратегии:

1. Обзор и область тестирования
2. Применяемые методологии
3. Спецификации тестовых окружений
4. Инструменты тестирования
5. Данные, относящиеся к релизу
6. Анализ рисков
7. Данные о проверке и утверждении

1. Саммари (общий обзор) и описание сферы тестирования

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

• Обзор («Summary») проекта с указанием ответственных лиц.
• Также указание причастных к оценке, согласованию и утверждению Стратегии.
• Расписание этапов и тестовых активностях на этих этапах, с рабочими графиками, и также сроки этапов.

2. Методология

Методология тестирования — следующая секция Стратегии. Подробное описание уровней тестирования, активностей, ролей и прикрепленных обязанностей членов QA-команды и других причастных.

Информатика. 8 класс. Тестирование программы /06.05.2021/

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

Итак, в этой секции указывается следующее:

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

3. Описание тестовых окружений

Следующая секция Стратегии тестирования. Тестовое окружение и тестовые данные — важные вещи в QA. Поэтому описание тестового окружения (иначе говоря, среды тестирования) в этом документе включает в себя указания по созданию тестовых данных и манипуляциям с ними. В частности, количество тестовых окружений и их параметры. Также может описываться резервное копирование и восстановление окружений. Итак, секция содержит следующее:

• Информация о количестве окружений и их конфигурациях.
• Отдельно окружения по предназначению (например, функциональное тестирование может иметь одни тестовые окружения, для приемочного другие).
• Количество пользователей в каждом окружении и уровни доступа, а также программные и аппаратные характеристики окружений (ОС, память, место на диске).
• Объем тестовых данных.
• Способ получения тестовых данных (при помощи генераторов, или данные реальных пользователей из проекта, с маскированием информации).
• Порядок резервного копирования и восстановления тестовых данных.
• Какие базы данных используются.
• Указывается, кто и когда должен делать резервные копии, что должно быть включено, порядок восстановления, и контроль доступа при восстановлении.

4. Инструменты тестирования

Важная секция, содержащая данные об инструментах автоматизации тестирования, управления им, и обслуживания тестовых процессов. Инструменты тестирования безопасности и производительности; платные или open-source.

• Во первых, инструменты управления тестированием (инструменты тест-менеджмента)
• Инструменты автоматизации, которые будут использованы для подготовки и выполнения тестов.
• Подходы к тестированию производительности и безопасности и применяемые в этой сфере инструменты
• Указание платности/бесплатности инструментов, количества пользователей, которое инструмент поддерживает.

5. Управление релизами

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

• Версии продукта для тестового/приемочного окружения, возникающие в результате незапланированных релизов.
• Контроль тестирования изменений в таких релизах; управление версиями.
• Управление билдами; где и когда будет доступен новый билд; где он будет развернут; продакшен-билд; кто контролирует релизы (например дает «go-signal» к запуску релиза) и так далее.

6. Анализ рисков

В следующей секции по возможности кратко описываются все потенциальные риски в проекте, могущие вызвать проблемы в процессе тестирования. Также описываются способы устранения/смягчения этих рисков. Нужно также иметь «План Б» на случай непредвиденных ситуаций (не предусмотренных обычным анализом рисков).

Итак, составляется список всех потенциальных опасностей и план контроля этих рисков, а также «план отхода» — резервный план, если проект столкнется с большими рисками.

7. Данные о согласовании и утверждении

Согласование и утверждение, последняя секция Стратегии. После подготовки Стратегии она проверяется, согласовывается, и утверждается причастными менеджерами:

• Менеджмент ИТ-компании.
• Команда управления проектом.
• Команда разработчиков.
• Бизнес-команда.

Указывается дата утверждения, ФИО утвердителей, их комментарии, и краткое описание утвержденных изменений, если таковые случатся; в процессе тестирования в Стратегию могут вноситься обновления и корректировки.

Чем тестовая стратегия отличается от тест-плана

Тест-план Тестовая стратегия

Создается на основе требований к продукту (SRS)	Создается на основе бизнес-требований (BRS)
Готовит QA-лид или другой ответственный менеджер	Готовит проджект-менеджер или бизнес-аналитик
ID тест-плана, тестируемые функции, применяемые техники тестирования, задачи в процессе, критерии приемки, тестовые артефакты, тестировщики прикрепленные к функциям и расписание их задач, и подобные низкоуровневые вещи	Цели, области и масштаб тестирования, применяемые методики, процессы, структура команды, форматы документации, подходы к коммуникации с клиентами и подобные высокоуровневые вещи
План пишется после принятия требований к продукту и на их основе	Стратегия является первичным документом и создается в начале работы над продуктом
Тест-план должен быть простым документом	Стратегия служит общим целеуказателем в проекте

Типы тестовых стратегий

Далее приведены типы стратегий «под задачу»:

К примеру, тестирование на основе рисков и тестирование на основе требований — два отдельных типа тестирования, нужны разные подходы. После изучения условий тестирования, таких как риски и требования, QA-команда уточняет обстоятельства тестирования. В случае тестирования на основе требований для определения обстоятельств изучаются требования. Затем создаются и выполняются тесты, направленные на проверку выполнения требований. В аналитической стратегии отслеживаются результаты проверки требований, и те, которые были проверены и прошли, и те, которые не прошли, и те, которые не были полностью протестированы.

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

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

В этом случае строго соблюдается некий формализованный стандарт качества (например, стандарт ISO25000); применяют чеклисты и/или другие формальные подходы. В некоторых видах тестирования (например, безопасности) и типах приложений (например мобильные) существуют общепринятые/стандартизированные чеклисты проверок. Например, для maintenance-тестирования обслуживания чаще всего достаточно чеклиста, описывающего соответствующие функции, их свойства и т.д.

1. Стратегия, ориентированная на стандарты или процессы

Например, при тестировании медицинских ИТ-систем, которые обязаны соответствовать регуляторным стандартам государства. ИТ-компания в некоторых случаях должна соблюдать методы и/или рекомендации, установленные комитетами по стандартам/группами специалистов, и иногда это касается условий тестирования,тест-кейсов, и даже состава QA-команды.

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

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

Например следующая ситуация: проводится исследовательское тестирование работающего продукта; тест-кейсы создаются по уже имплементированным функциям; по результатам этих тестов происходит обновление тестов и подходов. Нередко по реактивной стратегии действуют в Agile-разработке.

Как и в примере выше с Agile, может быть подход к тестовой стратегии, основанный на фидбеке от пользователей и стейкхолдеров. Например, имеем сценарий тестирования кроссбраузерной совместимости веб-приложения. Владелец продукта предоставляет список браузеров и их версий; также может указать нужные операционные системы и другие требования.

1. Стратегия антирегрессионного тестирования

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

Например, если веб-приложение необходимо протестировать на регрессию, QA-команда может автоматизировать как позитивные, так и негативные use-кейсы, и выполнять тесты всякий раз при обновлении приложения.

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

Выбор нужной стратегии

Влияют следующие факторы:

• Нужная Стратегия тестирования зависит от особенностей продукта.
• А также от требований, например, приложения, ориентированные на безопасность, требуют более строгих подходов.
• Выбор стратегии тестирования также зависит от модели разработки продукта.
• «Большие продукты» требуют долгосрочной стратегии
• Тип и размер компании.

Похожие записи:

1. 20 практических советов по тестированию ПО
2. Полное руководство по тестированию баз данных
3. Как проводить тестирование Backend
4. Анализ тестирования

Источник: qarocks.ru

Автоматизация тестирования: что можно, а что не нужно

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

Главным элементом непрерывного тестирования является его автоматизация, что даёт множество преимуществ:

• Быстрое получение обратной связи
• Аккуратное и тщательное тестирование
• Высокое покрытие тестами
• Быстрое обнаружение ошибок
• Повторное использование тестов
• Более короткие сроки поставки
• Адаптация для DevOps
• Экономия времени и денег

Несмотря на перечисленные выше преимущества, начальные вложения в автоматизацию тестирования могут быть очень высоки. Приобретение ПО, затраты на обучение работе с ним, проектирование и создание автоматизированных тестов — всё это требует немалых времени и денег. Однако, как только вы начинаете всё активнее разрабатывать новые функции в своём продукте, ручное тестирование в конечном итоге выходит дороже, а автоматическое — дешевле.

На нашем курсе DevOps: современный подход к организации работы ИТ мы подробно разбираем, как приземлить методологию DevOps на реальные ланшафты организаций. При этом у вас есть возможность обсудить с тренером барьеры, существующие в вашей практике и мешающие полноценно получать выгоду от использования DevOps.

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

Какие тесты можно автоматизировать

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

Модульное тестирование

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

Приоритетные функции

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

Регрессионные и интеграционные тесты

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

Нагрузочные тесты и тесты производительности

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

Повторяющиеся тестовые сценарии

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

Базовая функциональность (дымовые тесты)

В отличие от других тестов, дымовые тесты не такие сложные и относительно легко реализуемые. При этом прохождение этих тестов имеет решающее значение. Они информируют команды разработки о том, правильно ли работают базовые функции приложения, например: открывается ли окно входа в приложение, могут ли пользователи войти в систему, доступен ли API, доступно ли приложение из разных мест и т.п.

Какие тесты не нужно автоматизировать

Всё больше и больше узнавая о преимуществах автоматизации тестирования и глубоко проникаясь ими, можно задаться закономерным вопросом — а почему бы не автоматизировать вообще все тесты? Ответ в виде «не нужно пытаться автоматизировать всё» идёт вразрез с DevOps-мышлением, в котором явная установка на автоматизацию всего и вся. Перед планированием автоматизации тестирования нужно учесть несколько факторов. Вот примеры тестов и сценариев, для которых не нужна автоматизация.

Пользовательский опыт (UX)

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

Стадии ранней разработки

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

Функциональность, не имеющая большой важности

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

Тесты без понятных результатов

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

Тесты, которые невозможно полностью автоматизировать

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

Фреймворки автоматизированного тестирования

В каждой команде разработки и поставки ПО группа QA отвечает за разработку, внедрение и выполнение тестов. Для каждого типа тестирования должен быть определён тестовый сценарий, принципы, правила и инструменты для проведения. Фреймворк тестирования — это набор этих руководств, инструментов и практик, который помогает инженерам-тестировщикам эффективно выполнять тестовые сценарии.

Существуют разные фреймворки для разных целей тестирования. Вот некоторые из самых популярных типов фреймворков для автоматизированного тестирования:

• Модульный: приложение разделено на отдельные модули, и каждый модуль тестируется в изолированном состоянии
• Линейный: составление и исполнение тестовых скриптов. Тестировщики пишут тестовые сценарии последовательно, выполняя их затем для каждого отдельного тест-кейса
• Библиотечная архитектура: создан на основе модульного фреймворка тестирования, с той лишь разницей, что содержит функции для многократного использования
• Управляемое данными тестирование: тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или базе данных (SQL, ODBC-ресурсы, csv или xls файлы)
• Тестирование по ключевым словам: в данном фреймворке не обязательно иметь навыки программирования, поскольку ключевые слова, используемые при создании тестов, отделены от технического кода. Тестировщику достаточно иметь представление о всём наборе действий, реализованных во фреймворке
• Гибридный: комбинация из различных фреймворков.

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

Автоматизация — ключ к тому, чтобы разрабатываемое ПО могло быстро пройти через все стадии конвейера разработки и предоставить клиентам свои функции. Однако, это не означает, что команды должны вкладывать всё свое время и ресурсы в автоматизацию тестирования. Команды должны понимать, что можно и нужно автоматизировать, а что не стóит. Правильный выбор охвата тестов на ранних этапах разработки имеет большое значение.

На нашем курсе DevOps: современный подход к организации работы ИТ мы подробно разбираем, как приземлить методологию DevOps на реальные ланшафты организаций. При этом у вас есть возможность обсудить с тренером барьеры, существующие в вашей практике и мешающие полноценно получать выгоду от использования DevOps.

Также по теме:

• Медленное движение «влево» в автоматизации тестирования
• Организация и совершенствование команд разработчиков: Матрица тестирования
• Сдвиг тестирования вправо. Возникновение TestOps
• Выбор правильных метрик тестирования программного обеспечения
• Как нужно и можно проводить аудит ИТ

Источник: cleverics.ru

Как тестировать программное обеспечение

Серия статей про тестирование программного обеспечения. Часть 4: как тестировать программное обеспечение.

Содержание

1. Как тестировать программное обеспечение
2. Как тестировщик тестирует программное обеспечение
3. План тестирования (тест-план)
4. Техники тестирования
5. Инструменты тестировщика
6. Баг
7. Критерии остановки тестирования программного обеспечения
8. Как тестировать

Как тестировать программное обеспечение

Многие начинающие и не только начинающие тестировщики задаются вопросом “А как тестировать программное обеспечение”, каким образом тестировать сайт или программу, как тестировать требования, как тестировать прототипы к программе или веб-сервису… В этой главе рассмотрим разные аспекты того, как тестировать программное обеспечение.

Как тестировщик тестирует программное обеспечение

Тестировщик (специалист по тестированию, QA-инженер) каждый день сталкивается с тестированием программного обеспечения, для него этот вопрос имеет необычайную важность. Одни тестировщики тестируют, полагаясь на интуицию, другие тестировщики проверяют абсолютно всё в программном обеспечении, но есть тестировщики, которые знают, как тестировать программное обеспечение, соблюдая баланс скорости и качества. Такие тестировщики умеют концентрироваться на главных сценариях и второстепенных, они обладают не только базовыми знаниями теории тестирования, но и знают и умеют использовать специальные техники тестирования, о которых поговорим чуть ниже.

В общем и целом, процесс тестирования программного обеспечения можно представить в следующем виде: начинается этап тестирования задачи, тестировщик составляет план-тестирования, пишет чек-листы по каждому направлению в задаче, расписывает каждый пункт чек-листа, после описания нужных сценариев, расстановки приоритетов наступает непосредственно этап тестирования, на котором тестировщик проверяет сгенерированные сценарии. В процессе тестирования тестировщик отмечает по каждому пункту — пройден сценарий успешно или есть проблема.

Если есть проблемы, они выписываются отдельно, задача возвращается разработчику, разработчик исправляет все проблемы и переводит задачу снова на тестировщика. После этого задача тестировщика перепроверить поправленные пункты и продолжить тестирование с учетом новой информации. После окончания тестирования пишется отчет о тестировании (тест-репорт), в котором тестировщик описывает кратко список проверок согласно тест-плану, что было проверено и какие результаты тестирования. Если всё хорошо, задача уходит в релиз (выпуск на боевую, production).

План тестирования (тест-план)

План тестирования (сокращенно: тест-план) — это документ, который состоит из нескольких разделов, если кратко, это могут быть разделы про стратегию тестирования, про то, какие техники тестирования будут использоваться, про сроки тестирования, про то, что будет тестироваться, как будет тестироваться, какие будут использоваться инструменты тестирования и какие могут быть риски и ограничения при тестировании.

Хороший пример тест-плана (плана тестирования) можно посмотреть в статье Тест план для тестирования пример. Рассмотрим, какие бывают техники тестирования.

Техники тестирования

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

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

Список техник тест-дизайна и тест-анализа:

• Классы эквивалентности.
• Граничные значения.
• Причина следствие.
• Предугадывание ошибок.
• Исчерпывающее тестирование.
• Тестовые туры.
• Техника попарного тестирования.
• Техники тестирования требований.
• И, на самом деле, на этом список не заканчивается, эта тема огромна, будем стараться расширять список техник тестирования на этой странице.

Если Вы знаете другие техники тестирования, которых нет в этом списке, напишите комментарий в этой статье, либо присылайте в обратную связь. Сделаем список техник тестирования вместе!

Классы эквивалентности

Техника тестирования “Классы эквивалентности”. Другие названия техники: анализ классов эквивалентности, разбиение на классы эквивалентности, техника анализа классов эквивалентности, отношение эквивалентности, equivalence class, выделение классов эквивалентности, таблица классов эквивалентности, тест дизайн классы эквивалентности. Классы эквивалентности — это техника в тестировании программного обеспечения, суть которой заключается в том, что выборку тестовых данных можно разбить на классы, что тесты в одном классе будут эквивалентны друг другу. Если в одном классе 100 тестов, достаточно проверить один, и тогда мы сэкономим много времени, не проверяя все остальные 99 тестов, т.к. тесты в одном классе эквивалентны друг другу.

Про технику классов эквивалентности читайте в статье Классы эквивалентности примеры.

Граничные значения

Техника тестирования “Граничные значения”. Другие названия техники: анализ граничных значений, метод граничных значений, техника граничных значений, метод анализа граничных значений, тест дизайн граничные значений, boundary value analysis, границы классов эквивалентности.

Техника граничных значений — это продолжение техники классов эквивалентности, только базируется эта техника на том, чтобы провести анализ граничных значений классов эквивалентности. Пусть у нас есть несколько классов эквивалентности, нужно найти границы этих классов. Для простоты возьмем два класса эквивалентности.

Можно рассмотреть отдельно первый класс эквивалентности, и отдельно рассмотреть второй класс эквивалентности. Для первого класса будут две границы — то, что до класса эквивалентности, и то, что после него. Для второго класса аналогично — будут две границы — то, что до класса эквивалентности и то, что после класса эквивалентности.

Заметим, что классы идут подряд, поэтому можно выделить общую границу для двух классов эквивалентности, поэтому для двух классов эквивалентности будет всего три границы. Когда выделили границы классов эквивалентности, можно выделить граничные значения. Для этого фиксируем значение границы, до границы и после границы, получаем три значения для каждой границы. Итого 9 значений для всех трех границ классов эквивалентности. В этом и есть суть техники анализа граничных значений: выделяем классы эквивалентности, выделяем границы классов эквивалентности и выделяем граничные значения, остается только зафиксировать эти граничные значения в виде тестов и провести тестирование, выполнить проверки по этим тестам.

Инструменты тестировщика

Существует множество инструментов, которые помогают тестировщику быстрее и эффективнее проводить тестирование. Рассмотрим несколько инструментов тестирования (инструментов тестировщика).

Карты тестирования

Карта тестирования (чек-лист, check list, mindmap, мэпка, карта, список проверок) — это карта с проверками, то, что тестировщик проверяет при тестировании. Карта может быть в виде дерева, может быть в виде списка, и даже в виде таблицы. Формат карты тестирования (мэпки) определяется удобством использования, а также договоренностями в команде тестировщиков, в котором виде лучше всего хранить те или иные карты тестирования.

Инструменты веб тестирования

Веб-тестировщик имеет в своем арсенале множество инструментов. Часть инструментов UI-тестирования (веб-тестирования) можно посмотреть на сайте https://radar4site.ru в разделе Инструменты тестировщика: генератор идей тестирования (для новых идей по тестированию), генератор ИНН/КПП (чтобы при тестировании форм в программах и сайтах не ломать голову над тем, откуда взять правильные ИНН и КПП), определитель возраста сайта, определитель ИКС сайта, определитель числа символов в тексте (бывает полезным при вставке больших текстов в формы), а также недавно появившиеся инструменты тестирования — проверка слов на ошибки и проверка ударения в слове (эти сервисы еще пока в стадии доработки). Немаловажным инструментом тестировщика является возможность быстро и удобно делать скриншоты (снимок экрана, картинка экрана, рабочего стола) и видео. Для этого существуют специальные утилиты и программы, так называемые скриншотилки.

Инструменты процесса разработки

Может быть полезно владение инструментами процесса разработки: GIT (система контроля версий, чтобы иметь возможность быстро посмотреть, какие были изменения исходном коде программного обеспечения), SQL (язык запросов, для выполнения запросов в базу данных и добычи нужных данных), IDE (среда разработки, в которой пишется код программного обеспечения, чтобы общаться с разработчиками на одном языке и быстро доносить обратную связь по возможным проблемам программного обеспечения).

Баг

Что такое баг

В процессе тестирования программного обеспечения зачастую неизбежно возникают ситуации, когда тестировщик видит какое-то несоответствие того, что реализовано в программном обеспечении (сайте, программе, приложении) и тем, что описано в документации, либо с тем, что не согласуется с представлениями тестировщика. Когда возникает такое расхождение — это называют багом (от английского — bug, ошибка, проблема, дефект). У бага есть даже свой жизненный цикл, давайте рассмотрим его подробнее.

Жизненный цикл бага

Тестировщик нашел баг, что с ним будет происходить дальше? Рассмотрим жизненный цикл багов (бага). Данный жизненный цикл — это примерный жизненный цикл бага, он может отличаться в зависимости от команды тестирования, команды разработки, договоренностей в компаниях и т.д.

Жизненный цикл бага (статусы багов):

Новый — новым баг становится, когда только был обнаружен тестировщиком и зафиксирован в виде баг-репорта. Зафиксировать можно по-разному: в баг-трекинговой системе, в личном сообщении разработчику или команде и даже в устной форме (но так никто обычно не делает).

Исправлен (пофиксен, fixed bug) — это когда разработчик взял баг в работу и успешно его починил, исправил, пофиксил и отправил тестировщику на проверку.

Закрыт (closed bug) — это когда тестировщик проверил поправленный баг, что он действительно поправлен и не привел к другим проблемам и багам, и зафиксировал, что баг закрыт и больше не воспроизводится.

Это основные статусы жизненного цикла бага, но могут быть и другие, например: баг открыт (opened bug), баг отложен (deferred bug), баг отклонен (rejected bug), дубликат бага (duplicate bug, такой баг уже есть), баг назначен, баг проверен (verified bug), баг переоткрыт (открыт повторно, reopened bug).

Приоритеты багов

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

High — баг с высоким приоритетом, самый высокий приоритет бага, его нужно брать в первую очередь в работу.

Medium — баг со средним приоритетом, его нужно брать, если нет багов с высоким приоритетом.

Low — баг с низким приоритетом, это баг, который может подождать, если нет багов с более высокими приоритетами.

Серьезность багов

Серьезность багов — это характеристика, отражающая, насколько серьезен той или иной баг (дефект, проблема, ошибка) в программном обеспечении.

Blocker — блокирующий баг, когда программное обеспечение или часть программного обеспечения совсем не работает.

Critical — критичный баг, не работает основная часть функциональности программного обеспечения.

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

Minor — минорный баг, небольшая проблема, с которой можно жить дальше, небольшая неприятность.

Trivial — совсем мелкий баг, опечатка, какая-то неточность в программном обеспечении.

Критерии остановки тестирования программного обеспечения

В процессе тестирования может возникнуть вопрос “А когда можно остановиться тестировать? Какие есть критерии остановки тестирования программного обеспечения? Или можно тестировать бесконечно?” В процессе разработки программного обеспечения есть задачи, у задач есть примерные сроки на их реализацию и тестирование. Поэтому первым критерием остановки тестирования назовем время.

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

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

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

Как тестировать

Как тестировать программное обеспечение? Вооружившись знаниями прошлых глав, воодушевившись техниками тест-дизайна и тест-анализа можно начинать тестировать свой первый сайт, первую программу или первое приложение. Не важно, что тестировать, главное — начать. И остановиться будет уже невозможно.

Как тестировать сайты

О том, как тестировать сайты есть отдельная статья Как протестировать сайт пошаговое руководство, опишем вкратце, как выглядит процесс тестирования сайта: тестировщик получает задание — протестировать сайт, интернет-магазин, лендинг, либо часть функциональности сайта. Тестировщик пишет план тестирования, составляет чек-листы, карты тестирования по тестированию сайта. Затем тестировщик проходит пункты чек-листов, дописывает новые проверки и тесты в чек-листах и картах тестирования, описывает баг-репорты и в после финального этапа тестирования пишет отчет о проведенном тестировании сайта. Если очень кратко, то так выглядит процесс того, как тестировщики тестируют сайты.

Как тестировать программное обеспечение

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

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

Когда цели и задачи ясны, можно перейти к написанию плана тестирования. Открываем калькулятор и записываем все идеи, которые приходят в голову. Можно отталкиваться от основных сценариев, например, посчитать 2 + 2 и увидеть, что программа выводит корректный результат.

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

Для удобства можно открыть программу для составления интеллектуальных карт и составить мэпку (карту тестирования), в которой обозначить основные ветки и ответвления от основных веток, где ветки — это направления функций калькулятора, а подветки — это конкретизация каждого направления, каждой функций. Работая над картой тестирования можно составить множество сценариев, тестов, каждый из которых нужно протестировать.

В процессе проверки возле каждого пункта можно поставить либо зеленую галочку, либо красную. Зеленая будет означать, что тест пройден успешно. А красная — то, что есть проблема, найден баг (ошибка) в программном обеспечении, в данном случае, в программе калькулятор. Мы описали вкратце процесс того, как тестировать программное обеспечение.

Как тестировать мобильные приложения

Как тестировать мобильное приложение? Допустим, у нас есть мобильный телефон, на нем установлено новое приложение, которое только отправил Вам разработчик. Как протестировать мобильное приложение? Процесс тестирование мобильных приложений несколько отличается от тестирования программного обеспечения.

Во-первых, у мобильного телефона есть множество специфичных настроек, таких как, сотовая связь, наличие сим-карты, возможность подзарядки и т.д. Во-вторых, мобильное устройство имеет небольшие габариты, небольшой экран, на нем помещается не так много информации, из-за этого в мобильном телефоне есть специфичные элементы и технологии, которых нет на стационарном компьютере, на desktop-устройстве, такие как: компонентных мобильных операционных систем, сенсорный контакт (пролистывание — свайпы) и т.д.

Процесс тестирования мобильного приложения может выглядеть следующим образом: на телефон скачивается мобильное приложение, тестировщик открывает его, выделяет основные функции (основные сценарии) приложения, проверяет основные сценарии, дальше смотрит неосновные сценарии (негативные сценарии), и после этого пишет отчет о тестировании и отчет о найденных ошибках (багах). Если рассматривать объект — приложение, его, как правило, тестируют на разных мобильных операционных системах (Android, iOS), на разных устройствах, обычно на самых последних версиях.

Источник: radar4site.ru