Сообщений в теме: 46

[barancev]

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

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

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

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

Читать статью...

[SALar]

Статья хорошая. Теперь вопрос.

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

А зачем для этого использовать такой дорогой метод как тестирование? Для определения качества можно воспользоваться более дешевыми методами.

[barancev]

А зачем для этого использовать такой дорогой метод как тестирование? Для определения качества можно воспользоваться более дешевыми методами.

Если я правильно понял твой вопрос -- автор предлагает считать тестированием именно этот более дешёвый метод, а не деятельность по валидации.

[Clauster]

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

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

[Case]

Статья хорошая. Теперь вопрос.

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

А зачем для этого использовать такой дорогой метод как тестирование? Для определения качества можно воспользоваться более дешевыми методами.

Какой(-ие) например?

[Alfa]

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

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

А у меня получается (если просто взять отрицание), что тестированием является деятельность не нацеленная на попытки доказательства корректности программы. Довольно общее определение, но похоже на правду.

По поводу всей статьи вспоминается цитата из Кнута:

Beware of bugs in the above code; I have only proved it correct, not tried it.

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

[SALar]

Статья хорошая. Теперь вопрос.

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

А зачем для этого использовать такой дорогой метод как тестирование? Для определения качества можно воспользоваться более дешевыми методами.

Какой(-ие) например?

Чтобы забраковать партию слив не обязательно пробовать каждую. Для того чтобы вынести суждение о соответствии или несоответствии программы заданным метрикам качествам с высокой долей вероятности не обязательно проводить полное тестирование.

Недавно занимался исследованием CMS. Как полагается, метрики, способы оценки, интегральная оценка. Так вот, для того чтобы определить, что:
1) CMS не соответствует необходимым нам метрикам качества
2) CMS не соответствует заявленным производителем метрикам качества (ложь на сайте производителя)
обычно было достаточно 4-8 часов.

Как правило, сыпались на двух вещах:
1) ошибки проектирования интерфейса
2) архитектурные ошибки
До проверки функционала дело даже не доходило.

[barancev]

А зачем для этого использовать такой дорогой метод как тестирование? Для определения качества можно воспользоваться более дешевыми методами.
...
Чтобы забраковать партию слив не обязательно пробовать каждую. Для того чтобы вынести суждение о соответствии или несоответствии программы заданным метрикам качествам с высокой долей вероятности не обязательно проводить полное тестирование.

Неполное тестирование является более дешёвым методом, чем полное тестирование, ага :)

[Case]

Статья хорошая. Теперь вопрос.

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

А зачем для этого использовать такой дорогой метод как тестирование? Для определения качества можно воспользоваться более дешевыми методами.

Какой(-ие) например?

Чтобы забраковать партию слив не обязательно пробовать каждую. Для того чтобы вынести суждение о соответствии или несоответствии программы заданным метрикам качествам с высокой долей вероятности не обязательно проводить полное тестирование.

Полное или не полное это вопрос второй. Вместо тестирования есть другие методы чтобы узнать?

[Clauster]

Если не выдергивать вывод из контекста статьи, то там все нормально: цель тестирования не в доказательстве корректности ПО, а в предоставлении информации о её качестве. То, что Сергей говорит про метрики это не является тестированием, о чем и говорит автор в выводе.

[Pryanik]

Корректность - это один из факторов качества. Я бы сказал, что цель тестирования заключается НЕ ТОЛЬКО в доказательстве(определении) корректности (имеется ввиду выполнять точные задачи так, как они определены их спецификацией), но и определение других факторов качества.

[Clauster]

Корректность - это один из факторов качества. Я бы сказал, что цель тестирования заключается НЕ ТОЛЬКО в доказательстве(определении) корректности (имеется ввиду выполнять точные задачи так, как они определены их спецификацией), но и определение других факторов качества.

В статье под корректностью подразумевается совсем другое. См. 3 абзац. А своим постом вы только подтверждаете вывод автора.

[Pryanik]

Корректность - это один из факторов качества. Я бы сказал, что цель тестирования заключается НЕ ТОЛЬКО в доказательстве(определении) корректности (имеется ввиду выполнять точные задачи так, как они определены их спецификацией), но и определение других факторов качества.

В статье под корректностью подразумевается совсем другое. См. 3 абзац. А своим постом вы только подтверждаете вывод автора.

С автором я во многом разделяю мнения. Этот скорее не к автору статьи а к вашему предыдущему комментарию. Уточнил ваш вывод своими словами

[Green]

Коллеги,

должен вам признаться, что статья ни о чем.

Собственно, какой вывод можно сделать по прочтении этой статьи? Что некий тестировщик Бен считает себя свободным художником, исследователем с большой буквы. И на этом основании он не может гарантировать вам ничего. Хотя, пардон, он может гарантировать, что в программе есть дефекты. Ну и что? Как будто мы с вами не знаем, что каждая программа содержит дефекты.

Да пусть он считает себя хоть космонавтом или исследователем глубин космоса в стенах славной организации НАСА, что из этого? Лично мне это не дает никакой полезной информации.

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

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

Лично по мне, вся эта статья - игра в слова и не более.

[novak]

должен вам признаться, что статья ни о чем.

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

[Clauster]

Коллеги,

должен вам признаться, что статья ни о чем.

Собственно, какой вывод можно сделать по прочтении этой статьи? Что некий тестировщик Бен считает себя свободным художником, исследователем с большой буквы. И на этом основании он не может гарантировать вам ничего. Хотя, пардон, он может гарантировать, что в программе есть дефекты. Ну и что? Как будто мы с вами не знаем, что каждая программа содержит дефекты.

Да пусть он считает себя хоть космонавтом или исследователем глубин космоса в стенах славной организации НАСА, что из этого? Лично мне это не дает никакой полезной информации.

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

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

Лично по мне, вся эта статья - игра в слова и не более.

Судя по всему автор явный адепт context-driven школы тестирования и её пропагандирует. То, что вы не представляете себе, как можно работать отказавшись от валидации, ещё не значит что это невозможно. Не все любят и не всем подходят тяжелые процессы.

[barancev]

Да, чтобы контекст статьи был более ясен, следовало, наверное, сказать немного об авторе.

Бен Саймо -- президент ассоциации тестировщиков AST. Соответственно, по долгу службы, главный вдохновитель и организатор конференции CAST 2009. А также "антиконференции" FROSST. Последователь context-driven школы тестирования (как, впрочем, большинство верхушки AST).

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

[SALar]

Полное или не полное это вопрос второй. Вместо тестирования есть другие методы чтобы узнать?

* аудит софта
* экспертная оценка (положение фирмы на рынке и наличие доступной техподдержки относятся к метрике "надежность")
* опросы организаций внедривших ПО
* ...

[SALar]

Или например так.

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

[Pryanik]

Полное или не полное это вопрос второй. Вместо тестирования есть другие методы чтобы узнать?

* аудит софта
* экспертная оценка (положение фирмы на рынке и наличие доступной техподдержки относятся к метрике "надежность")
* опросы организаций внедривших ПО
* ...

Тестирование является основным(основопологающим) методом оценки качества. А приведенные выше методы не дадут вам объективной оценки качества ПО, хотя и их надо принимать во внимание. Я бы сказал 99% оценки качества - тестирование, 1% - все остальное (кстати "опросы организаций внедривших ПО" мне кажется можно тоже отнести к тестированию, бета-тестирование).