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

[rps5]

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

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

Не подскажете стоимость данных методов по отношению к стоимости тестирования?

[SALar]

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

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

Не подскажете стоимость данных методов по отношению к стоимости тестирования?

Аудит крупной системы вполне может обойтись в 10-20 раз дешевле полноценного промышленного тестирования.

[Clauster]

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

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

Не подскажете стоимость данных методов по отношению к стоимости тестирования?

Аудит крупной системы вполне может обойтись в 10-20 раз дешевле полноценного промышленного тестирования.

Т.е. разработчики пишут код, а потом заказывают аудит того, что написали? И так 10-20 раз? :)

[Pryanik]

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

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

Не подскажете стоимость данных методов по отношению к стоимости тестирования?

Аудит крупной системы вполне может обойтись в 10-20 раз дешевле полноценного промышленного тестирования.

Но ведь и оценка качества будет менее точна в 10-20 раз.
А что вы понимаете под аудитом? Разве в аудит ПО не входит тестирование?

[SALar]

Т.е. разработчики пишут код, а потом заказывают аудит того, что написали? И так 10-20 раз? :)

Нет

Но ведь и оценка качества будет менее точна в 10-20 раз.

Нет

Ладно, я все понял. Попробую что нибудь придумать. Или тренинг, или статью, или на конференцию заявлю доклад.

[Green]

Коллеги,

все дружно встали на защиту автора, поэтому я решил объяснить свою позицию.

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

ОК. Нет проблем.

Что же он предлагает взамен? Он предлагает исследовать программы и информировать о состоянии качества тех, кто принимает решение.

И с этим нет никаких проблем. Все верно.

Кроме одного.

За большинством понятий, которые автор отвергает как ложные, я вижу вполне понятную и устоявшуюся методику. Например, проверку на соответствие спецификациям. Да, мы не можем гарантировать того, что спецификация полностью покрывает потребности заказчика. Но это и не задача тестирования. Но проверить соответствие спецификации и реализации мы должны. И после проверки можем ГАРАНТИРОВАТЬ - имеются или нет между ними расхождения.

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

И так практически по каждому пункту. За исключением одного - гарантия отсутствия дефектов в программе. Ну что же, оставим хоть что-то.

Теперь представим, что автор прав. Все это - от беса. И теперь он берется исследовать (не валидировать) программу. Тогда расскажите мне, как он это будет делать? Да пусть он трижды ТДД специалист, он все равно будет использовать приемы моделирования для того, что бы подтвердить - работает этот кусок кода или нет. Ему все равно придется обращаться к спецификации (берем правильный случай), составлять тесты, выдавать метрики и т.п.

Или он будет делать что-то совершенно другое? В статье это не описано.

Резюме:

Если брать лозунг - нет гарантии отсутствия дефектов, то все правильно.
Но когда начинают отбрасывать стандартные методы работы, то стоит 10 раз подумать.

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

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

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

[Alfa]

И после проверки можем ГАРАНТИРОВАТЬ - имеются или нет между ними расхождения.

За исключением одного - гарантия отсутствия дефектов в программе. Ну что же, оставим хоть что-то.

Противоречие. Дефекты и есть расхождения.

[Green]

И после проверки можем ГАРАНТИРОВАТЬ - имеются или нет между ними расхождения.

За исключением одного - гарантия отсутствия дефектов в программе. Ну что же, оставим хоть что-то.

Противоречие. Дефекты и есть расхождения.

В чем же здесь противоречие?

Если есть отличие реализации от спецификации, то это оформляется в виде дефекта.

Но в программе кода ВСЕГДА больше, чем того требуется по спецификации. Поэтому даже при полном совпадении реализации и спецификации всегда есть не проверенные места. Следовательно, мы не можем гарантировать отсутствие дефектов. Потому что мы просто не знаем - есть дефекты или нет.

[Alfa]

И после проверки можем ГАРАНТИРОВАТЬ - имеются или нет между ними расхождения.

