16 Техник Тест Дизайна С Примерами. Продвинутый Курс Тестирование ПО. Занятие 8.

Введение

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

Юбилейная лекция

• Преподаватель объясняет, что число 8 является юбилейным.

• Он упоминает о связи числа 8 с двойкой в третьей степени и количеством бит в одном байте.

• Преподаватель также говорит о значении числа 8 в контексте команды "team 8".

Значение техник тест-дизайна

• Преподаватель подчеркивает, что все разработчики должны знать и использовать техники тест-дизайна.

• Он объясняет, что это позволяет разработчикам провести предварительное тестирование перед передачей функционала на проверку специалисту по тестированию.

План работы над test design

• Преподаватель представляет план работы над test design.

• Первый шаг - анализ документации и требований.

• Затем оценка рисков и дальнейшее составление тест-кейсов.

Определение test design

• Преподаватель предлагает простое определение test design - это создание тест-кейсов.

• Он подчеркивает, что запомнить это определение легко, так как оно логично.

Техники тест-дизайна

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

Роль техник тест-дизайна

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

• Он отмечает, что это очень важно для работы на собеседованиях и в повседневной практике.

План работы над test design (продолжение)

• Преподаватель продолжает рассказывать о плане работы над test design.

• Следующий шаг - анализ документации и требований.

• Он упоминает, что более подробно расскажет о техниках составления тест-кейсов на следующей лекции.

