Теория Тестирования От А До Я (фундаментальная). Продвинутый Курс Тестирование ПО. Занятие 11.

• Лекция посвящена теории тестирования, которая часто встречается на собеседованиях для начинающих тестировщиков.  

• Вопросы по теории тестирования составляют 30-50% от всех вопросов на собеседованиях.  

• Лекция суммирует предыдущие темы: тест дизайн, тест документация и методологии разработки.  

• Лекция должна быть на повторе, так как 30-50% материала будет на собеседованиях.  

• Даже у мидл тестировщиков часто спрашивают по теории тестирования.  

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

• Обсуждение методологий Scrum и Kanban.  

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

• Часто используется смешанная методология Scrumban, где элементы Scrum сочетаются с элементами Kanban.  

• Не стоит смотреть видео о том, как стать тестировщиком или сколько зарабатывают тестировщики.  

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

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

• Первоисточник лекции - статья "Фундаментальная теория тестирования".  

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

• Лекция будет сухой, но с примерами и объяснениями.  

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

• Тестирование включает планирование, проектирование тестов, выполнение и анализ результатов.  

• Эти темы обсуждались на предыдущих лекциях.  

• Чек-лист относится к дизайну тестов.  

• Тест-план создается для выполнения тестов.  

• Тест-экшин - это непосредственное тестирование.  

• Тест-анализ включает анализ результатов тестирования.  

• Качество ПО - это совокупность характеристик, удовлетворяющих потребности.  

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

• Верификация - оценка соответствия продукта требованиям.  

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

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

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

• Анализ продукта, работа с требованиями, разработка тест-плана.  

• Создание тестовой документации, тестирование, отчеты тестирования.  

• Стабилизация и эксплуатация системы.  

• Тест-план описывает объем работ по тестированию и отвечает на вопросы "что?", "когда?", "где?".  

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

• Тест-дизайн включает разработку и проектирование тест-кейсов.  

• Тест-дизайн - это разработка тест-кейсов.  

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

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

• Тест-аналитик определяет, что тестировать.  

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

• На практике часто все делает один тестировщик.  

• Исчерпывающее тестирование: проверка всех возможных комбинаций входных значений.  

• Эквивалентное разделение: тестирование по интервалам значений.  

• Анализ граничных значений: тестирование на границах категорий.  

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

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

• Упрощение сложных терминов для лучшего понимания.  

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

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

• Логичность и важность этой техники.  

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

• Использование расширений для генерации невалидных данных.  

• Пример использования фейк-филлера для заполнения форм.  

• Фейк-филлер заполняет формы рандомными данными.  

• Важность тестирования форм для выявления ошибок.  

• Применение техник тест-дизайна для эффективного тестирования.  

• Тестирование email-поля всеми возможными значениями нереально.  

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

• Доступ к коду помогает продвинутым тестировщикам.  

• Валидация полей в коде: email, имя, пароль.  

• Email должен быть строкой и обязательным полем.  

• Ошибки при неверном вводе email различаются на разных языках.  

• Тестирование в коде называется white box.  

• Валидация email-поля в библиотеке.  

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

• Тестировщики могут перейти в разработку или автоматизацию.  

• Использование Postman и JQuery для полуавтоматизации.  

• Важно не бояться кода и знать английский.  

• PR-тест: проверка всех пар значений вместо всех сочетаний.  

• Таблица принятия решений: набор условий для определенного действия.  

• Диаграмма состояний: описание поведения системы.  

• Кейсы как техника тест-дизайна: тестирование от разных ролей.  

• Важность тестирования с точки зрения бизнеса и пользователя.  

• Юзабилити-кейсы: обобщенные сценарии использования системы.  

• Блок-схема: диаграмма с ромбиками для вопросов и кружочками для действий.  

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

• Обсуждение шуток и анекдотов.  

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

• Принцип контекстного тестирования, зависящего от проекта.  

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

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

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

• Сбор информации от каждого участника по отдельности.  

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

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

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

• Анализ данных о поведении пользователей на сайте.  

• Определение приоритетных тест-кейсов на основе данных аналитики.  

• Большая часть дефектов содержится в небольшом количестве модулей.  

• Принцип Порета также применим.  

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

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

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

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

• Эксплореры изучают систему, проектируют тесты и тестируют одновременно.  

• Тестирование от балды выполняется без подготовки и проектирования тестов.  

• Это неформальное и импровизационное тестирование.  

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

• Тест-кейсы должны быть конкретными и понятными для команды.  

• Включают идентификатор, название, тип, приоритет, предусловия и пост-условия.  

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

• Баг-репорт описывает последовательность действий, приведших к некорректной работе системы.  

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

• Номер версии, серьезность, приоритет и статус бага.  

• Автор тест-кейса и назначение на разработчиков.  

• Окружение бага: продакшн, стейджинг, девелопмент.  

• Скриншоты, видео, логины, пароли, консоль, ошибки.  

• Логи с мобильных устройств и ошибки на сервере.  

• Запросы с сети и аналитика.  

• Данные из базы данных и дата/время обнаружения бага.  

• Комментарии, заметки, ссылки на другие баги.  

• Линковка задач для блокировки и разблокировки.  

• Severity: критичность дефекта, выставляется тестировщиком.  

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

• На практике часто используется только priority.  

• Матрица как таблица для оценки соответствия требований.  

• Пример вопроса на собеседовании о matrix.  

• Обсуждение двумерной таблицы и её восприятия.  

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

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

• В таблице требования находятся в колонках, тест-кейсы в строках.  

• Пересечения требований и тест-кейсов отмечаются галочками.  

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

• Матрица покрытия проверяет соответствие требований и тест-кейсов.  

• В заголовках колонок таблицы находятся требования, в заголовках строк — тест-кейсы или чек-листы.  

