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

[Clauster]

Самый близкий синоним, видимо, пропитаться. Думаю, налицо разность школ тестирования. Ваши лекала не совпадают с моими. Или вы тяготеете к context-driven school?

Вам правда достаточно информации чтобы сделать такие выводы?
Странно, потому что я с Вашими высказываниями почти согласна, и пока что суть дискуссии, как мне кажется, упирается не больше чем в отсутствие общего словаря :) К context-driven тяготею, хотя и считаю деление школ надуманным :)

Да, общее впечатление, что вы много работали с "тяжелыми" процессами.
Когда я ещё не знал про CDTS, очень трудно было ломать стереотипы (не свои) и, как оказалось, я изобрел немало велосипедов. Может, и надуманно, но чрезвычайно полезно.

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

Что значит правильная или неправильная? :) Будете ссылаться на "всех этих западных гуру и полугуру"? :))

Это значит что эта цель - миф. Ссылка на Рекса Блэка и Б.Бейзера потянет?

Как правило, цель ad hoc - быстро обнаружить критические проблемы. Ещё раз, ключевое слово быстро.

У меня сценарии приоритезированы почти полностью в соответствие с критериями, указанными по ссылке. И сессии тоже разноуровневые и тоже соответствуют тем же критериям. И при необходимости срочно проверить фиксы могут использоваться подходящие сценарии. При чём тут ad hoc, если в Вашем посте речь идёт о приоритетах?

Наличие у вас сценариев уже говорит о том, что это не ET и не ad hoc (или вы просто так про них написали?). При чем тут ad hoc. Ещё раз: цель - быстро выявить критические проблемы. У нас нет сценариев, кейсов или чего-то там ещё. Зато мы знаем, например, что пофиксили в последнем билде, какие фичи выпускаются в текущем релизе ну и много чего ещё. Я, грубо говоря, беру методику из приведенного выше поста и провожу ad hoc тестирование. Когда мне ставят цель поиск багов, я, в той же ситуации, имея те же знания, уже буду действовать совсем по другой методике (например, открою vista guidelines и буду шерстить интерфейс на капитализацию, горячие клавиши и т.д.). Только кому от этого будет лучше?

Вы совершенно справедливо можете называть то, что описали хаотическим тестированием и я даже с вами соглашусь (т.к. у него нет цели), но не называйте это ad hoc.

ХАОТИ'ЧЕСКИЙ - Лишенный порядка, последовательности, стройности, совершенно беспорядочный. Про отсутствие цели ничего не написано. Вы можете дать грамотному тестеру задачу "срочно проверить фикс", и он, руководствуясь знанием продукта, интуицией и принципами приоритезации тестов, изложенных в Вашем блоге, оперативно найдёт баги. Это будет беспорядочно и быстро :) Вы это называете ad hoc?

Это уже не будет беспорядочно, правда?

[Clauster]

ХАОТИ'ЧЕСКИЙ[/url] - Лишенный порядка, последовательности, стройности, совершенно беспорядочный. Про отсутствие цели ничего не написано.

Давайте проведем хаотическое целенаправленное тестирование. Это даже хуже чем наиболее оптимальный.

[Natalya Rukol]

rlabs, мы обсуждаем не что писать на флаге и не парное тестирование :)

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

Ничего не поняла, особые трудности вызвал выделенный участок :) Эксплоративное = Exploratory. Нет?

Да, общее впечатление, что вы много работали с "тяжелыми" процессами.

Я последнее время "подсела" на масштабные проекты, где есть своя специфика - не более того.

Когда я ещё не знал про CDTS, очень трудно было ломать стереотипы (не свои) и, как оказалось, я изобрел немало велосипедов. Может, и надуманно, но чрезвычайно полезно.

Свои ломать полезнее :)))

Это значит что эта цель - миф. Ссылка на Рекса Блэка и Б.Бейзера потянет?

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