Следовательно, мы не можем гарантировать отсутствие дефектов. Потому что мы просто не знаем - есть дефекты или нет.

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

Необходимо проверить, что программа делает то что должна, но так же и то, что она не делает того что не должна.

(примерная цитата, источник искать лень, какой-то классик)

[Clauster]

...автор отвергает как ложные...

Очевидно, вы неверно поняли смысл статьи. Как лично я понял, автор говорит о том, что многие люди, считающие что они занимаются тестированием, на самом деле занимаются валидацией. И сейчас, даже спустя 32 года (уже 33) после того как Майерс назвал эту деятельность антонимом тестирования, миф о том что это тестирование крепко засел в головах специалистов. И настолько крепко, что они уже не тестируют, а только лишь валидируют. Автор предлагает попрощаться с этим мифом (не отказаться от методов) и уделить время действительно тестированию. На днях Джеймс Бах выложил в своем блоге статью Quality is dead - не поэтому ли?

[novak]

Но проверить соответствие спецификации и реализации мы должны.

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

[Green]

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

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

У меня точно не было. Всегда приходилось жестко планировать работу, выбирать между первостепенным и второстепенным, между тем что оставить в работе, а что отбросить или отложить. На основании чего можно делать такие выводы? Я полагаю, на основании четкого структурированного подхода: спецификация, требования, критерии, сроки и т.п. Даю 100% - свой отчет о проделанной работе автор формулирует именно в таких терминах.

А вот как раз "свободное парение", исследование, ассоциируется у меня с низкопрофессиональным подходом, с отсутствием четкой методики. Этот метод подходит только в начале работы, на стадии знакомства с приложением или периодически, в процессе тестирования, для смены вида деятельности.

Но!

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

Однако, когда это преподносится мне как откровение свыше, то я вспоминаю историю с борьбой сторонников процессных и быстрых методологий в разработке (историю см выше).

[Clauster]

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

да и не раз

А вот как раз "свободное парение", исследование, ассоциируется у меня с низкопрофессиональным подходом, с отсутствием четкой методики. Этот метод подходит только в начале работы, на стадии знакомства с приложением или периодически, в процессе тестирования, для смены вида деятельности.

для справки http://en.wikipedia....oratory_testing

[novak]

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

[barancev]

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

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

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

Да, мы не можем гарантировать того, что спецификация полностью покрывает потребности заказчика. Но это и не задача тестирования. Но проверить соответствие спецификации и реализации мы должны. И после проверки можем ГАРАНТИРОВАТЬ - имеются или нет между ними расхождения.

Сергей, наука математика утверждает обратное -- за исключением достаточно узкого класса задач, в общем случае, мы действительно не можем гарантировать полное соответствие спецификации и реализации. Даже если у нас есть полная формальная спецификация, что, согласись, бывает далеко не всегда :)

А вот как раз "свободное парение", исследование, ассоциируется у меня с низкопрофессиональным подходом, с отсутствием четкой методики. Этот метод подходит только в начале работы, на стадии знакомства с приложением или периодически, в процессе тестирования, для смены вида деятельности.

Профессиональная разведка (какая бы это ни была разведка -- хоть шпионаж, хоть геологическая, хоть научный поиск) никогда не является "свободное парением". Это целенаправленная, планируемая и управляемая деятельность. И, кажется, наиболее эффективная форма деятельности в условиях высокой неопределённости. Что совсем не редкость в IT-проектах.

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

Это что, валидация? Гарантия отсутствия дефектов или установление соответствия, вот так вот, отбросив "второстепенное"? Тестирование на основе рисков гораздо ближе к исследовательскому, практически даже совпадает с ним, и весьма далеко от "валидационных" подходов. Сергей, ведь ты, не зная этого, оказывается говорил прозой :)

[rps5]

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

Согласен.
Совсем без исследовательского тестирования, имхо, обходиться нельзя. Есть риск пропустить ошибку, с которой могут столкнуться пользователи. (И дело тут даже не в качестве тестпланов.)
Естественно также, что использовать только этот метод, т. е. обходиться без документации, нельзя.

