Home

Автор: Ben Simo
Перевод: Алексей Баранцев

Оригинальная публикация (на английском языке)

"... часто можно встретить такое определение тестирования: 'Тестирование представляет собой процесс подтверждения корректности программы. Это демонстрация отсутствия дефектов'. Основная проблема с этим определением в том, что оно совершенно неправильное. В действительности его можно считать определением антонима тестирования".

- Glenford Myers,
Software Reliability: Principles & Practices, 1976

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

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

Проблема со всем этим хозяйством заключается в том, что мы не в состоянии доказать корректность компьютерных программ. Мы не можем доказать отсутствия дефектов. Мы не можем протестировать программу во всех состояниях и на всех возможных входных данных. Мы не можем проверить все возможные получаемые результаты. Мы не можем полностью понять потребности всех заинтересованных лиц. Мы не может доказать, что пользователи будут довольны. Мы не можем доказать, что программный продукт сможет решать проблемы, для решения которых он был создан. Если бы это всё было возможно, я полагаю, страховые компании нашли бы способ, как продавать страхование качества программ.

"Если вы думаете, что вы можете полностью протестировать программу, не проверяя её реакцию на всех возможных входных данных -- отлично. Дайте мне список всех ваших тестов. Мы напишем программу, которая успешно пройдёт через все эти тесты, но будет с грохотом падать на входных данных, для которых у вас не было тестов. Если мы можем сделать это намеренно, нет оснований отвергать возможность того, что мы или другие программисты не могут сделать это случайно".

- Cem Kaner, Jack Falk, and Hung Quoc Nguyen,
Testing Computer Software, Second Edition, 1999

Теперь, спустя тридцать два года после того, как Гленфорд Майерс назвал "тестирование как сопособ доказательства корректности" противоположностью тестированию, мы оказались окружены практиками и инструментами, которые предназначены для доказательства корректности. Миф о возможности доказательства корректности жив и прекрасно себя чувствует.

Деятельность, нацеленная на попытки доказательства корректности программы -- это противоположность тестирования.

Но если тестирование это не валидация, тогда что же это? Тестирование -- это исследование программы и донесение информации о тех или иных аспектах качества до лиц, принимающих решения.

"Тестирование -- это процесс, посредством которого мы изучаем и понимаем, каковы могут быть выгоды и риски, связанные с выпуском программной системы".

- James Bach,
James Bach on Risk-Based Testing, STQE Magazine, Nov 1999

"Тестирование выполняется с целью сбора информации. Решения о проекте или продукте принимаются на основании этой информации".

- Cem Kaner, James Bach, Bret Pettichord,
Lessons Learned In Software Testing: A Context-Driven Approach, 2002

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

- Brett Pettichord,
Don't Become the Quality Police, StickyMinds.com, 2002

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

Обсудить в форуме