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

[barancev]

Ещё один прелюбопынейший вопрос из экзмена ISTQB. Предлагаю высказываться :)

[Boltick]

Ещё один прелюбопынейший вопрос из экзмена ISTQB. Предлагаю высказываться :)

Нравится ответ D :) Сходу выбрал его.
Правда в этом случае цель тестирования - поиск дефектов, с чем я не совсем согласен :)

Перечитал ответы еще раз и подумал, а чем вариант B плох? Хм... Подвис в раздумьях...

[rlabs]

Перечитал ответы еще раз и подумал, а чем вариант B плох? Хм... Подвис в раздумьях...

Тем, что тестирование и выпуск успешного продукта не связаны никак.

[Natalya Rukol]

Религиозный провокационный вопрос :)
Ответила "С" как наиболее близкий к моей карте мира, хотя и
1) Уверена что по мнению stqb он не верен.
2) Мне самой он нравится только на уровне "из двух зол" (а точнее из четырёх :)).

[LeshaL]

Религиозный провокационный вопрос :)
Ответила "С" как наиболее близкий к моей карте мира, хотя и
1) Уверена что по мнению stqb он не верен.
2) Мне самой он нравится только на уровне "из двух зол" (а точнее из четырёх :)).

По поводу того, что тестирование повышает качество мне понравилось выступление одного индуса, перевод этого выступления опубликовал в своем блоге Алексей Лупан:
http://testitquickly...-neastimparati/

[Natalya Rukol]

Индус молодец! :) Мне очень понравилось выступление, несмотря на акцент.
Но есть пара "но". Все мы знаем притчу о том, как путник шёл по дороге, и увидел трёх людей, роющх яму. И спросил: "Что Вы делаете?"
Первый ответил: "Мне сказали рыть отсюда и досюда, рою эту часть рва".
Второй ответил: "Я работаю за две гривны в неделю".
А третий сказал: "Я строю величайший храм, который простоит века".
Ведь правы все, не так ли? Но кто из этих троих больше мотивирован? Кто качественнее решает задачи? Кому из них работа доставляет удовольствие? Кто самореализуется, копая ров?
Так и в тестировании.
Некоему тестеру, "глупому лягушонку, недостойному сыну шакала Табаки, пылинке с хвоста слона Хатхи" дали задачу - пройти тестовый сценарий. Кто-то будет "проходить сценарий", ни взгляда по сторонам, ни капли инициативы. Кто-то более продвинутый озадачится вопросом "зачем проходить сценарий?" и будет это делать для того, чтобы оценить статус продукта, даже если сценарий не ахти, тестер пройдёт его как надо и дополнит проверками. А кто-то спросит "а зачем оценивать статус продукта?", и поймёт, что менеджер проекта принимает решение, базируясь на качестве/времени/финансах. Оценит, что нужно для повышения качества с его стороны (чёткий статус, понятные дефекты, грамотные аргументы и т.д.) И таким образом сможет поднять качество продукта!
Кто-нибудь из Вас когда-нибудь ходил к врачу-диагносту с целью узнать что за болезнь и ничего не делать? Врядли. Нам это нужно чтобы лечиться. Лечит ли нас диагност? Нет. Но без него вылечиться нельзя. И диагност будет по-разному работать в разной ситуации. Если на вопрос "зачем он диагностирует пациента?" он ответит: "для того, чтобы его можно было вылечить", результаты его работы будут лучше, он будет изначально адаптирован для решения проблемы, а не просто нахождения.
В общем, вопрос философский, и от ответа на него мало что меняется - просто мы смотрим на более высокоуровневую задачу, когда говорим о качестве, и на более низкоуровневую. когда говорим "оценить состояние продукта".

[rlabs]

А кто-то спросит "а зачем оценивать статус продукта?", и поймёт, что менеджер проекта принимает решение, базируясь на качестве/времени/финансах. Оценит, что нужно для повышения качества с его стороны (чёткий статус, понятные дефекты, грамотные аргументы и т.д.) И таким образом сможет поднять качество продукта!

Замечательное выступление!

А как оно связано с вариантом "Testing increases the quality of a software system by avoiding defects in the system under test"?

[astenix]

Лечит ли нас диагност? Нет. Но без него вылечиться нельзя.

Хочу уточнить environment, в котором варится упомянутый индус.

На территории Индии Прадиип Саундарараян является старшим, официальным брамином школы context-driven-testing, спецкурс Джеймса Баха, философская ветвь agile-development. Для протокола: мне эта школа очень интересна и близка.

История с "тестированием организма" написана Прадиипом специально для пропаганды целей адептов см, выше чего именно :) Наглая, неприкрытая пропаганда.