Определение test design (пр

Уточнение требований

Обзор раздела: В этом разделе рассматривается процесс уточнения требований перед созданием проекта.

Задание вопросов и непонимание требований

• Мы задаем вопросы, когда что-то непонятно в требованиях продюсера, project-менеджера или бизнес аналитика.

• Этот этап является очень важным и позволяет уточнить требования перед началом работы.

Роль менеджера, клиента и бизнес-аналитика

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

Значимость задавания вопросов

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

• Некоторые "глупые" вопросы могут помочь нам лучше понять требования и привести к новым открытиям.

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

Обзор раздела: В этом разделе рассматриваются техники тестирования и их важность.

Тест-дизайн

• Техники тест-дизайна помогают нам не забыть о покрытии определенного функционала при создании тестов.

• Целью тест-дизайна является максимальное покрытие функционала системы.

Приоритеты для тест-кейсов

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

• Приоритеты зависят от различных факторов, таких как сроки, бизнес-приоритеты и цели тестирования.

Количество и формализация проверок

Обзор раздела: В этом разделе рассматривается количество и формализация проверок при тестировании.

Количество проверок

• Необходимо определить минимально достаточное количество проверок для каждой системы.

• Написание слишком большого количества тест кейсов может быть неэффективным и затратным процессом.

Формализация проверок

• Формализация проверок позволяет передавать задокументированные и структурированные тест-кейсы другим членам команды.

• Это особенно полезно, когда новый человек присоедин

Преподавание и опыт преподавателя

Обзор раздела: В этом разделе говорится о жесткости тем, которые преподаются, а также о важности опыта и подачи материала преподавателя.

Простота и максимальность подачи материала

• Преподаватель старается преподать сложные темы максимально просто.

• Опыт и статьи преподавателя вызывают восхищение у слушателей.

Недостаток информации об опыте

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

Полезные ресурсы для проверки квалификации

• Существуют сертификации для тестировщиков, которые помогают подтвердить квалификацию.

• Рекомендуется обратить внимание на сертификат от международной организации по тестированию.

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

Обзор раздела: В этом разделе рассказывается о значимости техник тестирования дизайна и примере сертифицированного тестировщика.

Сертификация и обучение

• Преподаватель является сертифицированным тестировщиком с опытом работы.

• Знание английского языка также важно для тестировщика.

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

• Исчерпывающее тестирование - протестировать все возможные варианты входных и выходных значений.

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

Поздравление с получением оффера

Обзор раздела: В этом разделе поздравляют Михаила с получением оффера на работу и обсуждаются планы на будущее.

Получение оффера

• Михаил получил оффер на работу в хорошую компанию в Польше с перспективой релокации.

• Он будет заниматься автоматизацией тестирования с использованием Postman.

Учебный процесс

• Миха

Разделение на эквиваленты

Обзор раздела: В этом разделе рассматривается пример с зарплатами для объяснения концепции разделения на эквиваленты.

Эквивалентное разделение

• Можно использовать пример с зарплатами для демонстрации эквивалентного разделения.

• В математике используются отрезки и интервалы для представления числовых значений.

• Примерно определяются уровни зарплат в тестировании: junior, middle и senior.

• С помощью эквивалентного разделения можно создать тест кейсы для каждого интервала.

Анализ граничных значений

Обзор раздела: В этом разделе рассматривается техника анализа граничных значений и ее применение.

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

• Для анализа граничных значений используется пример с весом боксеров на олимпийских играх.

• Различные весовые категории имеют свои границы, например, 48, 51, 56 кг и т.д.

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

Преимущества эквивалентного разделения и анализа граничных значений

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

Преимущества

• Используя технику эквивалентного разделения, можно сократить количество тест кейсов.

• Анализ граничных значений позволяет проверить поведение программы на крайних значениях.

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

Заключение

Обзор раздела: В этом разделе делается заключение по использованию техник эквивалентного разделения и анализа граничных значений.

Заключение

• Техника эквивалентного разделения позволяет сократить количество тест кейсов при проверке программы.

• Анализ граничных значений помогает выявить ошибки в программе на крайних значениях.

• Объединение этих двух подходов может улучшить процесс тестирования и повысить его эффективность.

50 999 следующие

Обзор раздела: В этом разделе рассматривается интервал значений от 50 до 999.

Интервал значений от 50 до 999

• Значения в интервале от 50 до 999 обозначаются как следующие числа.

• Этот интервал является наилегчайшим весом и используется для анализа граничных значений.

51 да да то есть вот это у нас получается наилегчайший вес интервал до здесь 51 51 по такой же логике здесь 5555 999 идея понятна до

Обзор раздела: В этом разделе объясняется, что значения от 51 до 5555 также являются частью наилегчайшего весового интервала.

Интервал значений от 51 до 5555

• Значения в интервале от 51 до 5555 также считаются наилегчайшими.

• Это продолжение идеи предыдущего интервала (от 50 до 999).

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

Обзор раздела: В этом разделе объясняется процесс анализа граничных значений для интервалов.

Анализ граничных значений

• Для анализа граничных значений мы берем значение на единицу до начала интервала и значение на единицу меньше конца интервала.

• Например, если у нас есть интервал от 48 до 55, то мы возьмем значение 47 (единица до начала) и значение 54 (единица меньше конца).

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

Обзор раздела: В этом разделе объясняется, что для каждой точки или значения существует два соседних значения - одно на 1 меньше и одно на 1 больше.

Два значения для каждой точки

• Для каждой точки или значения у нас есть два соседних значения: одно на 1 меньше и одно на 1 больше.

Создание продуктов и тестирование

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

Создание продуктов

• Можно создавать свои внутренние продукты и покупать их.

• Использование инструментов, таких как Bubble, для управления балансом.

• Примеры использования Postman для перехвата запросов и работы с backend.

Техника тест-дизайна

• Роль хорошего тестировщика заключается в определении причин и следствий.

• Применение причинно-следственной логики при нажатии кнопок или выполнении действий.

• Предугадывание возможных ошибок при вводе данных, например, неправильный формат e-mail.

• Использование предугадывания ошибок для улучшения качества продукта.

Техника причинно-следственного анализа

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

• Применение техники причинно-следственного анализа для определения связей между действиями и результатами.

• Пример использования: нажатие на категорию тестов должно открывать страницу с соответствующими тестами.

• Использование логического мышления для предугадывания возможных последствий действий.

Предугадывание ошибок

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

• Предугадывание возможных ошибок при вводе данных, например, неправильный формат e-mail.

• Использование предварительного анализа для определения всех возможных вариантов ошибок.

• Улучшение качества продукта путем изучения и понимания потенциальных ошибок.

Предугадывание ошибок при регистрации

Обзор раздела: В этом разделе рассм

Ошибки и техники тестирования

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

Ошибки при начале работы

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

• Термин "ломать" не является точным описанием работы тестировщика. Он скорее проверяет наличие багов и улучшает качество системы.

• При начале тестирования следует сначала проверить позитивные случаи использования системы, например, регистрацию пользователя и успешный вход в систему.

• Начинающие тестировщики часто зацикливаются на локальных проблемах и не обращают внимание на функциональность системы в целом.

Подход к тестированию

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

• При планировании тестирования следует учитывать различные платформы и языки, на которых будет использоваться система.

• Тестирование должно проводиться на разных операционных системах, таких как Windows, Linux и Mac.

Заключение

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

• Позитивное тестирование составляет примерно 95% всех случаев тестирования.

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

Почему не 27, а чуть-чуть меньше?

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

Причины уменьшения количества тест-кейсов

• Вопрос о причинах уменьшения количества тест-кейсов.

• Различные комбинации языков и операционных систем для тестирования.

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

• Использование онлайн-инструмента Pierre Weiss для генерации тест-кейсов.

Генерация и использование техники Pairwise Testing

Обзор раздела: В этом разделе рассказывается о генерации и использовании метода Pairwise Testing для сокращения количества тест-кейсов.

Процесс генерации и использования Pairwise Testing

• Генерация парных комбинаций с помощью инструмента.

• Применение техники Pairwise Testing для сокращения количества тест-кейсов.

• Пример использования Pairwise Testing с различными языками и операционными системами.

Ограничения и осторожность при использовании методов сокращения тест-кейсов

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

Ограничения и предостережения

• Необходимость хорошего знания системы перед применением методов.

• Ситуативность и контекстуальность применения методов.

• Примеры случаев, когда методы могут не дать достаточно полного покрытия тестирования.

Повышение и форма

Обзор раздела: В этом разделе говорится о повышении и создании формы.

Создание формы

• Для начала, предлагается создать форму.

• Форма должна содержать поля для ввода имени, электронной почты, страны и кнопку "Сохранить".

• Предполагается, что песня будет отображаться на этой странице.

• Обсуждаются возможные поля для формы, такие как пол и страна.

Валидация полей

• Обсуждаются входные значения для каждого из полей.

• Упоминается валидность или невалидность значений в полях.

• Рассматривается проверка валидности электронной почты.

• Упоминается случай с ошибкой при передаче невалидного параметра функции.

Количество тестовых кейсов

• Рассчитывается количество возможных комбинаций для тестирования формы.

• Упоминается необходимость определения позитивных и негативных тестовых кейсов.

• Обсуждается использование техники 1 с, чтобы сгенерировать тестовые кейсы.

Таблица принятия решений

• Вводится понятие таблицы принятия решений.

• Примером использования таблицы является определение наркомана или не наркомана.

• Упоминаются различные признаки, по которым можно определить наркомана.

Определение наркомана

• Обсуждаются признаки наркомана, такие как походка и глаза.

• Уточняется, что будет приниматься решение о том, является ли человек наркоманом или нет.

Имена участников

• Предлагается использовать имена Артем, Искандер, Алексей и Ларента для примеров.

Заключение

• Обсуждается решение о том, как определить наркомана среди уч

Определение правил для принятия решений

Обзор раздела: В этом разделе обсуждается процесс определения правил для принятия решений на основе требований менеджера, клиента и документации.

Определение параметров и критериев

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

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

• Имя человека может быть использовано в качестве одного из критериев.

Таблица принятия решений

• Можно создать таблицу принятия решений без использования имени.

• Примеры таблиц принятия решений можно найти в банковской сфере.

• Таблица содержит множество критериев, таких как работоспособность, доходы, задолженности и т.д.

Граф состояний переходов

• Граф состояний переходов - это математическая техника, используемая для принятия решений.

• Граф состояний переходов может иметь различные названия, но принцип остается тот же.

• Значения в графе состояний переходов могут быть истинными или ложными.

Ожидаемый результат

• Ожидаемый результат - это то, что должно произойти после выполнения определенных действий.

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

Примеры из реальной практики

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

Заключение

• Правила для принятия решений могут быть определены на основе требований и критериев.

• Граф состояни

Очередь за зарплатой и тестирование системы

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

Проверка системы и состояния

• В день зарплаты стоит очередь за получением зарплаты в офисе.

• Обсуждение названия метода или техники для тестирования системы.

• Разговор о возможных названиях и поиск информации в статьях.

• Уточнение первого состояния системы - "тишина".

• Обсуждение следующего состояния - "покой".

• Разговор о переходе, когда пользователь вставляет карту.

• Уточнение следующего состояния - "карта вставлена".

• Обсуждение перехода, когда пользователь вводит пин-код.

• Уточнение состояния - "введенный пин-код".

• Обсуждение возможных переходов и состояний при вводе пин-кода.

• Уточнение двух состояний после неправильного пин-кода.

• Обсуждение верного и неверного пин-кода и следующего состояния.

• Упоминание о "бабках" как следующем состоянии системы.

• Разговор о долларах нарисованных на банкомате и отдаче карты.

• Уточнение случая, когда нет денег на счету пользователя.

Состояния и переходы

• Обсуждение ввода пин-кода еще раз при неверном вводе.

• Разговор о сложностях при разрастании системы с множеством состояний и переходов.

• Упоминание блок-схемы как аналогичной концепции для представления состояний и переходов.

Применение графа состояний

• Упоминание использования графа состояний для обнаружения нестыковок и проблем в системе.

• Обсуждение возможности

Путь от начала графа в конец

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

Критические пути

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

• Составление критического пути основано на состояниях и переходах между ними.

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

Тестирование состояний и переходов

• Для тестирования состояний и переходов можно использовать условные тесты.

• Например, при условии, что карта уже вставлена, пользователь вводит пин-код и нажимает кнопку для получения денег.

• Ожидаемый результат - успешный ввод пин-кода и выдача денег.

Различные сценарии тестирования

• Можно провести несколько тестовых сценариев для проверки различных случаев.

• Например, один сценарий проверяет верный пин-код, а другой - неверный пин-код.

• Можно также проверить ситуацию, когда неверный пин-код вводится три раза.

Граф состояний и переходов

• Граф состояний и переходов помогает визуализировать все возможные состояния и переходы системы.

• Это полезный инструмент для разработчиков и тестировщиков при работе с сложными системами.

• Разработчики могут использовать граф состояний и переходов для более точного понимания поведения системы.

Тестирование и документация

• Тестирование основывается на пользовательских сценариях (user story) и требованиях.

• User story - это описание функциональности или поведения системы из точки зрения пользователя.

• Тест кейсы являются более детальным описанием конкретных шагов и ожидаемых результатов.

Значение дискейса в тестировании

Обзор раздела: В этом разделе рассматривается значение дискейса (use case) в тестировании.

Дискейс как требование

• Дискейс представляет собой требование, которое создается заказчиками, менеджерами или бизнес-аналитиками для разработчиков.

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

Различия между дискейсом и тест кейсом

• Дискейс является более высокоуровневым описанием, в то время как тест кейс - это более детальное описание конкретных шагов и ожидаемых результатов.

• Дискейсы помогают разработчикам и тестировщикам понять общую картину поведения системы.

Пример использования

Исследовательское тестирование

Обзор раздела: В этом разделе рассматривается исследовательское тестирование, его подход и примеры использования.

Исследовательское тестирование

• Михаил предлагает не пропускать бонусы.

• Обещан видеоурок через две недели.

• Редактирование становится сложнее по мере продвижения проекта.

• Исследовательское тестирование - подход, при котором изучение, дизайн и тестирование выполняются одновременно.

• Традиционный подход к тестированию включает составление тест-кейсов и чек-листов перед началом тестирования.

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

• Исследовательское тестирование основано на опыте и знаниях тестировщика.

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

• Исследовательское тестирование позволяет обнаружить такие нюансы и проблемы заранее.

• Техники тест-дизайна могут быть авторскими и основываться на опыте тестировщика.

• Пример с использованием ролей в фриланс платформе для актеров, где техника тест-дизайна помогла представить различные сценарии использования системы.

• Техника тест-дизайна позволяет размышлять о функциональности системы из разных ролей и представлять ее взаимодействие с пользователями.

Бонусы и видеоурок

Обзор раздела: В этом разделе обсуждаются бонусы и обещанный видеоурок.

Бонусы и видеоурок

• [](t=5983s

Ромбики и блок-схемы

Обзор раздела: В этом разделе рассматривается использование ромбиков в блок-схемах для задания вопросов и принятия решений.

Ромбики в блок-схемах

• Ромбики обозначают вопросы или условия в блок-схеме.

• Общепринятый формат движения по блок-схеме - направо или вниз, отсутствует движение по сторонам.

Пример использования ромбиков

• Пример: блок-схема для процесса восстановления пароля.

• Входные данные (восстановление пароля).

• Проверка электронной почты на корректность формата.

• Если формат некорректный, показать ошибку.

• Если формат корректный, перейти к следующему шагу.

• Проверка наличия электронной почты в базе данных.

• Если адрес отсутствует, показать ошибку.

• Если адрес есть, отправить письмо с новым паролем и уведомить пользователя.

Тестирование методами "обезьянки" и "ад хок"

Обзор раздела: В этом разделе рассматривается исследовательское тестирование и методы "обезьянки" и "ад хок".

Исследовательское тестирование

• Исследовательское тестирование - это одновременное изучение и составление тест-кейсов.

• Опытный тестировщик системно подходит к задаче тестирования, находит пути и создает соответствующие тест-кейсы.

Тестирование методом "обезьянки"

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

• Неопытный пользователь выполняет действия в приложении без понимания происходящего.

• Цель - проверить работоспособность приложения в случайных сценариях.

Тестирование методом "ад хок"

• Тестирование методом "ад хок" - это систематическое подход к задаче тестирования.

• Представляет собой поиск ошибок с использованием позитивных сценариев.

• Разработчикам полезно получать отчеты об ошибках от опытных тестировщиков.

Метод "monkey testing"

Обзор раздела: В этом разделе рассматривается метод "monkey testing" и его применение в тестировании Android-приложений.

Метод "monkey testing"

• "Monkey testing" - это метод, при котором приложение подвергается случайным действиям.

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

• Цель - проверить работоспособность приложения и выявить возможные ошибки или

Разговорчики с разработчиком

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

Важность общения с разработчиком

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

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

• Уточняйте, как будет обрабатываться неправильный e-mail или отсутствие друзей в контактах пользователя.

Преимущества общения с разработчиком

• Общение с разработчиками помогает выявить несостыковки или проблемы в коде еще до его написания.

• Глупые вопросы могут натолкнуть разработчика на новые мысли и помочь ему улучшить проект.

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

Аналитика и тестирование дизайна

• Используйте аналитику для отслеживания действий пользователей и составления тест-кейсов.

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

• Техника "тестирование дизайна" позволяет улучшить элементы интерфейса на основе данных об использовании пользователем.

Заключение

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

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

Обзор раздела: В этом разделе рассматривается техника тестирования дизайна, особенно если на проекте подключен модуль аналитики.

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

• Подключение модуля аналитики на проекте.

• Управляемая аналитика - использование багов и обратной связи пользователей для создания тест-кейсов.

• Создание тест-кейсов на основе обнаруженных багов.

• Добавление структурированных тестов к уже существующим, чтобы проверить функционал, который не работает.

• Использование различных методик и подходов при составлении тест-кейсов и проведении стресс-тестирования.

• Рекомендации по применению различных методик в зависимости от ситуации и требований проекта.

Книжные методики и таблицы принятия решений

Обзор раздела: В этом разделе обсуждаются книжные методики тестирования и использование таблиц принятия решений.

Книжные методики и таблицы принятия решений

• Использование блок-схем и таблиц принятия решений для описания состояний и переходов в проекте.

• Примеры создания блок-схем и таблиц принятия решений для функционалов, таких как восстановление пароля.

• Рекомендации по изучению книжных методик тестирования и практическому применению на проекте.

Домашнее задание для тестировщиков

Обзор раздела: В этом разделе обсуждается домашнее задание для тестировщиков, которое поможет им углубить знания в области тестирования.

Домашнее задание для тестировщиков

• Рекомендации по самостоятельному изучению 18 основных методик тестирования через чтение статей и просмотр видео.

• Практическое применение изученных методик, например, тестирование граничных значений ввода данных.

• Важность записи и документирования результатов тестирования.

Заключительные лекции и планы на будущее

Обзор раздела: В этом разделе рассматривается завершение курса и планы на будущие лекции.

Заключительные лекции и планы на будущее

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

• Поддержка мотивации студентов после окончания курса.

• Обещание помощи студентам в случае обращения за консультацией или подсказками.

Note that the summary is based on the provided transcript and may not include all the details from the video.