Наличие у вас сценариев уже говорит о том, что это не ET и не ad hoc (или вы просто так про них написали?). При чем тут ad hoc. Ещё раз: цель - быстро выявить критические проблемы. У нас нет сценариев, кейсов или чего-то там ещё. Зато мы знаем, например, что пофиксили в последнем билде, какие фичи выпускаются в текущем релизе ну и много чего ещё. Я, грубо говоря, беру методику из приведенного выше поста и провожу ad hoc тестирование. Когда мне ставят цель поиск багов, я, в той же ситуации, имея те же знания, уже буду действовать совсем по другой методике (например, открою vista guidelines и буду шерстить интерфейс на капитализацию, горячие клавиши и т.д.). Только кому от этого будет лучше?

Я согласна с тем, что ad hoc может использоваться не только для поиска багов, но и для совсем другой, более зрелой цели - поиск критичных багов!! :)

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

Это уже не будет беспорядочно, правда?

Откуда Вы знаете, порядочно это будет или нет? :) Какой это уровень по Бейзеру - первый или второй? (у Бейзера в оригинале, кстати, это не "стадии становления тестировщика", а фазы тестирования).

ХАОТИ'ЧЕСКИЙ - Лишенный порядка, последовательности, стройности, совершенно беспорядочный. Про отсутствие цели ничего не написано.

Давайте проведем хаотическое целенаправленное тестирование. Это даже хуже чем наиболее оптимальный.

Почему? Представьте себе человека, который потерял свой паспорт и опаздывает на самолёт. Он носится по квартире в трусах в цветочек и роется в своих ящиках. У него есть цель? Да. А процесс поиска хаотичен? Да :)

Clauster, у меня пара вопросов:
1) К какой фазе тестирования по Бейзеру относится ad hoc?
2) Можно ли использовать ТОЛЬКО ad hoc? Если нет - то почему?

[Clauster]

Clauster, у меня пара вопросов:
1) К какой фазе тестирования по Бейзеру относится ad hoc?
2) Можно ли использовать ТОЛЬКО ad hoc? Если нет - то почему?

А у меня только один: Вы практикуете ET?

[LeshaL]

Такой интерпретацией Вы сводите термин ad hoc к абсурду, потому что каждый случай в некотором роде данный.

В моем понятии ad hoc, это то тестирование, которое заранее не было (да и не могло быть) спланированно. Например, когда приходит коллега-программист и просит проверить его приватный билд или когда по ходу работ выясняется, что есть проблемы в какой-то области в которой не планировалось тестирование (например third-party библиотека) и теперь надо что-то там потестировать. И тот случай, который в Session-Based тестировании проходит под вывеской on opportunity (случайно заметили проблему в том месте, которое в данный момент не есть наша миссия).

Посему, я не вижу почему вы считаете, что в такой интерпретации ad hoc - абсурден. И мне не понятно, почему ad hoc значит что-то, для чего нет тест кейсов (в смысле задизайненых заранее тестов).

Ad hoc - тестирование посвященное конкретному "проишествию", которое случилось внезапно.
Почуствуйте разницу: если к вам прибежал разработчик с криками, что он сделал крутую оптимизацию и просит запустить ваши замечательные тестовые скрипты для оценки перформанса на его приватном билде - это будет ad hoc тестированием. Если же перед разработчиком заранее была поставлена такая задача и он ее выполнил и залил изменения в репозиторий, а вы померили перформанс на следующем регулярном билде - то это не ad hoc. Заметьте, что вы сделаете одни и те же действия.

[Boltick]

Представьте себе человека, который потерял свой паспорт и опаздывает на самолёт. Он носится по квартире в трусах в цветочек и роется в своих ящиках. У него есть цель? Да. А процесс поиска хаотичен? Да :)

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

[Alfa]

Такой интерпретацией Вы сводите термин ad hoc к абсурду, потому что каждый случай в некотором роде данный.

