15.12M
Category: softwaresoftware

Кто такой тестировщик?

1.

Кто такой
тестировщик?
Инженер по тестированию (QA-engineer) —
это специалист, который создаёт сценарии
тестирования, прогнозирует сбои и находит
ошибки в продуктах.
AB
by Anna Bril

2.

Тестирование — это поиск
несоответствий
Тестирование — это поиск несоответствий между фактическим
и ожидаемым результатом. Если заказчик хочет видеть
определённые иконки на странице это будет ожидаемый
результат. А уже как это будет реализовано в нашем продукте —
это результат фактический.
Ожидаемый результат
Иконки на странице должны быть определённого
цвета и размера.
Фактический результат
Иконки на странице могут быть другого цвета или
размера.

3.

Задачи и обязанности
тестировщика
Тестировщик проверяет, что приложение работает так, как
ожидается по документации. Если это не так, он фиксирует
ошибку и передаёт её на исправление в отдел разработки.
1
Проверка документации
Тестировщик изучает документацию и уточняет
спорные моменты в ней.
2
Разработка тестов
Тестировщик готовит набор тестов для проверки
функциональности продукта.
3
Проверка продукта
Тестировщик проходит по разработанным тестам и
фиксирует результат.

4.

Жизненный цикл разработки ПО (SDLC)
Жизненный цикл программного обеспечения (software lifecycle): Период времени, начинающийся с
момента появления концепции программного обеспечения и заканчивающийся тогда, когда
дальнейшее использование программного обеспечения невозможно.
1
Сбор и анализ требований
На этом этапе от клиентов собирается вся необходимая информация для разработки
продукта в соответствии с их ожиданиями.
2
Дизайн
На этом этапе требования, собранные в документе SRS, используются в качестве
входных данных, и создается архитектура программного обеспечения.
3
Разработка
Реализация / кодирование начинается, как только разработчик получает Design
document. Дизайн программного обеспечения переведен в исходный код.
4
Тестирование
На этом этапе разработанное программное обеспечение тщательно тестируется, и все
обнаруженные дефекты передаются разработчикам для их исправления.
5
Развертывание
После тестирования продукта он развертывается в производственной среде или
выполняется первое UAT (пользовательское приемочное тестирование).
6
Поддержка
Основное внимание на этом этапе SDLC уделяется обеспечению того, чтобы потребности
продолжали удовлетворяться и чтобы система продолжала работать в соответствии со
спецификацией.

5.

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

6.

Тестирование, контроль качества и обеспечение качества.
Тестирование ПО — проверка соответствия между реальным и ожидаемым
поведением программы.
Контроль качества (QC) - набор действий, предназначенных для оценивания
качества компонента или системы.
Обеспечение качества (QA) - активности, направленные на обеспечение
уверенности в том, что требования к качеству будут выполнены.
Давайте разберемся на примере создания мобильного приложения,
потому что определения не всегда отражают суть:
1. В рамках тестирования мы выполним проверки и
задокументируем дефекты, убедимся, что продукт
соответствует требованиям.
2. В рамках контроля качества мы проанализируем полученные
данные и убедимся, что соблюдены все требования,
предъявляемые к качеству как продукта, так и самого
процесса. Мы должны убедиться, что уровень качества
нашего продукта высокий и он готов к релизу.
3. В рамках обеспечения качества мы формируем процесс QA
для соответствия стандартам качества на всех этапах SDLC,
еще до этапа создания нашего продукта, который будет
минимизировать количество дефектов и предупреждать их.

7.

Верификация и валидация
Верификация - подтверждение соответствия продукта требованиям.
Валидация - подтверждение соответствия продукта ожиданиям пользователя.
Верификация
Валидация
Проверяет соответствие продукта
требованиям.
Проверяет соответствие продукта
ожиданиям пользователя.
Отвечает на вопрос: правильно ли мы
разрабатываем продукт?
Отвечает на вопрос: правильный ли
продукт мы разработали?

8.

Верификация
Верификация включает в себя статические методы
проверки, такие как анализ требований, дизайна и
кода.
1
Анализ требований
Проверяет полноту и непротиворечивость требований.
2
Анализ дизайна
Проверяет соответствие дизайна требованиям.
3
Анализ кода
Проверяет соответствие кода дизайну.

9.

Валидация
Валидация включает в себя динамические
проверки, такие как тестирование рабочего
продукта.
1
Тестирование
Проверяет соответствие продукта ожиданиям пользователя.
2
Пользовательское тестирование
Проверяет удобство использования продукта.
3
Приемочное тестирование
Проверяет соответствие продукта требованиям заказчика.

10.

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

11.

Пирамида тестирования
Основной принцип разделения уровней - тест должен быть на том же уровне, что и тестируемый объект.
Unit/component/program/
module testing
Тестирование минимально-атомарного
модуля программы.
1
2
Integration testing
Тестирование нескольких модулей
System testing
3
программы вместе.
Тестирование всей программы полностью.
4
Acceptance testing
Приемка программы заказчиком.

12.

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

13.

Интеграционное тестирование
Интеграционное тестирование фокусируется на взаимодействии между компонентами или система
1
2
3
4
5
Подход Большого взрыва
Все модули собираются вместе и тестируются.
Инкрементальный подход
Тестирование выполняется путем объединения модулей поэтапно.
Нисходящий подход
Тестирование начинается с высокоуровневых модулей.
Восходящий подход
Тестирование начинается с низкоуровневых модулей.
Гибридный подход
Комбинация восходящего и нисходящего подходов.

14.

Системное тестирование
Системное тестирование означает тестирование всей системы в
целом, и выполняется после интеграционного тестирования, чтобы
проверить, работает ли вся система целиком должным образом
Зачем нужно системное тестирование?
Системное тестирование выполняется в среде, аналогичной production environment,
и, следовательно, заинтересованные стороны могут получить хорошее представление
о реакции пользователя;
Это помогает свести к минимуму устранение неполадок после развертывания
и количество обращений в службу поддержки;
На этом этапе STLC тестируются архитектура приложения и бизнес-требования.

15.

End-to-end
тестирование
End-to-end тестирование проверяет программное обеспечение
от начала до конца.
Преимущества
Позволяет проверить все
сценарии использования.
Недостатки
Может быть трудоемким и
затратным.

16.

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

17.

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

18.

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

19.

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

20.

Дымовое тестирование
Дымовое тестирование - это проверка самой важной функциональности
приложения, без которой приложение не имеет смысла.
Авторизация
Поиск товара
Оплата
Проверка возможности
Проверка возможности
Проверка возможности
пользователя авторизоваться в
пользователя найти нужный
пользователя оплатить товар.
системе.
товар.

21.

Подтверждающее
тестирование (ретест)
Ретест проводится после исправления дефекта, чтобы убедиться,
что ошибка больше не воспроизводится. Он не требует оценки
влияния изменений на другие части приложения.
Цель
Подтвердить, что дефект был исправлен.
Когда проводится
После исправления дефекта.

22.

Регрессионное тестирование
Регрессионное тестирование проводится после любого
изменения в коде, чтобы убедиться, что изменения не повлияли
на уже существующие функции.
1
Цель
Проверить стабильность приложения после изменений.
2
Когда проводится
После любого изменения в коде.
3
Частота
Перед каждым релизом.

23.

Особенности регрессионного
тестирования
Регрессионное тестирование - одна из самых важных
задач тестировщика. Оно проводится перед каждым
релизом, чтобы гарантировать стабильность
приложения.
1
Частота
Проводится перед каждым релизом.
2
Автоматизация
Часто автоматизируется для экономии времени.
3
Длительность
Обычно занимает несколько дней.
4
Заморозка кода
Внесение изменений в код запрещено, кроме исправлений критических дефектов.

24.

Функциональное и
Нефункциональное
тестирование
Функциональное тестирование оценивает функции,
которые должна выполнять система. Оно может
проводиться на всех уровнях разработки.
Функциональное тестирование отвечает на вопрос:
"Что делает система?"
Нефункциональное тестирование оценивает
характеристики системы, такие как удобство
использования, производительность или безопасность.
Нефункциональное тестирование отвечает на вопрос:
"Как система это делает?".

25.

Классификация по степени
автоматизации
1
Ручное тестирование
Тест-кейсы выполняются вручную без использования
средств автоматизации.
2
Автоматизированное тестирование
Используются техники и инструменты для
автоматизации задач тестирования.

26.

Классификация по
запуску кода
1
Статическое тестирование
Тестирование без запуска кода. Проверка документации,
кода, тестовых данных.
2
Динамическое тестирование
Тестирование во время выполнения кода. Проверка
реального поведения приложения.

27.

Инсталляционное тестирование
Включает в себя следующие процессы:
•Установка ПО
•Удаление ПО
•Обновление ПО
•Откат на предыдущую версию
•Повторный запуск установки после возникновения ошибки
или исправления уже возникших проблем
•Автоматическая установка
•Установка отдельного компонента из общего пакета программ

28.

Тестирование удобства использования
Понятность
Обучаемость
Операбельность
Привлекательность
Проверка того, насколько
Проверка того, насколько
Проверка того, насколько
Проверка того, насколько
понятно пользователю, как
легко пользователю
удобно пользователю
пользователю нравится
работать с продуктом.
научиться работать с
работать с продуктом.
использовать продукт.
продуктом.

29.

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

30.

