Тестирование ПО - процесс анализа или эксплуатации ПО с целью выявления дефектов. Основоположник тестирования - Гленфорд Майерс.


Роль и место тестирования в жизненном цикле разработки ПО.

Этапы разработки ПО:
	• разработка требований к программному продукту;
	• проектирование ПО / алгоритмизация;
	• реализация алгоритма;
	• тестирование и отладка ПО;
	• внедрение и сопровождение ПО.

Zero-defect mindset - установка на нулевое кол-во ошибок (не переходить к следующему этапу разработки, пока не исправлен предыдущий).


Основные определения.

Поскольку появилось огромное количество тестирования, их классификацию принято рассматривать по отдельным признакам:
	1. виды тестирования по знанию внутреннего устройства программы:
		a. тестирование по методу чёрного ящика (black box testing);
		b. тестирование по методу белого ящика (white box testing);
		c. тестирование по методу серого ящика (gray box testing).
	2. виды тестирования по объекту тестирования:
		a. требования к программному продукту;
		b. тестирование исходного кода (code-review);
		c. модульное тестирование;
		d. интеграционное тестирование;
		e. объектно-ориентированное тестирование;
		f. функциональное тестирование;
		g. системное тестирование;
		h. тестирование программного интерфейса;
		i. тестирование удобства использования;
		j. локализационное тестирование (проверка работы при переходе на другой язык);
		k. тестирование производительности;
		l. тестирование безопасности;
		m. тестирование на совместимость / кроссплатформенное (кроссбраузерное) тестирование.
	3. виды тестирования по субъекту тестирования:
		a. тестирование, проводимое программистом;
		b. тестирование, проводимое тестировщиком (функциональное, локализационное, интерфейса, удобства использования, безопасности, производительности);
		c. случайным человеком / посторонним (ad-hoc testing).
	4. виды тестирования по позитивности тестов:
		a. позитивные тесты (проверка работы программы в стандартных ситуациях);
		b. негативные тесты (проверка на устойчивость к ошибкам и нестандартным ситуациям).
	5. виды тестирования по степени изолированности:
		a. модульное тестирование;
		b. интеграционное тестирование;
		c. системное тестирование.
	6. виды тестирования по степени автоматизации:
		a. ручное тестирование (manual);
		b. автоматизированное (с помощью инструментов автоматизации);
		c. полу-автоматизированное тестирование (человек + инструменты).
	7. виды тестирования по степени подготовки:
		a. по тестовым случаям;
		b. случайное тестирование.
	8. виды тестирования по запуску программы на выполнение:
		a. статическое тестирование (проводится без запуска программы, путём просмотра кода);
		b. динамическое тестирование (проводится посредством запуска программы).
	9. виды тестирования по хронологии тестирования:
		a. до передачи пользователю (почти все виды тестирования + альфа-тестирование - предрелизная проверка работы программы, в результате которой могут вноситься незначительные изменения);
		b. после передачи пользователю (бета-версия - функционал реализован, исправляются ошибки).


Смежные вопросы тестирования. Экономическая сторона тестирования.
Классическая пирамида тестирования (ниже - чаще)
	• функциональное
	• интеграционное
	• модульное

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

3 концепции установки качества:
	• good enough quality - в большинстве случаев формируется какой-то критерий (планка) качества, при достижении которой процесс тестирования можно заканчивать. Эта планка прописывается в тестовом плане;
	• best possible quality. Используется при написании программ в сферах здравоохранения и прочих сферах, где ошибки недопустимы;
	• quality if time permits.


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

-----------------------------------------------------------------------------------------------

Разработка к любому программному продукту начинается с разработки требований к программному продукту.

Этапы разработки требований:
	• опросы заказчика - проводится интервью с заказчиком в виде вопросов и ответов. Используются слайды, макеты и чертежи, обсуждаются пожелания заказчика;
	• подготовка документа требований - по мере получения информации от заказчика требования к будущему ПО фиксируются в специальном документе. Свойства требований:
		○ каждое требование должно иметь уникальный идентификатор;
		○ требования должны быть представлены с точки зрения пользователя и не затрагивать внутренние свойства системы и детализацию кода. Документ составляется на человеческом языке;
		○ в перечень требований должны быть включены как функциональные, так и нефункциональные требования;
		○ документ требований должен храниться в безопасном месте и находиться под управлением конфигурациями (постоянно изменяется, существует версионность, может быть заморожен).
	• разработка спецификации требований (спецификации к ПО) - это документ, который описывает то же самое, что и документ требований, но предназначен для разработчика, поэтому содержит уточнённые данные и нужные технические детали (используемые библиотеки, классы и типы данных, элементы и объекты интерфейса);
	• построение матрицы прослеживаемости требований (Requirements Traceability Matrix)- используется чтобы поставить в соответствие каждому требованию реализованный компонент на других этапах разработки ПО. Такой подход позволяет не потерять ни одно требование ни на каком из этапов.
	№ требования	№ в проекте	№ в коде	№ в тестах
	R1000	P1000.1	C1000.1	T1000.1
		P1000.2	C1000.2	T1000.2
	R1001	P1001	C1001	T1001
	…	…	…	…
	Для тестировщиков интересны только таблицы с № требования и № в тестах для определения покрытия программы тестами;
	• Проверка требований программного продукта. Критерии:
		○ полнота - набор требований считается полным, если все его составные части представлены и каждая часть выполнена в полном объёме. Требования не должны содержать выражений. Фразы  т.д., и т.п., и прочее подлежит уточнению.
			§ все функциональности должны быть разбиты на функциональные роли;
			§ в требованиях предусмотреть описание ограничений и формат вводимых данных;
			§ должна быть описана реакция системы на все действия (стандартные и нестандартные).
		○ однозначность - требование должно допускать единственное толкование и должно быть удобочитаемым и понятным;
		○ непротиворечивость - требования не должны противоречить друг другу;
		○ прослеживаемость - требования должны иметь уникальный идентификатор;
		○ осуществимость - каждое требование должно ставить перед системой реально осуществимые задачи как с функциональной точки зрения, так и в смысле затрат времени и средств на разработку;
		○ контролепригодность - каждое требование должно быть измеряемым, чтобы его можно было проверить.
	• Категории требований к программному продукту:
		○ функциональные средства/требования - требования этой категории определяют какие функциональности будет выполнять продукт, а какие не будет;
		○ интерфейсная - эти требования описывают входы, получаемые из внешних систем, и выходы;
		○ данные - эти требования описывают формат данных, ограничения, скорость передачи, точность вычисления, способ сохранения, …;
		○ производительность - эти требования описывают проблемы масштабирования и синхронизации;
		○ пользователи и человеческий фактор - описывает уровень квалификации пользователя;
		○ безопасность - описывается возможность доступа к системе, где её данные должны дублироваться и как часто;
		○ документация - описывает какая документация должна быть в системе;
		○ устранение неисправностей - реакция системы на непредвиденные ситуации;
		○ сопровождение - каковы условия поставки новых версий, сроки поддержки продукта и т.д.