В моем понятии ad hoc, это то тестирование, которое заранее не было (да и не могло быть) спланированно. Например, когда приходит коллега-программист и просит проверить его приватный билд или когда по ходу работ выясняется, что есть проблемы в какой-то области в которой не планировалось тестирование (например third-party библиотека) и теперь надо что-то там потестировать. И тот случай, который в Session-Based тестировании проходит под вывеской on opportunity (случайно заметили проблему в том месте, которое в данный момент не есть наша миссия).

Посему, я не вижу почему вы считаете, что в такой интерпретации ad hoc - абсурден. И мне не понятно, почему ad hoc значит что-то, для чего нет тест кейсов (в смысле задизайненых заранее тестов).

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

[LeshaL]

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

Извините, если вам так показалось. Я не хотел относить ваши реплики к новому тексту.

Значит с последней моей интерпретацией вы согласны?

[Clauster]

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

Извините, если вам так показалось. Я не хотел относить ваши реплики к новому тексту.

Значит с последней моей интерпретацией вы согласны?

Не знаю, как Alfa, а я, после таких разъяснений, пожалуй, соглашусь, учитывая, что ad hoc с латыни дословно переводится как "для этого, к этому (случаю)".

[innovator]

А процесс поиска хаотичен? Да :)

Несочитаемые слова - процесс и хаотичный. http://slovari.yande...4/us3104207.htm
Тестирование принято называть "процессом", поэтому та часть работы, которая "хаотична" и есть тот самый бардак, о котором уже здесь упоминали.
Может быть и возникает чувство неуправляемости и произвольности ad hoc и ET, но все же это иллюзия.

[Alfa]

Значит с последней моей интерпретацией вы согласны?

Да.

[Alfa]

А процесс поиска хаотичен? Да :)

Несочитаемые слова - процесс и хаотичный. http://slovari.yande...4/us3104207.htm
Тестирование принято называть "процессом", поэтому та часть работы, которая "хаотична" и есть тот самый бардак, о котором уже здесь упоминали.
Может быть и возникает чувство неуправляемости и произвольности ad hoc и ET, но все же это иллюзия.

В данном случае, ИМХО, лучше использовать другое определение

Процесс (от лат. processus — продвижение)
2) Совокупность последовательных действий для достижения какого-либо результата

Правда это не меняет того, что ответ, который на свой вопрос дала Наталья, неверен. Правильный ответ «Нет».

[Mila]

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

В более зрелых компаниях встречала другую интерпритацию ad hoc тестирования.
Самый простой пример: для графических компонент проводилось хаотичное кликание по произвольным координатам и ожидалось, когда все завалится.
Помимо графики есть еще медоборудование, мобильная связь, датчики движения, сканеры, распознаватели... Какой-то эталонный набор данных или тесткейзов может быть слишком узким или его очень долго создавать... И вот тогда можно на постоянной или временной основе проводить хаотичные тесты, особенно, если это все можно быстро реализовать. :)
Критерий везде успешности простой: справимся или нет + анализ логов на ошибки. Иногда возможно вывести и некие характеристики по результатам испытаний :)
Тест-кейзов действительно нет, вернее, они генерируются... и в принципе никогда не повторяются...

[rlabs]

В более зрелых компаниях встречала другую интерпритацию ad hoc тестирования.
Самый простой пример: для графических компонент проводилось хаотичное кликание по произвольным координатам и ожидалось, когда все завалится.

В более зрелых компаниях наверняка знают, что эта методика называется Fuzz testing (или monkey testing), и требует серьезной подготовки. И снова это не ad hoc.

[LeshaL]

Значит с последней моей интерпретацией вы согласны?

Да.

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

При этом следует отметить:
Наталья права в том, что
- "Не путайте Ad Hoc и Exploratory" (все-таки ET - это исследование и изучение нового, АН - в большинстве случаев, применение уже накопленых знаний при тестировании, в основном, при возникновении чрезвычайных ситуаций)

