Семь принципов тестирования

Всем привет,
занимаюсь изучением ISTQB FL syllabus. И возник у меня вопрос по поводу 7го принципа тестирования: на мой взгляд, это переформулировка 1го принципа.

Principle 1 - Testing shows presence of defects.
Testing can show that defects are present, but cannot prove that there are no defects. etc.

Principle 7 - Absence-of-errors fallacy.
Finding and fixing defects does not help if the system built is unusable and does not fulfill the users' needs and expectations.

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

В чем существенная разница между указанными 2мя пунктами? Может быть даже кто-то приведет примеры?
Заранее благодарна.

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

Хммм... Не могу понять, почему вам эти принципы кажутся одинаковыми.

Принцип 1 - Тестирование указывает на наличие дефектов
Тестирование может указать на наличие дефектов, но не может доказать их отсутствия

Принцип 7 - Заблуждение об отсутствии ошибок
Поиск и исправление дефектов не исправят ситуацию, если система сложна в использовании и не удовлетворяет потребностям и ожиданиям пользователя

По-моему совершенно разные вещи.

Хммм... Не могу понять, почему вам эти принципы кажутся одинаковыми.

Принцип 1 - Тестирование указывает на наличие дефектов
Тестирование может указать на наличие дефектов, но не может доказать их отсутствия

Принцип 7 - Заблуждение об отсутствии ошибок
Поиск и исправление дефектов не исправят ситуацию, если система сложна в использовании и не удовлетворяет потребностям и ожиданиям пользователя

По-моему совершенно разные вещи.

Спасибо за перевод :)

Я в первую очередь сравниваю выделенное жирным шрифтом и обе фразы, по-моему, говорят об одном и том же.

Возможно, тут проблема с терминологией: дефект есть следствие ошибки, правильно? (в соответствии с глоссарием)

Мне кажется, что комментарий к 7му принципу совсем не проясняет его заголовок. Я поняла заголовок 7го принципа так, что, грубо говоря, ошибочно было бы полагать, что проверяемая система работает без отклонений от ожидаемого поведения, даже если все найденные дефекты исправлены.
Но, поскольку, первый принцип утверждает, что, опять же, грубо говоря, всех дефектов не найдешь, то можно предположить что отклонения от ожидаемого поведения вызваны ненайденными дефектами (т.к. дефект - следствие ошибки).
Разве тогда не выходит, что 7й принцип - в некотором смысле - следствие 1го?

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

Есть
1) Отклонения от ожидаемого заказчиком/разработчиками поведения - их мы исправили в первом принципе, но остались
2) Отклонения от ожидаемого поведения конечными юзерами. Об этом и говорит 7й принцип.
То есть в процессе работы программы юзеры с багами не сталкиваются, но, к примеру, UI настолько "красивый", что даже клавиатуру в руки брать противно, не то что работать.

Не понимаю это непонимание, попробую на примерах :)

Приходит к вам заказчик и говорит: "Хочу большую красную кнопку, которая будет делать мне хорошо"

Аналитики написали требования к кнопке, дизайнеры нарисовали интерфейс, разработчики написали код, вы протестировали, нашли 42 дефекта, их исправили. Подходит РМ и спрашивает: "продукт готов?", а вы отвечаете: "ну, я 42 бага нашёл, других не вижу, но обещать естественно не могу".

Продукт выпустили.

Развитие событий, вариант №1:

У пользователя не работает, оказывается вы многое в тестировании не учли и пропустили критичные баги. Вот он, принцип №1 в действии - то, что вы нашли 42 бага, ещё не значит, что в продукте не спрятались ещё 146.

Развитие событий, вариант №2:

Софт работает как часы (случилось чудо и вы НЕ пропустили ни одной ошибки), но пользователя красная кнопка счастливым не делает. Чтобы сделать ему хорошо, эта красная кнопка должна быть на самом деле зелёным текстовым полем, он просто неправильно выразился. Вот он, принцип №7 в действии - проверка продукта на соответствие требованием не гарантирует, что пользователь останется доволен.

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

Сделали красную кнопку на красном фоне, да еще и окружили ее десятком других красных кнопок - получили unusable system. Пользователь кнопку не видит. А если видит - то не понимает, в какую из них тыкать. Хотя тестер точно знает в какую тыкнуть, он ее находит по XPATH.

Или - кнопку видно, но по тыку система задумывается примерно на 24 часа прежде чем родить результат, текущий курс доллара по курсу ММВБ. А пользователь ожидает результат мгновенно. Получилось system does not fulfill user's expectations. Хотя тестер вполне себе может подождать результат день, прежде чем пометить тесткейс пройденным.

Ну или вообще - кнопку видно, расположена где надо, по тыку дает результат почти мгновенно. Но результат невозможно скопировать и потом вставить в Exel. Оказывается, пользователи программы именно за этим и хотели кнопку. Получили system does not fulfill users' needs. Хотя тестер всегда сравнивал результат на экране с ожидаемым и считал это достаточным.

Спасибо огромное всем участникам за разъяснения.
Я считала, что дефект - понятие точное - или он есть или его нет.
Исходная точка для поиска ошибок - требования к продукту. Если чего-то нет в требованиях, то я не могу сделать заключение о правильности работы. И я не могу начать дизайн тестов до того, как мне дадут требования к системе (они могут быть неполными на некоторых этапах - в зависимости от принятого процесса разработки). Только те опции, на которые есть требования, я могу протестировать.
Тогда фунциональность, не удовлетворяющая пользователя по причине того, что пользователь "неправильно выразился" не может быть дефектом. Такие вещи могут рассматриваться как новые возможности, влекущие новые требования и, соответственно, новые тесты.
Но как можно что-то тестировать, не формализовав на первом этапе требования, я не понимаю.