В их учении, в частности, говорится, что для проекта "написанный код ЦЕНЕЕ написанной документации". Это означает только то, что документация ТОЖЕ ценна, но код первичнее, а не "нафиг документацию!".

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

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

Очень вероятно, что клиент спросит: "А до сих пор что делали?"

Ему ответят: "Готовились. Вот документация, по которой мы начнем, собственно, тестировать, и вот документальное подтверждение того, что все это время мы эту документацию готовили. Будете ее читать?"

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

Поэтому "код ЦЕННЕЕ документации" :)

Подробнее об этом указанный Прадиип накалякал целый пост (относительно свежий). Он утверждает, что за весьма активной деятельностью ("подготовка к тестированию") можно спрятать большой кусок ничегополезногонеделанья (указаны цифры). И что полезнее, как глаголит его школа, сразу браться за тестирование, изучать софт ВО ВРЕМЯ тестирования, ну и тд.

Вот против бесполезнодеятельности и выступают адепты школы context-driven-testing, спецкурс Джеймса Баха, философская ветвь agile-development, говоря о том, что "тестирование не повышает качество". Дополним: "оно лишь снабжает информацией манагера проекта".

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

И если я правильно понял подтекст Прадиипа, даже лечение не делает организм сильнее. Оно его просто приводит от состояния "-10" (уровень болезни) до состояния "0" - нормальное состояние организма. 36,5 С, гормональный рост, достижения на личном фронте, все дела.

Если я действительно правильно понял, то пресловутая история про "тестирование организма" возникла потому, что бОльшая часть окружения Прадипа как раз НЕ доросло до понимания: "А кто-то спросит "а зачем оценивать статус продукта?", и поймёт, что менеджер проекта принимает решение, базируясь на качестве/времени/финансах. Оценит, что нужно для повышения качества с его стороны (чёткий статус, понятные дефекты, грамотные аргументы и т.д.) И таким образом сможет поднять качество продукта!", и ведут себя в отношении тестирования как ссущие дети - "Мы должны делать диагностику просто потому, что это сделает наш организм сильнее, качественнее", где-то по пути потеряв нить между "Что именно диагностика делает, а что - не делает" и "Вот он, наш качественный код и работающий софт!". Вывод мне самому слегка странен, но Пуруша их поймет, как и какие у них дела творятся. Страна далекая, очень своеобразная.

Резюме:

* Утверждение "диагностика - не лечит" - правильное. Просто оно усеченное, и полностью звучит так: ""диагностика - не лечит, она помогает лечению". В усеченном виде она, действительно, порождает разногласия и возражения, особенно в разных контекстах. Вывод: не надо ее усекать.

* Если предположить, что идеи "менеджер проекта принимает решение, базируясь на чёткий статус, понятные дефекты, грамотные аргументы и т.д., и таким образом сможет поднять качество продукта!" не в ходу в окружении Прадиипа - утверждение "диагностика - не лечит", опять же, правильное. Но усеченное.

[LeshaL]

...

Ух!
Предлагаю не отвлекаться от темы, вопрос "что ценнее код или документация", вроде бы тут не причем.

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

ЗЫ: кстати, Алексей, а почему ваш блог перестал транслироваться на software-testing.ru или это у меня чего-то глючит?

[Natalya Rukol]

Замечательное выступление!

А как оно связано с вариантом "Testing increases the quality of a software system by avoiding defects in the system under test"?

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

[Alfa]

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

Как это не нужно? А как мы узнаем, что можно выпускать продукт?
То что Вы описали достаточно хорошо соотвествует случаю прямо перед выпуском продукта — баги уже не находятся (а значит и не исправляются), требования не меняются, продукт не улучшается.
Т.е. это будет влиять на решение о выпуске.

[rlabs]

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

Что-то все в кучу собрано. "Если никто не будет работать на работе - они нафиг не нужны". С этим, действительно, сложно поспорить.

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

[Natalya Rukol]

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

Как это не нужно? А как мы узнаем, что можно выпускать продукт?
То что Вы описали достаточно хорошо соотвествует случаю прямо перед выпуском продукта — баги уже не находятся (а значит и не исправляются), требования не меняются, продукт не улучшается.
Т.е. это будет влиять на решение о выпуске.

Согласна. Но тестируют же не только перед выпуском?

Что-то все в кучу собрано. "Если никто не будет работать на работе - они нафиг не нужны". С этим, действительно, сложно поспорить.

Я сказала, что тестирование не нужно если в результате его действий не будет улучшаться продукт, фикситься баги, и т.д. Есть разница ;) А ещё на тесты по логике ссылаетесь :)

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

