🗊Презентация Классификации видов тестирования

Классификации видов тестирования По доступу к коду (по знанию системы) По степени изолированности компонентов По степени автоматизации По степени подготовленности к тестированию По признаку +/- сценариев (по требованиям) По запуску кода По объекту тестирования

Smoke тестирование - это минимальный набор написанных тест-кейсов, определяющий, что билд готов к передаче в тестирование. Цель для команды тестирования – не нахождение дефектов, а убедиться, что вся функциональность работает стабильно и готова к тестированию. Занимает от 15 минут до 2х часов. Если не работают элементарные вещи, то билд отдают на доработку. Можно использовать средства автоматизации. Smoke тестирование - это минимальный набор написанных тест-кейсов, определяющий, что билд готов к передаче в тестирование. Цель для команды тестирования – не нахождение дефектов, а убедиться, что вся функциональность работает стабильно и готова к тестированию. Занимает от 15 минут до 2х часов. Если не работают элементарные вещи, то билд отдают на доработку. Можно использовать средства автоматизации.

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

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

Тестирование производительности – тестирование  поведение системы при различных нагрузках и при различных сценариях использования. Тестирование производительности – тестирование  поведение системы при различных нагрузках и при различных сценариях использования. Основные виды тестирования производительности: Stress testing Load testing Stability testing Volume testing

Стрессовое тестирование (Stress testing) – проверка системы при пиковых нагрузках, ограниченных ресурсах и восстановление после  возвращению к нормальному состоянию. Стрессовое тестирование (Stress testing) – проверка системы при пиковых нагрузках, ограниченных ресурсах и восстановление после  возвращению к нормальному состоянию. Нагрузочное тестирование (Load testing) - проверка систем на различных уровнях нагрузки. Определяем, при какой максимальной нагрузке (максимальном количестве пользователей) система способна функционировать в соответствии с требованиями к производительности.

Тестирование стабильности (Stability testing) - оценка работоспособности системы при длительной нагрузке. Главная задача - выявить утечки памяти или другие проблемы, которые не позволяют системе стабильно работать. Тестирование стабильности (Stability testing) - оценка работоспособности системы при длительной нагрузке. Главная задача - выявить утечки памяти или другие проблемы, которые не позволяют системе стабильно работать. Объемное тестирование (Volume testing) - тестирование проводится с увеличением не нагрузки и времени работы, а количества используемых данных, которые хранятся и используются в приложении.

При тестировании производительности нас интересует: При тестировании производительности нас интересует: изменение времени выполнения операций в зависимости от интенсивности операций (где интенсивность операций = кол-во пользователей * кол-во операций * единицу времени). определение границы приемлемой производительности (где приемлемая производительность - это либо четко прописанное в ТЗ среднее время отклика системы, либо такая скорость работы, когда уже с приложением нормально работать невозможно). определение количества пользователей, которые могут одновременно работать с приложением.

Тестирование интерфейса пользователя (UI testing) - тестирование графического интерфейса пользователя для того, чтобы убедиться, что он соответствует принятым стандартам и их требованиям. Тестирование интерфейса пользователя (UI testing) - тестирование графического интерфейса пользователя для того, чтобы убедиться, что он соответствует принятым стандартам и их требованиям. Тестирование удобства использования (Usability testing) - тестирование, определяющее, насколько продукт отвечает требованиям той аудитории, для которой он пишется.

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

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

2.3 Методологии разработки ПО Модель жизненного цикла программного обеспечения - структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта. Водопад или каскадная модель Водоворот или каскадная с промежуточным контролем V модель - разработка через тестирование Спиральная модель Итеративная модель Cемейство Agile: Scrum, XP, Kanban

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

"Водоворот" или каскадная модель с промежуточным контролем - в этой модели предусмотрен промежуточный контроль за счет обратных связей. "Водоворот" или каскадная модель с промежуточным контролем - в этой модели предусмотрен промежуточный контроль за счет обратных связей.

V модель - разработка через тестирование которая предполагает регулярное тестирование продукта во время разработки. V модель - разработка через тестирование которая предполагает регулярное тестирование продукта во время разработки.

Особенности V модели: Особенности V модели: • детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять • приемо-сдаточные испытания основываются, прежде всего, на требованиях, системное тестирование — на требованиях и архитектуре, комплексное тестирование — на требованиях, архитектуре и интерфейсах, а компонентное тестирование — на требованиях, архитектуре, интерфейсах и алгоритмах

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

Agile – семейство гибких методологий разработки. Agile – семейство гибких методологий разработки.

Scrum - одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности - простота. Scrum - одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности - простота.

Скрам Мастер (СМ) - отвечает за успех Scrum в проекте. По сути, СМ является интерфейсом (посредником) между менеджментом и командой. В Agile команда самоорганизующаяся и самоуправляемая. Скрам Мастер (СМ) - отвечает за успех Scrum в проекте. По сути, СМ является интерфейсом (посредником) между менеджментом и командой. В Agile команда самоорганизующаяся и самоуправляемая.

Product Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Единая точка принятия окончательных решений для команды в проекте. Product Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Единая точка принятия окончательных решений для команды в проекте.

Обязанности команды (7 +/- 2): Обязанности команды (7 +/- 2): Отвечают за оценку элементов бэклога Принимают решение по дизайну и имплементации Разрабатывают софт и предоставляют его заказчику Отслеживают собственный прогресс Отвечают за результат перед Product Owner

Особенности Scrum Особенности Scrum - Sprint Backlog - содержит функциональность, выбранную Product Owner на итерацию из Product Backlog. В Scrum итерация называется Sprint длительностью 2-4 недели. Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику). В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Планирование спринта происходит в начале новой итерации, где выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда. При этом никто не может менять список задач утвержденный на Sprint.

Особенности Scrum Особенности Scrum Retrospective meeting - проводится после завершения спринта. Члены команды высказывают своё мнение о прошедшем спринте. Отвечают на два основных вопроса: – Что было сделано хорошо в прошедшем спринте? – Что надо улучшить в следующем? В процессе митинга решают вопросы и фиксируют удачные решения. Совещание ограничено одним-тремя часами.

Особенности Scrum Особенности Scrum Planning Poker / Scrum poker — техника оценки, используемая для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения.