1.ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ. То есть работает ли продукт?
Это тестирование направлено на проверку функциональности продукта, соответствует ли ожидаемый результат фактическому.
Сюда входит:
➤ smoke testing - быстрая и минимальная проверка продукта, самый главный тест.
➤ sanity testing - здесь будет больше тестов, чем в smoke, более широкоокреслимое тестирование, чем smoke. Ранится уже после smoke тестирования.
➤ regression testing - все ли будет работать также хорошо, как прежне после изменений, после добавления фичи. (запуск всех тестов сразу)
➤ acceptance testing - приемочное тестирование, проверка того, соответствует ли разрабатываемое ПО требованиям заказчика. (запуск всех тестов сразу)
➤ End2End testing - проверка на взаимодействия различных компонентов системы в ее целом.
➤ системное тестирование - проверка на работоспособность всех компонентов системы.
➤ интеграционное тестирование - проверка на взаимодействие с другими компонентами системы.
2.НЕФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ. То есть то, как продукт работает?
Это тестирование свойств, которые не относятся к функциональности системы, например:
➤ Т. Удобства пользователя (проверка насколько легко пользоваться нашим продуктом со стороны пользователя)
➤ Т. безопасности (проверка на предмет защищенности пользовательских данных, проверка на сколько просто неавторизированному пользователю пользоваться функционалом на сайте, проверка насколько просто постороннему лицу получить доступ к данным)
➤ Т. производительности Performance Testing (целью этого тестирования является определение работоспособности, стабильности)
В Т. Производительности входят след Т.:
➤ LOAD нагрузочное Т. (проверка системы, выдержит ли она нагрузку во время того, если будет на сайте сразу 1000 пользователей. ПОСТЕПЕННАЯ НАГРУЗКА)
➤ STRESS нагрузочное Т. (здесь нагрузка идет полным объёмом сразу)
Также другие виды тестирования:
➤ кросс-браузерное Т. и кроссплатформенное Т. (проверка на разных платформах ОС, например Андроид или Ios. Кросс-браузерное – проверка в разных браузерах)
➤ Т. на восстановление (проверка на надежность. Проверка системы насколько просто будет восстановить данные после ошибок или сбоев)
➤ Т. на проникновение (проверка насколько просто постороннему лицу получить доступ к данным)
3.Тестирование белого ящика, серого ящика и черного ящика
Т.черного ящика – когда тестировщик не знает программный код, только исходя внешних факторов интерфейса. Без знаний реализации проекта. Только все что есть на интерфейсе.
Т.белого ящика – когда мы знаем весь процесс реализации (можем протестировать как с внешним интерфейсом, так и с внутренним кодом)
Т.серого ящика – когда мы знаем только некоторые особенности реализации проекта
4.Альфа и Бета тестирование
Альфа тестирование – проверяется разработчиками
Бета тестирование – нанимается определенная группа пользователей, чтоб проверили функциональность проекта (без разработчика), то есть, работа со стороны пользвателя.
Уровень бизнес требований:
➤ Цель, ради которой создается продукт (для чего, какая польза, как получить прибыль).
Уровень user требований:
➤ Задачи, которые user может выполнять с помощью продукта (регаться, смотреть инфу, заказывать, покупать).
Уровень продуктных требований:
➤ Функциональное тестирование и нефункциональное тестирование (работает ли и как продукт должен работать).
Пути определения требований:
➤ В основном это определяет бизнес-аналитик, либо PM, в некоторых случаях QA.
➤ Также определиться с трекинговой системой, где все будет хранится.
Свойства к требованиям:
➤ Завершенность, непротиворечивость(соответствие картинок, таблиц), корректность, проверяемость, модифицируемость, прослеживаемость(id).
Как упростить работу с требованиями:
➤ Тест-кейсы, вопросы, схемы(use-case diagram).
➤ Исчерпывающее тестирование невозможно ...
Это значит что полное тестирование всех возможных комбинаций входных данных и путей выполнения программы практически невозможно в реальных условиях. Программы могут иметь огромное количество возможных путей выполнения, и некоторые из них могут быть недостижимыми в реальных условиях использования программы.
➤ Тестирование демонстрирует наличие дефектов ...
Благодаря тестированию можно определить наличие дефектов
➤ Заблуждение об отсутствии ошибок ...
Даже если ошибок не найдено, работа системы может работать неправильно из-за того, что она сама по себе построена неудобно для пользователей
➤ Раннее тестирование сохраняет время и деньги ...
Чем раньше обнаружен дефект, тем проще быстрее и дешевле его исправить. Сэкономит время и деньги!
➤ Принцип скопления дефектов ...
Чем больше модулей, тем больше может быть дефектов, они кучкуются.
➤ Тестирование зависит от контекста ...
Тестирование может быть разным и зависит это от работы, будь то сайт интернет магазина либо системы безопасности. Где-то риски больше, где-то меньше.
➤ Парадокс пестицида
Необходимо менять наборы тестов и методы тестирование, для того чтобы находить невыявленные ошибки, 1 способ может найти одни дефекты, но они могут остаться еще и надо тестировать их другими методами или тестами
Показывает в какой последовательности идут тесты.
➤ Компонентное UNIT-testing (юнит, пишут девы)(пример, интернет-магазин = тестирования корзины или окно оплаты)
➤ Интеграционное (тестирование двух модулей и больше, взаимодействие между ними)
➤ Системное тестирование (проверка всех модулей) API-tests
➤ Приемочное тестирование UI-tests (определение готовности продукта, проверяем работу функционала) в основном финальное тестирование перед релизом. Сюда можно отнести альфа и бета тестирования.
Пирамида указывает на то, сколько тестов будет проведено.
Пирамиду разбивают на 3 уровня:
➤ модульное тестирование (юнит, пишут девы);
займет 50-60% тестов всего модульного блока
➤ интеграционное тестирование API-тесты;
займет 30% количества проведенных тестов
➤ системное тестирования UI-тесты; (клик, сендКис)
Системное тестирования занимает больше сил и больше ресурсов. Займет 10% количества проведенных тестов
1.Классы эквивалентности
Это определённый диапазон входных данных, то есть проведение тестов с определёнными значениям. (например, с 0-13лет, не нанимаем на работу – это один класс эквивалентности, с 14-17 – частично нанимаем, с 18-55 – берем на работу, с 56-99 – не нанимаем) с 0 до 99 – позитивный класс, все что до и после значений: негативный класс.
Сюда можно отнести эквивалентное разбиение: если брать один диапазон значений, то нам не нужно тестить все значение, а стоит выбрать только среднее. Этот метод позволяет минимизировать количество тестов. Но это в принципе не обязательно, так как есть тестирование граничных значений.
Применяется в основном на полях ввода.
2.Анализ граничных значений
B ISTQB прописано то, что есть два подхода тестированию граничных значений. Если от 2 до 6 букв диапазон, 1 подход: тестируется 1,2 и 6,7. 2 подход: тестируется 1,2,3 и 5,6,7.
К примеру, диапазон от 0 до 10. Тестироваться будут: -1,0,1 и 9,10,11.
3.Попарное тестирование Pairwise Testing
Это техника тест-дизайна, которая предусматривает собой создание таких тест-кейсов, которое бы покрывало наибольшее количество комбинаций каждой пары входных данных.
Применяется в основном, когда имеем дело с фильтрами, шрифтами, их размером и т.д.
4.Тестирование состояний и переходов
Это тестирование объекта и его перехода. Например, есть пользователь, состояние – не зареган, когда он зарегается – это будет переход во второе состояние (зареган).
5.Таблица принятий решений
Это комбинация условий. Используется, когда у нас есть условие и их значение, делаем комбинацию из значений и проводим тесты.
5.Подход на основе опыта
Позволяет провести тестирования «черного ящика». Ввод выше максимальных чисел, ввод ниже минимальных чисел, ввод спецсимволов или нулевых значений, Ui - тесты.
Это чек-листы, тест-кейсы, баг-репорты, тест план, тест стратегия, отчет о тестировании.
ЧЕК-ЛИСТ
Это быстрая проверка на предмет ошибок и проблем. В основном содержит только одно действие.
Например: Только окно авторизации: поле "email", поле "password", кнопка "Войти", кнопка "Забыли пароль?".
ТЕСТ-КЕЙС
Тут будет использоваться детальный пошаговый сценарий, той или иной user-story.
Например:
1. Вход на сайт www.example.com
2. В правом верхнем углу нажать на кнопку "Войти в систему"
3. В появившемся окне: ввести логин, пароль
4. Нажать на кнопку "Войти"
Что входит в тест-кейс: ➤ Id'шка ➤ название (детальное, чтоб понять о чем речь) ➤ пред условия (на каком устройстве будет тестироваться (Android?), или какой браузер (Safari?) ➤ приоритет ➤ степы (последовательность действий) ➤ ожидаемый результат.
Виды тестовых сценарий:
Позитивный тест-кейс - используется только валидные данные, чтобы проверить, что приложение работает согласно заявленным требованиям.
Негативный тест-кейс - используется как минимум одно не валидное значение, чтобы проверить что приложение не выполняет данную функцию.
БАГ-РЕПОРТ
Это документ, который описывает ситуацию или последовательность действий, которая привела к некорректности работы тестируемого объекта, с указанием причин и ожидаемого результата.
Составляется он след способом:
➤ Заглавие (описание, например, в форме регистрации не работает кнопка "войти")
➤ Описание бага (пред условия, ожидаемый и фактический результат)
➤ Проект (название проекта, если он не один)
➤ Автор (создатель баг-репорта)
➤ Исполнитель (сотрудник, назначенный на решение этой проблемы)
➤ Прикрепленные файлы (скриншот или короткое видео дефекта)
➤ Severity (серьезность: blocker, critical, major, minor, trivial)
➤ Priority (приоритет: high, medium, low)
➤ Enviroment (окружение: ОС, браузер)
ТЕСТ ПЛАН
Это детализация отдельного конкретного продукта. Более высокоуровневый документ, служит для всех участников проекта.
Структура:
➤ Описание продукта, компании
➤ Что необходимо протестировать? (Описание объкта тестирования: система, приложение)
➤ Что будем тестировать? (Список функций и описание тестируемой системы или компонентов в отдельности (форма регистрации, форма авторизации, чат, комментарии)
➤ Как будем тестировать? (Указываем те виды тестирования, которые будем использовать)
➤ Когда будем тестировать? (Сроки выполнения тестирования)
➤ Последовательность проведение работ. (Чтение тех документации(требований), тестирование, анализ результатов тестирования, заведение баг-репортов)
➤ Критерии начала тестирования. (Готовность тестового стенда (сайт), наличие всей необходимой документации, законченность разработки тестируемого функционала)
➤ Критерии окончания тестирования. (Весь функционал работает согласно заявленным требованиям)
➤ Инструменты для тестирования + трекинговая система.
ТЕСТ СТРАТЕГИЯ
Это общий подход для тестирования. Максимально обобщенный документ, что до того, как будет происходит тестирование в компании.
Этапы тест стратегии:
➤ Описание тестируемого продукта. Что и зачем нужно тестировать?
➤ Подход к тестированию. Уровни тестирования, виды тестирования, роли и обязанности, требования к окружениям.
➤ Инструменты тестирования: инструменты, необходимые для проведения тестов (багтрекинговая система, стек автоматизации).
➤ Результаты тестирования: документация, которую необходимо создать до, во время и по окончании тестирования.
➤ Риски и способы их снижения (Risk and mitigation): все риски тестирования и план по их снижению.
➤ Инструмент отчетности: как будут отслеживаться дефекты и проблемы;
Составляет:
➤ Менеджер (чаще всего)
➤ Тестировщик (mid)
Окружение используется для того, чтобы потестить, к примеру, добавленные новые фичи, написанный свежий код и т.д.
Так называемое - окружения развертывания ПО. Чтоб не затрагивать рабочую версию продукта и провести регрессию, происходит разделение окружения.
Существуют такие разделения, как:
➤ Dev enviroment - среда разработки (базы данных, сайт и т.д.), тут развертывается свежий код.
➤ Test enviroment - тут тестируется функциональность.
➤ Stage enviroment - это предпродакшн, тут развертывается бэк системы.
➤ Prod enviroment - тут работают пользователи. Может быть открытм и закрытым.
Пример бага с выскоим Severity и низким Priority:
Например, на сайте не работает какая-то функциональность, но она редко используется, мы можем поставить высокую Severity и низкую Priority.
Пример бага с выскоим Priority и низким Severity:
Например, мы попадаем на страничку "Google" и видем, что в названии отсутствует одна буква "О" и название выглядит "Gogle", так как это достаточно популярный сайт, он резко потерял бы репутацию, поэтому тут мы поставим высокую Priority и низкую Severity.
Верификация - это процесс проверки системы на соответствие изначальным требованиям. То есть, "работает ли продукт так как нужно"?
Валидация - это процесс проверки на соответствие требованиям пользователя. То есть, "работает ли продукт, так как это нужно для пользователя"?
В эти процессы включаются: тестовая документация (тест план, тест кейс), тесты, отчеты, анализ.
Пример верификации на разных уровнях тестирования:
➤ модульное тестирование (проверка работы отдельных функций)
➤ интеграционное тестирование (проверка на взаимодействие между разными компонентами)
➤ регресионное тестирование (проверка все ли также хорошо работает после изменений/обновлений)