По времени проведения тестирования:

Альфа-тестирование  — использование незавершённой (альфа) версии программного продукта, в которой реализована не вся функциональность, запланированная для данной версии продукта, штатными программистами (разработчиками и тестерами) с целью выявления ошибок в работе реализованных модулей и функций для их последующего устранения.

Тестирование при приёмке (дымовое тестирование) означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование. Пример: Ошибки инсталляции: если программный продукт не устанавливается, его тестирование, скорее всего, окажется невозможным.

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

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

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

Из опыта разработки ПО известно, что повторное появление одной и тех же ошибок — случай достаточно частый. Поэтому считается хорошей практикой при исправлении ошибки создать тест на неё и регулярно прогонять его при последующих изменениях программы. Хотя регрессионное тестирование может быть выполнено и вручную, но чаще всего это делается с помощью специализированных программ, позволяющих выполнять все регрессионные тесты автоматически. В некоторых проектах даже используются инструменты для автоматического прогона регрессионных тестов через заданный интервал времени. Обычно это выполняется после каждой удачной компиляции (в небольших проектах) либо каждый день или каждую неделю.

Тестирование при сдаче.

Бета-тестирование — интенсивное использование почти готовой версии продукта (как правило, программного или аппаратного обеспечения) с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю. В отличие от альфа-тестирования, проводимого силами штатных разработчиков или тестировщиков, бета-тестирование предполагает привлечение добровольцев из числа обычных будущих пользователей продукта, которым доступна упомянутая предварительная версия продукта (так называемая бета-версия). Такими добровольцами (их называют бета-тестерами) часто движет любопытство к новому продукту — любопытство, ради удовлетворения которого они вполне согласны мириться с возможностью испытать последствия ещё не найденных (а потому и не исправленных) ошибок. Кроме любопытства, мотивация может быть обусловлена чувством собственной важности от ощущения участия в важном деле, желанием повлиять на процесс разработки и в итоге получать более удовлетворяющий их нужды продукт и многим другим. Кроме того, открытие бета-тестирования может использоваться как часть стратегии продвижения продукта на рынок (например, бесплатная раздача бета-версий позволяет привлечь широкое внимание потребителей к окончательной дорогостоящей версии продукта), а также для получения предварительных отзывов о нём от широкого круга будущих пользователей. Бета-версия не является финальной версией продукта, поэтому разработчик не гарантирует полного отсутствия ошибок, которые могут нарушить работу компьютера и/или привести к потере данных. Хотя, и в финальных версиях всё чаще таких гарантий разработчики не дают.

Релиз — выпуск окончательной версии программы — готового для использования продукта. В релизе обычно собирают все версии и обновления, и выпускают конечный продукт со всеми исправлениями, который не нужно обновлять, так как он является последней версией ПО. Целью процесса управления релизами является консолидация (логическое объединение), структурирование и оптимизация всех изменений или обновлений, а также снижение риска при переводе сервиса на новый качественный уровень. Для достижения поставленной цели необходимо правильно распределить имеющиеся ресурсы и рассчитать баланс между сроками, которые отведены для внедрения всех обновлений, и временем, необходимым для подготовки внесения данных изменений. Процесс управления релизами состоит из трёх этапов:

1 этап: может, не всегда быть применим в той или иной организации, но для некоторых компаний, данный этап может являться одним из основополагающих, к ним могут относиться, например, компании по разработке программных средств или конструкторские бюро;

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

3 этап: распространение и внедрение.