Тестирование безопасности
1
SQL-инъекции
Проверка защиты от SQL-инъекций.
2
XSS-инъекции
Проверка защиты от XSS-инъекций.
3
Перехват трафика
Проверка защиты от перехвата трафика.
4
Брутфорсинг
Проверка защиты от полного перебора данных для получения
доступа.

31.

Тестирование надежности
Тестирование надежности - это проверка способности
приложения выполнять свои функции в заданных условиях
на протяжении заданного времени или заданного
количества операций.
1
Проверка работоспособности
Проверяется способность приложения выполнять свои функции в
заданных условиях.
2
Проверка времени
Проверяется способность приложения работать на протяжении заданного
времени.
3
Проверка количества операций
Проверяется способность приложения выполнять заданное количество
операций.

32.

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

33.

Тестирование отказоустойчивости
Тестирование отказоустойчивости - это тестирование,
заключающееся в эмуляции или реальном создании критических
ситуаций с целью проверки способности приложения
задействовать соответствующие механизмы, предотвращающие
нарушение работоспособности, производительности и
повреждения данных.
1
Эмуляция
Проверяется реакция приложения на эмуляцию критических ситуаций.
2
Реальное создание
Проверяется реакция приложения на реальные критические ситуации.
3
Предотвращение нарушений
Проверяется способность приложения предотвращать нарушения
работоспособности, производительности и повреждения данных.

34.

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

35.

Нагрузочное тестирование
Нагрузочное тестирование - это исследование способности приложения сохранять заданные
показатели качества при нагрузке в допустимых пределах и некотором превышении этих
пределов (определение «запаса прочности»).
Проверка качества
Нагрузка
Превышение пределов
Проверяется способность
приложения сохранять
заданные показатели
качества.
Проверяется реакция
приложения на нагрузку в
допустимых пределах.
Проверяется реакция
приложения на превышение
допустимых пределов
нагрузки.

36.

Анализ
требований
Анализ требований - это процесс сбора,
анализа, документирования и проверки
требований к системе, которые должны быть
удовлетворены для достижения целей проекта.
Свойства качественных требований:
Завершенность
Модифицируемость
Атомарность
Прослеживаемость
Недвусмысленность
Непротиворечивость
Обязательность
Выполнимость
Проранжированность
Корректность

37.

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

38.

Уровни и типы требований
Требования к программному обеспечению можно классифицировать по уровням
и типам. Давайте рассмотрим основные категории требований, которые
встречаются в процессе разработки.
Пользовательские
Функциональные
Нефункциональные
требования
требования
требования
Бизнес-требования
Пользовательские
Функциональные
выражают цель, ради
требования описывают
требования описывают
которой
задачи, которые
поведение системы, т.е.
разрабатывается
пользователь может
ее действия:
продукт. Они отвечают
выполнять с помощью
вычисления,
на вопросы: зачем
разрабатываемой
преобразования,
вообще он нужен, какая
системы. Они
проверки, обработку и
от него ожидается
описывают реакцию
т.д.
польза, как заказчик с
системы на действия
его помощью будет
пользователя и
получать прибыль.
сценарии работы
Бизнес-требования
Они определяют
качество, надежность,
безопасность и другие
характеристики
системы.

39.

Неявные требования
Не всегда требования будут описаны на проекте в виде спецификации
или пользовательской истории. В таком случае необходимо изучать
неявные требования из других источников.
Законы, регламенты, инструкции
Некоторые требования могут быть вытекать из законодательных
актов, отраслевых стандартов или внутренних правил компании.
Список задач, существующие тесты и баг-репорты
Анализ существующих задач, тестов и баг-репортов может дать
представление о проблемах, которые необходимо решить в новой
системе.
Руководство пользователя
Руководство пользователя может содержать информацию о том, как
пользователи должны взаимодействовать с системой, что может быть
полезно для выявления неявных требований.
Интервью с командой и заказчиками
Беседы с разработчиками, менеджерами и заказчиками могут выявить
неявные требования, которые не были задокументированы.

40.

Важность качественных требований
Качественные требования - это основа успешного проекта. Они обеспечивают четкое
понимание целей проекта, помогают избежать ошибок в разработке и гарантируют,
что конечный продукт будет соответствовать ожиданиям заказчика.
1
Снижение рисков
Четкие и корректные требования снижают риск возникновения ошибок и
недоразумений в процессе разработки.
2
Улучшение коммуникации
Качественные требования способствуют улучшению коммуникации между
разработчиками, заказчиком и пользователями системы.
3
Повышение качества продукта
Хорошо сформулированные требования гарантируют, что конечный продукт
будет соответствовать ожиданиям заказчика и пользователей.
4
Ускорение разработки
Четкое понимание требований позволяет разработчикам быстрее и
эффективнее создавать программное обеспечение.
English     Русский Rules