[Green]

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

Алексей,
большое спасибо. Ты да же не догадываешься, как ты прав.

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

Вот вы мне тогда разъясните, темному, что такое делает автор, чего нельзя сделать в подходе называемом "валидация" и что такое можно сделать в авторском подходе, чего нельзя сделать методами "валидации"?

Заранее благодарю.

[Clauster]

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

Это не статья, это заметка в блоге. Разницу улавливаете?

Вот вы мне тогда разъясните, темному, что такое делает автор, чего нельзя сделать в подходе называемом "валидация" и что такое можно сделать в авторском подходе, чего нельзя сделать методами "валидации"?

Заранее благодарю.

Это уже похоже на слепую ярость - вы один и тот же вопрос задаете два раза подряд. :) У меня сложилось впечатление, что вы даже не пытаетесь понять статью, а просто хотите её дискредитировать.
Вроде там понятно написано:
Валидация - деятельность, нацеленная на попытки доказательства корректности программы.
Тестирование - исследование программы и донесение информации о тех или иных аспектах качества до лиц, принимающих решения.
Методами валидации не получится исследовать систему. Валидация != тестирование, но это и не взаимоисключающие вещи и сравнивать их как минимум бестолково. По поводу "что такого делает автор" я уже давал ссылку, далее можно копать блоги Канера, Баха, их книжку Lessons Learned in Software Testing (только на английском). По теме risk-based testing есть книжка Pragmatic Software testing от Рекса Блэка. Правда, все это на английском языке.

[barancev]

Вот вы мне тогда разъясните, темному, что такое делает автор, чего нельзя сделать в подходе называемом "валидация" и что такое можно сделать в авторском подходе, чего нельзя сделать методами "валидации"?

Автор не предлагает подхода потому, что его нет. Точнее говоря, он есть, но он совершенно не такой, каким ты его хочешь увидеть. И валидация ему совершенно не противоречит. Автор не пропагандирует exploratory testing, напротив, если бы кто-нибудь сказал, что exploratory testing круче всех, то автор статьи осудил бы его столь же решительно. Решение этого парадокса следует искать здесь: http://www.context-driven-testing.com/

[Green]

... слепую ярость...

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

Вроде там понятно написано:
Валидация - деятельность, нацеленная на попытки доказательства корректности программы.
Тестирование - исследование программы и донесение информации о тех или иных аспектах качества до лиц, принимающих решения.
Методами валидации не получится исследовать систему. Валидация != тестирование, но это и не взаимоисключающие вещи и сравнивать их как минимум бестолково.

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



Автор (и Вы за ним) проводит противопоставление двух понятий: валидация и тестирование. Основанием для этого является заявление о том, что набор действий, скрывающихся за этими терминами - служат разным целям.

Моя же позиция заключается в том, что тестирование и валидация - это одно и тоже. Различие заключается в том, какие цели ставятся перед набором действий в рамках тестирования=валидации. Если целью является подтверждение работоспособности программы - то это не верная цель (это не есть тестирование=валидация вообще), если выявить слабые места и дефекты программы - то это правильная цель. Об этом я не раз писал на страницах этого форума и упоминал в своих докладах.

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

Так вот действия, которые предпринимает разработчик ни есть ни валидация, ни тестирование. А действия тестировщика вы можете назвать и валидацией, и тестированием. Это уже кому как нравится.

По поводу "что такого делает автор" я уже давал ссылку, далее можно копать блоги Канера, Баха, их книжку Lessons Learned in Software Testing (только на английском). По теме risk-based testing есть книжка Pragmatic Software testing от Рекса Блэка. Правда, все это на английском языке.

Первую почитывал (даже в оригинале ) ... лет 6-7 назад. Видимо, забыл уже.
К тому же, отсылка к чужому мнению не есть изложение собственных представлений.