• Важно осознавать и запоминать информацию, а не просто слушать.  

• Дефект и баг — это несоответствия фактического и ожидаемого результатов.  

• Ошибка — это ошибка программиста или пользователя.  

• Сбой — это полный отказ компонента или системы.  

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

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

• Важно учитывать контекст и возможность обхода дефекта.  

• Модульное тестирование — тестирование отдельных частей кода.  

• Интеграционное тестирование — тестирование взаимодействия между частями кода.  

• Системное тестирование — тестирование всей системы через Postman или другие инструменты.  

• Обсуждение тестирования через Postman.  

• Примеры использования Stripe и PayPal как готовых систем.  

• Пост-терминалы и их взаимодействие с другими системами.  

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

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

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

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

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

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

• Тестирование делится на функциональные и нефункциональные виды.  

• Функциональные виды включают функциональное тестирование, тестирование пользовательского интерфейса и тестирование безопасности.  

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

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

• Тестирование пользовательского интерфейса проверяет дизайн и функциональность интерфейса.  

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

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

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

• Стрессовое тестирование проверяет систему при пиковых нагрузках.  

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

• Тестирование стабильности проверяет, что система работает без перебоев.  

• Тестирование установки проверяет, что программа устанавливается и работает на разных версиях ОС.  

• Тестирование удобства пользования проверяет, что интерфейс удобен для использования.  

• Тестирование на отказы проверяет, что система автоматически перезапускается после сбоя.  

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

• Дымовое тестирование проверяет основной функционал системы.  

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

• Основной функционал системы не углубляется.  

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

• Тестировщик использует чек-лист с приоритизированными пунктами.  

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

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

• Если дым не выходит, труба считается качественной.  

• Регрессивное тестирование проводится после исправления бага.  

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

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

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

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

• Тестирование сборки включает проверку нового функционала или исправлений.  

• Санитарное тестирование проверяет конкретную фичу или функцию.  

• Часто путается с smoke-тестированием, но имеет свои нюансы.  

• Smoke-тестирование проверяет основной функционал системы, а sanitary-тестирование фокусируется на конкретной фиче.  

• Тестирование делится на функциональное и нефункциональное.  

• Виды тестирования по степени автоматизации: ручное, полуавтоматизированное и автоматизированное.  

• По знанию системы: белый, серый и черный ящик.  

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

• Серый ящик: частичный доступ к коду, тестирование с использованием знаний о системе.  

• Черный ящик: отсутствие доступа к коду, тестирование как конечный пользователь.  

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

• По целям: функциональное и нефункциональное тестирование.  

• Нефункциональное тестирование включает производительность, масштабируемость и безопасность.  

• Повторное тестирование, основное тестирование, приемочное тестирование.  

• Комплексное тестирование включает все виды тестирования.  

• Входное тестирование и исследовательское тестирование.  

• Статическое тестирование без запуска кода, динамическое тестирование с запуском кода.  

• Статическое тестирование проверяет документацию и требования, динамическое тестирование проверяет работу системы.  

• Раннее тестирование начинается на этапе разработки требований.  

• Статическое тестирование включает код ревью и использование статических анализаторов кода.  

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

• Тестирование демонстрирует наличие дефектов, но не доказывает их отсутствие.  

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

• Раннее тестирование помогает найти дефекты на ранних этапах разработки.  

• Тестировщик должен подключаться к тестированию на этапе формирования требований.  

• Задавать вопросы по требованиям и диаграммам помогает выявить дефекты на ранних стадиях.  

• Раннее тестирование дешевле и эффективнее, чем исправление багов в рабочей системе.  

• Дефекты часто скапливаются в сложных частях системы.  

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

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

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

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

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

• Тестирование зависит от контекста и принципов истины.  

• Заблуждение об отсутствии ошибок: тестирование не доказывает отсутствие дефектов.  

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

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

• Примеры требований: валидация полей, уникальные email, ограничения на длину имени и пароля.  

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

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

• Модифицируемость и трассируемость требований.  

• Создание бага в Jira, назначение на конкретного человека.  

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

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

• Если баг исправлен, его закрывают.  

• Разработчик может перевести баг в статус "открыт" или "с ту", если знает, кто виноват.  

• Тим лид другой команды может решить, что делать с багом.  

• Первая стадия: идея или полисе.  

• Вторая стадия: сбор и анализ требований.  

• Третья стадия: документирование требований.  

• Четвертая стадия: дизайн, включая архитектуру и дизайн страниц.  

• Пятая стадия: разработка.  

• Шестая стадия: тестирование.  

• Седьмая стадия: внедрение и развертывание.  

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

• Девятая стадия: смерть программы.  

• Каскадное водопадное тестирование.  

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

• Канбан-доска с минимальным количеством задач.  

• Скрам с спринтами от одной до четырех недель.  

• Груминг, оценка задач, начало спринта, демка, ретроспектива.  

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

• Обучение джунов через ежедневные созвоны и совместную работу.  

• Объяснение разницы между кей тестером и тестером.  

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

• Автор обещает добавить краткие описания и названия к теории тестирования.  

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

• Упоминает, что в статье содержится 90% необходимой информации.  

• Автор объясняет, что материал был переработан и систематизирован из статьи.  

• Убирает лишнее и добавляет более понятные определения.  

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

• Автор считает, что большинство книг по ручному тестированию не содержат новой информации.  

• Рекомендует осознанно прочитать книги Савина и Куликова.  

• Утверждает, что после прочтения этих книг, курсы тестировщиков не нужны.  

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

• Предлагает переписать статью в конспект или использовать ссылки на видео.  

• Обещает добавлять новые материалы и улучшать статью.  

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

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

• Призывает всех фотографироваться и изучать материал.