- и в том, что "использовать ТОЛЬКО ad hoc нельзя" - это "lack of management" (нехорошо когда тестирование построено по принципу "опять там что-то отвалилось надо бы посмотреть". Хотя в любом случае такие вещи будут возникать - надо просто быть готовым к этому и стараться свести нештатные ситуации к минимуму).

[Clauster]

Наталья права в том, что
- "Не путайте Ad Hoc и Exploratory" (все-таки ET - это исследование и изучение нового, АН - в большинстве случаев, применение уже накопленых знаний при тестировании, в основном, при возникновении чрезвычайных ситуаций)

- и в том, что "использовать ТОЛЬКО ad hoc нельзя" - это "lack of management" (нехорошо когда тестирование построено по принципу "опять там что-то отвалилось надо бы посмотреть". Хотя в любом случае такие вещи будут возникать - надо просто быть готовым к этому и стараться свести нештатные ситуации к минимуму).

С этим никто и не спорил. А вот с "lack of management" трудно согласиться. Скорее, даже наоборот, это очень высокий уровень менеджмента. Когда тестировщик сам менеджит свои процессы. В общем-то, это неотъемлемая часть ET.

[Natalya Rukol]

Clauster, у меня пара вопросов:
1) К какой фазе тестирования по Бейзеру относится ad hoc?
2) Можно ли использовать ТОЛЬКО ad hoc? Если нет - то почему?

А у меня только один: Вы практикуете ET?

Я уже об этом писала на предыдущей странице. Да, и много :) Но в структурированном виде.
А Вы ответите?

С этим никто и не спорил. А вот с "lack of management" трудно согласиться. Скорее, даже наоборот, это очень высокий уровень менеджмента. Когда тестировщик сам менеджит свои процессы. В общем-то, это неотъемлемая часть ET.

Не думаю, что мы сможем здесь в чём-то убедить друг друга, поэтому эту часть дискуссии предлагаю просто закрыть. Я не считаю менеджментом спихивание организационной части на сотрудников :) Пока у Вас их 5, это может работать, когда 50 - Вам не поможет никакая иерархия. Нанять 50 экспертов, конечно, выход (если повезёт) - но это будет бездарной тратой бюджета.

[DrVal]

А я вот поддержу Наталью и процитирую гуру:

Exploratory testing is also known as ad hoc testing. Unfortunately, ad hoc is too often
synonymous with sloppy and careless work.

Т.е. в понятие ad hoc testing обычно вкладывается смысл "несистематизированное".
ET - это методология, AH - ее отсутствие.

К незапланированным активностям команды тестирования это имеет слабое отношение.

Не знаю, как Alfa, а я, после таких разъяснений, пожалуй, соглашусь, учитывая, что ad hoc с латыни дословно переводится как "для этого, к этому (случаю)".

[DrVal]

Тут не хватает ключевого дополнения:

В общем-то, это неотъемлемая часть ET - при условии, что сотрудник обладает должной квалификацией и навыками.

С этим никто и не спорил. А вот с "lack of management" трудно согласиться. Скорее, даже наоборот, это очень высокий уровень менеджмента. Когда тестировщик сам менеджит свои процессы. В общем-то, это неотъемлемая часть ET.

[novak]

А я вот поддержу Наталью и процитирую гуру:

Exploratory testing is also known as ad hoc testing. Unfortunately, ad hoc is too often
synonymous with sloppy and careless work.

Т.е. в понятие ad hoc testing обычно вкладывается смысл "несистематизированное".
ET - это методология, AH - ее отсутствие.

Звучит, как будто вы поддерживаете Наталью этой цитатой. Однако Бах в ней говорит не о том, что ad hoc - это отсутствие систематизации. А просто объясняет, почему он предпочитает называть называть процесс "Exploratory testing" - у "ad hoc" как у слова просто плохая слава. Он говорит не про понятие "ad hoc testing", а про понятие "ad hoc".