Соглашусь с Albert Gareev, и хочется добавить..

“Что такое тест
Это специальная, искусственно созданная ситуация, выбранная определенным образом,
и описание того, какие наблюдения за работой программы нужно сделать
для проверки ее соответствия некоторому требованию.
”
Я это называю тест-кейс, и кажется не я один такой. А тест (или test procedure) это последовательность действий без входных данных и без ожидаемых результатов. Т.е. в совокупности данные, тест и ожидаемые результаты дают тест-кейсы. Да и по IEEE 829 мне казалось так дела обстоят.

“Вот эти 6 аспектов качества верхнего уровня:

функциональность,
надежность,
практичность,
эффективность,
сопровождаемость
переносимость.
”

Я привык разделять тестирование на функциональное и _не_ функциональное и от этого дальше по видам плясать. Стандартами конечно не подкреплю, но я всегда думал, что википедия на моей стороне

“Другие классификации видов тестирования
Чаще всего используется разбиение на три уровня, это

модульное тестирование,
интеграционное тестирование,
системное тестирование.”

Тут мне кажется с неправильного ракурса рассматриваются этапы тестирования. Если смотреть на эти этапы со стороны готовой интегрированной системы – в принципе можно как то согласится, но не нужно забывать, что эти этапы появляются последовательно обычно. +Интеграционный уровень почти не описан, а систмено-интергационного вообще нет.

На примере будет понятней наверно, что я имею ввиду. Возьмем калькулятор (я отдаю себе отчет, что в тестировании калькулятора интеграционный этап смысла не имеет, он просто взят как пример ), и допустим, что сначала мы написали код для функций умножения, сложения, деления и т.п.
Тут мы начинаем модульное тестирование – всеразличное статическое (код ревью, тулзы…) и динамическое (юнит тесты, тулзы…).
Тут мы пишем обертку для каждой функции (умножение, деление, сложение и т.п.) – для каждой функции бинарь, который параметрами командной строки принимает числа. Так мы можем проверить функциональность каждой функции отдельно (в больших проектах обычно есть промежуточный этап, а то и не один, при интеграции разрабатываемого продукта в систему, хотя вполне бывает и “Big Bang”)
Тут мы начинаем интеграционный этап тестирования – каждая функция отделана друг от друга, но ее можно уже тестировать блэк-боксом.
Ну и потом мы рисуем калькулятору ГУИ и собираем все функции воедино.
Тут мы начинаем системное тестирование – т.к. функциональность каждой отдельной операции мы уже проверяем на интеграционном уровне, то здесь нам остается проверить взаимодействие операций и корректность взаимодействия с ними через ГУИ.

Хочется всё устаканить конечно, очень правильная и классная идея, но этот вариант еще не доработан.

“Главная деятельность тестировщиков – заключается в том, что они предоставляют участникам проекта по разработке программного обеспечения отрицательную обратную связь о качестве программного продукта.”

Далее – комментарии. Обратная связь

Во-первых, я бы сказал, что “предоставление информации” – это не главная деятельность. Главная деятельность – это ДОБЫЧА той самой информации.

Во-вторых, эффективно тестировать можно и не предоставляя никому ничего. Просто так, для души. Или в целях самообучения, например.

В-третьих, можно тестировать, но о качестве не судить. Просто объективно предоставить все найденные ошибки, недостатки, и особенности.

В-четвертых, “проекта по разработке программного обеспечения” может и не быть. Например, вместо него может быть проект по внедрению купленного программного обеспечения. Здесь требуется не только тестирование в целях поиска проблем, но и поиск путей эти проблемы как-то закрыть (извне), обойти, или хотя бы поставить конечного пользователя в известность.

Ну и в заключение, я бы сказал, ныне тестирование не особенно связано только с понятием “программный продукт”. Отдельно взятая программа может работать без каких-либо проблем, а в комплексе с еще одной “валить” всю систему. Вся инфраструктура, каким-либо компонентом которой является программный продукт, нуждается в тестировании.

Вот буквально только что в другом месте я отвечал на похожий вопрос по поводу моего тренинга “Тест-дизайн от А до Я” (http://trainings.software-testing.ru/schedule?&task=3&cid=21). То есть отвечал я про тренинг, но на самом деле это было про тест-дизайн вообще. Просто процитирую свой ответ:

Тренинг “Тест-дизайн от А до Я” в каком-то смысле философский. В нём я пытаюсь рассказать не про правила тест-дизайна, а про идеи, которые породили эти правила, которые лежат в их основе.

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

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

Другое дело, что я сильно упростил картину мира, может быть это Вас смутило.

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

Да, я представил систему как замкнутую, тогда как в действительности это не так.

Но даже в такой упрощённой трактовке, мне кажется, эта модель достаточно хорошо показывает, ЗАЧЕМ нужно тестирование.