Тестирование – комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).

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

Цель  – предоставление актуальной информации о соответствии производимого продукта требованиям.

Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным.

Баг (bug) — это отклонение фактического результата от ожидаемого.

Тест план (Test Plan)  – формализованное и укрупненное описание одной сессии тестирования по одному или нескольким направлениям проверок.

Отвечает на вопросы:

• Что надо тестировать?

• Что будете тестировать?

• Как будете тестировать?

• Когда будете тестировать?

• Критерии начала тестирования.

• Критерии окончания тестирования.

Тест-комплект — совокупность тест-кейсов, находящихся, как правило, в одном документе, которые проверяют какую-то определенную часть нашего проекта.

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

Верификация – это подтверждение, что были выполнены все требования предъявляемые к ПО.

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

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

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

Требования — это спецификация (описание) того, что должно быть реализовано.

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

Требования к требованиям:

• Корректность;

• Недвусмысленность;

• Полнота набора требований;

• Непротиворечивость набора требований;

• Проверяемость (тестопригодность);

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

• Понимаемость.

Классификация:

1. Прямые (т. е. формализованными в технической документации, спеках, юзер-стори и прочих формальных артефактах)

2. Косвенные (т. е. проистекающими из прямых, либо являющимися негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования данного продукта или продуктах, подобных ему).

Так же делятся на:

1. Функциональные (описывающие какие функции должен выполнять продукт)

2. Нефункциональные (требования к окружению, поддерживаемости, надежности и прочим характеристикам продукта)

Спецификация (spec) — это детальное описание того, как должно работать ПО (от заказчика, анализируем, преобразуем детально для работы команды).

Качество ПО (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

Эквивалентное Разделение (Equivalence Partitioning — EP)	Промежуток входящих значений, при которых программа должна вести себя одинаково. Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis — BVA)	Это такие значение, которые находятся на границе классов эквивалентности. Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). АГЗ может быть применен к полям, записям, файлам, или к любого рода сущностям, имеющим ограничения.
Причина / Следствие (Cause/Effect — CE)	Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — эта «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».
Предугадывание ошибки (Error Guessing — EG)	Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.
Исчерпывающее тестирование (Exhaustive Testing — ET)	Это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации (разная детализация).

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.

Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Серьезность (Severity)	Это атрибут, характеризующий влияние дефекта на работоспособность приложения. Severity выставляется тестировщиком
	S1 Блокирующий (Blocker)	Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы
	S2 Критический (Critical)	Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
	S3 Значительный (Major)	Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки
	S4 Незначительный (Minor)	Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса
	S5 Тривиальный (Trivial)	Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Приоритет (Priority)	Это степень важности, присваиваемая багу. Другими словами определяется, насколько срочно это ошибка должна быть исправлена.  Как баг влияет на сроки? Как баг влияет на процесс тестирования? Как баг влияет на работу остальных тестировщиков? Каковы затраты необходимы на устранение бага? Должны ли мы изменить требования к ПО?
	P1 Высокий (High)		Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
	P2 Средний (Medium)		Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения
	P3 Низкий (Low)		Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Цикл тестирования ПО:

1. Изучение и анализ предмета тестирования.

2. Планирование тестирования.

3. Исполнение тестирования.

Юнит-тестирование – тестирование самим программистом (вид альфа-тестирования).

По знанию внутренней системы	черный ящик (black box testing)	тестирование программы без доступа к коду		эквивалентное разбиение; анализ граничных значений; анализ причинно-следственных связей; предположение об ошибке;
	белый ящик (white box testing)	тестирование программы только по коду		покрытие решений; покрытие условий; покрытие решений и условий; комбинаторное покрытие условий;
	серый ящик (grey box testing)	тестирование без кода+тестирование по коду.
По объекту тестирования	функциональное тестирование (functional testing)	проверка того, что продукт выполняет свое прямое назначение, предоставляет функции, требуемые заказчиком\пользователями
	нефункциональное	проверка качественных характеристик продукта: скорости работы, надежности, безопасности и т.п.
Основные виды:
тестирование интерфейса пользователя (UI testing)			это вид тестирования исследования, выполняемого с целью определения, удобен ли некоторый искусственный объект для его предполагаемого применения, суть в том, чтобы интерфейс был интуитивно понятен даже непродвинутым пользователям
тестирование локализации (localization testing)			например, проверка шрифтов и другая адаптация приложения для пользователей;
тестирование скорости и надежности (load/stress/performance testing)			это вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимально допустимого уровня нагрузки для исследуемого компонента или системы. например, проверка скорости загрузки сайта при определенном количестве пользователей;
тестирование безопасности (security testing)			это тестирование с целью оценить защищенность ПО. Общая стратегия безопасности основывается на трех основных принципах: конфиденциальность; целостность; доступность; суть в том, чтобы усложнить условия для кражи данных (например телефонов и др. личной информации);
тестирование совместимости (compatibility testing)			это процесс тестирования с целью определить переносимость программного продукта. (запуск на разных операционках и браузерах.)
Тестирование возможности взаимодействия (interoperability testing)			это процесс тестирования для определения возможности взаимодействия программного продукта.
Тестирование производительности (performance testing)			это процесс тестирования с целью определить производительность программного продукта.
Тестирование надежности (reliability testing)			это процесс тестирования, исследующий надежность программного продукта.
Стрессовое тестирование (stress testing)			это вид тестирования производительности, оценивающий систему или компонент на граничных значениях рабочих нагрузок или за их пределами, или же в состоянии ограниченных ресурсов, таких как память или доступ к серверу.

3. По субъекту тестирования:  • альфа-тестировщик (alpha tester) — тестирование сотрудниками фирмы; • бета-тестировщик (beta tester) — тестирование пользователями. 4. По важности тестирования: • сначала тестирование новых функциональностей (new feature testing) — тестирование новых функциональностей; • потом регрессивное тестирование (regression testing) — повторное тестирование старых функций (как функциональное, так и нефункциональное). 5. По критерию «позитивности»сценариев:  • позитивное тестирование (positive testing) — проверки, цель которых получить положительный результат, правильную отработку системы; • негативное тестирование (negative testing) — тестируем нестандартными методами, цель – реакция ПО на некорректные запросы и ошибки (например вводим вместо 9 цифр — 11 букв). 6. По степени изолированности тестируемых компонентов: • компонентное тестирование (component testing) — это тестирование одного логического компонента; • интеграционное тестирование (integration testing) — это тестирование на уровне двух или больше логических компонентов; • системное тестирование (system or end- to-end testing) — это проверка всей системы от начала до конца. 7. По степени автоматизированности тестирования:  • ручное тестирование (manual testing) — это исполнение тест-кейсов без помощи каких-либо программ, автоматизирующих вашу работу (например, создаем аккаунт вручную); • автоматизированное тестирование (automated testing) – с использованием средств автоматизации (пример: акаунт создается программой автоматически); • смешанное/полуавтоматизированное тестирование (semi automated testing) — создаем акаунт вручную, но закупки сделаются автоматически. 8. По степени подготовки к тестированию:  • тестирование по документации (formal/documented testing) — тестирование по тест-кейсам; • эд хок-тестирование (ad hoc testing) — интуитивное тестирование без документации (например, когда что-то нужно быстро проверить).

Конверсионное тестирование (сonversion testing) — это методика тестирования, что используется для проверки того, как имеющие в системе А данные будут преобразовываться и становиться доступными для использования в системе Б.

Конформационное тестирование — это тестирование с целью убедиться, что ПО отвечает определенным отраслевым стандартам (IEEE, W3C и т.д.) для разработки ПО.

Дымовое тестирование (Smoke Testing) - Рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

Повторное тестирование (Re-testing) - Тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

В чем разница между regression testing и re-testing?

Re-testing — проверяется исправление багов

Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов.

Санитарное тестирование или проверка согласованности/исправности (Sanity Testing) - это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную.

Исполнение тестирования в 2 этапа: тестирование новых функциональностей и регрессионное тестирование.

Диаграмма связей — это инструмент управления качеством, основанный на определении логических взаимосвязей между различными данными. Применяется этот инструмент для сопоставления причин и следствий по исследуемой проблеме. 

Таблица принятия решений (decision table) — великолепный инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определенному действию.

Кодирование (coding) — это процесс написания программного кода, скриптов на определенном языке программирования (часть программирования).

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

Симулятор ПО — это модель оригинального ПО, в которой реализуется логика работы этого ПО (частично или полностью), имитируется поведение ПО, копируется его интерфейс. Симулятор по полноте функций/учитываемых параметров уже, чем эмулятор. Эмулируется объект, а симулируются его свойства, функции или поведение.

Сборка (build) — подготовленный для использования информационный продукт. Чаще всего это исполняемый файл (двоичный файл, содержащий исполняемый код программы).

Самый верхний – QA (Quality Assurance), обеспечение качества продукта путем выстраивания и оптимизации процессов как в команде тестирования, так и во взаимодействии ее с другими командами и ролями. Это стратегические задачи по обеспечению качества продукта на всех этапах его жизненного цикла от проектирования (тестирование требований), до сопровождения (обеспечение необходимых характеристик продукта при хранении, транспортировке, применении и т.п.).

QC (Quality Control), является частью QA, это контроль качества продукта\поставки\сборки путем планирования, документирования, проведения и анализа результатов тестирования. Это тактика тестирования продукта.

Тестирование (в свою очередь является частью QC) – это непосредственно выполнение тестов с целью нахождение проблем и ошибок в ПО.

Общее в QA и тестировании заключается в том, что они призваны улучшить ПО, различие между ними — в том, что

• QA призвано улучшить ПО через улучшение процесса разработки ПО;

• тестирование — через обнаружение багов.

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

• Планирование – формируется бизнес идея и определяются функциональные требования к ПО

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

• Разработка – непосредственно написание программного продукта

• Тестирование – выполняется проверка и отладка ПО в соответствии с требованиями. Сюда же относиться UAT - пользовательское тестирование и приемка ПО заказчиком

• Внедрение – предварительная тестовая установка релиза - DryRun, подготовка всех необходимых инструкций, настройка окружения и установка ПО

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

Цикл разработки ПО – это путь от идеи до внедрения и поддержки ПО.

1. Идея И-описание цели, Д-описание пути к достижению цели)

2. Разработка дизайна продукта и создание документации

3. Кодирование

4. Исполнение тестирования и исправление багов

5. Релиз

• Тест-смета (Test Estimation) — документ, включающий в себя предварительную оценку времени, необходимого на подготовку к тестированию и на тестирование новых фича (new feature testing);