Спасибо за позитив, 30 из 30 :) Тем не менее, определение - не тест на логику. C и D, ИМХО, друг другу не противоречат. У любой задачи всегда есть 2 неотъемлемых атрибута - процесс и результат. D может быть процессом достижения С, а С может быть результатом D. Но процесс поиска дефектов (тем более без упоминания о выявлении работоспособного функционала) не обязательно сможет повысить качество, даже не факт что сможет помочь принять правильное решение о релизе.
Я бы сформулировала "Testing allows to release products with desired quality through validation and verification of the product".

[rlabs]

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

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

Спасибо за позитив, 30 из 30 :) Тем не менее, определение - не тест на логику. C и D, ИМХО, друг другу не противоречат. У любой задачи всегда есть 2 неотъемлемых атрибута - процесс и результат. D может быть процессом достижения С, а С может быть результатом D. Но процесс поиска дефектов (тем более без упоминания о выявлении работоспособного функционала) не обязательно сможет повысить качество, даже не факт что сможет помочь принять правильное решение о релизе.

В варианте D утверждается, что верификация и валидация позволяет обнаружить проблемы в системе. Логично, никаких противоречий?
В варианте C, простите за мой английский, утверждается, что тестирование позволяет избежать дефектов в продукте, увеличивая тем самым его качество. Выглядит не очень правдоподобно. Наиболее близкая по смыслу методика, действительно позволяющая избежать некоторых проблем и повысить качество - TDD, но это не тестирование.

Я бы сформулировала "Testing allows to release products with desired quality through validation and verification of the product".

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

[Alfa]

Согласна. Но тестируют же не только перед выпуском?

That does not matter. Представим ситуацию, что тестирование есть, но все отчеты об ошибках и прочее читает только менеджер проекта. Нужно оно в таком виде? Мой ответ — да, оно помогает принять решение о выпуске.

Я сказала, что тестирование не нужно если в результате его действий не будет улучшаться продукт, фикситься баги, и т.д. Есть разница ;)

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

[barancev]

ЗЫ: кстати, Алексей, а почему ваш блог перестал транслироваться на software-testing.ru или это у меня чего-то глючит?

Это вопрос скорее ко мне. Действительно перестал. Глючит Yahoo Pipes, причём никаких сообщений об ошибках нет, но и в вывод не попадает. Очень странно. Разбираюсь.

[astenix]

блог > транслироваться > software-testing.ru

действительно, не транслируется...

Сейчас кое-куда пишу баг-репорт с заголовком "Ааааааа! Ничего не работает!"

[novak]

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

И, кстати, в плане двух зол, если с первым вроде всё понятно, может кто-нибудь объяснить, в чём же зло утверждения D?

[Natalya Rukol]

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

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

И, кстати, в плане двух зол, если с первым вроде всё понятно, может кто-нибудь объяснить, в чём же зло утверждения D?

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

Очень много разных определений тестирования, почти все противоречат друг другу. IEEE сводит тестирование к верификации, ISTQB - к валидации + верификации. ИНОГДА этого достаточно. Иногда - нет. Поэтому я не могу назвать определение D неверным, но оно как минимум недостаточное.

Rex Black, "Critical Testing Processes'
"Testing is a process that assesses the quality of a system, providing services and information products that help the organization manage the risks to system quality."
Похоже на D, но здесь хотя бы добавлен критерий helps тестирование или не helps. Результаты тестирования могут быть такими, что они вообще ничему не help, зато пункту D удовлетворяют - этим он мне и не нравится.

Rick Craig, Stefan Jaskiel (Systematic Software Testing):
"Testing is a cocurrent lifecycle process of engineering, using and maintaining testware in order to measure and improve the quality of the software being tested"Аналог С

Boris Beizer (3rd testing level):
"The purpose of testing is not to prove anything, but to reduce the perceived risk of not working to an acceptable value"
А это, ИМХО, наиболее корректный ответ. Мы обеспечиваем требуемое качество. Мы нивелируем риск его недостижения до определённой величины. Мы предоставляем информацию о состоянии продукта. И для достижения этого, мы выполняем то, что описано в пункте D. И зачастую - не только то, что там описано :)

Мой вывод: дискуссия не просто философская, она скорее религиозная. Правильный ответ по мнению ISTQB мы все знаем - это D. Личный attitude каждого - это личный attitude каждого

[Alfa]

Религиозный провокационный вопрос :)
Ответила "С" как наиболее близкий к моей карте мира, хотя и
1) Уверена что по мнению stqb он не верен.
2) Мне самой он нравится только на уровне "из двух зол" (а точнее из четырёх :)).

Предлагаю challenge. Возьмите программу listboxer и при помощи тестирования сделайте ей «increases the quality of a software system». А мы посмотрим и поучимся.