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

[Clauster]

Вообще первая заметка в моем блоге как раз был перевод 7 принципов. Если кому тяжело дается, мой вольный перевод тут
http://bugsclock.blo...ext-driven.html

[Clauster]

...контекстно-ориентированного подхода...

ориентированный - имхо не самый удачный перевод. Driven это гонимый, ведомый. К тому же в русском языке слово контекст несет преимущественно гуманитарную нагрузку. В общем сложно перевести этот термин на русский, чтобы хорошо передался его смысл.

[Alfa]

Вы путаете теплое с мягким. Разве CDTS отвергает стандарт 829? Какие-то техники тестирования?

Я не говорю что отвергает.

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

Если CDT это философия тестирования то, покажите что там специфичного для тестирования. Пока я вижу только «context driven — это философия». Тут мы вернулись к первоначальному вопросу.

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

Это как раз понятно.
За ссылки спасибо, добуду — прочту.

[Alfa]

Не исключено что вы сами того не зная изпользуете context-driven подход

Не исключено. Но я, знаете ли, люблю людям мозг есть насчет процессов и их лучшения иногда :). Тут мы расходимся.
Когда смотрел Петтихорда с его четыремя школами, не смог определить где же я там. Там вообще по четкому делению школ целая дискуссия в блогах была, если надо могу ссылки дать.

[Clauster]

Если CDT это философия тестирования то, покажите что там специфичного для тестирования. Пока я вижу только «context driven — это философия». Тут мы вернулись к первоначальному вопросу.

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

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

Школ вроде больше чем 4. Петтихорд, кстати тоже один из отцов CDTS.

[Green]

Другими словами, context-driven testing - это очень просто. Прежде чем начать тестирование, следует спросить закзаичка о том, что он считает наиболее важным в релизе и скорректировать тест-план в зависимости от полученного ответа.

Сергей, читаем внимательно всё по вышеприведённым ссылкам :)

Это в точности соответствует подходу, который назван там context-aware: "... some people create standards, like IEEE Standard 829 for test documentation, because they think that it is useful to have a standard to lay out what is generally the right thing to do. This is not unusual, nor disreputable, but it is not context-driven. Standard 829 starts with a vision of good documentation and encourages the tester to modify what is created based on the needs of the stakeholders. Context-driven testing starts with the requirements of the stakeholders and the practical constraints and opportunities of the project. To the context-driven tester, the standard provides implementation-level suggestions rather than prescriptions."

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

Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP? Куда ж там тест-план делся?


Ребята,
вы иногда бываете такими наивными.

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

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

Но,
прошу обратить внимание. Я не говорю, что это плохо! Просто это не настолько хорошо или координально, как это пытаются преподнести.

[barancev]

Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP? Куда ж там тест-план делся?

Сергей, ведь уже кажется Clauster дал ответ на этот вопрос (правда, в отношении IEEE 829, но суть не меняется) -- если контекст подсказывает, что нужно работать по RUP и писать планы, а также ещё кучу документов -- значит так и надо делать.

Вопрос в другом -- а если нет такого внешнего ограничения, а есть совершенно иной контекст, что делать тогда? Переть как танк напролом, пытаясь подмять под RUP всё, что шевелится? Или таки действовать сообразно обстоятельствам?

Ребята,
вы иногда бываете такими наивными.

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

[Sapiens]

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

[barancev]

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

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

[Clauster]

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

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

Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP?

Это невозможно. Я думаю нельзя натянуть CDT на какую-то методологию, потому что методология это не контекст. Методология это то, что уже натянуто на контекст.

Нашли кого слушать! Консультантов, которые этим зарабатывают деньги.

Хм. А кого слушать? Вас что ли? :) Нет, действительно интересно, чье мнение может быть для вас авторитетно? Только чтобы это был не консультант и не придумавший свою школу\религию.

[Clauster]

все равно все пункты очень абстрагированы и в этом смысле я согласен с автором топика

Они и должны быть абстрагированы. Иначе их будет гораааааздо больше.

[Green]

Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP?

Это невозможно. Я думаю нельзя натянуть CDT на какую-то методологию, потому что методология это не контекст. Методология это то, что уже натянуто на контекст.

Теперь настала моя очередь "тыкать пальцем в книжку". В приводимых выше ссылках у Канера есть раздел, посвященный CDT для RUP и других методологий.

Нашли кого слушать! Консультантов, которые этим зарабатывают деньги.

Хм. А кого слушать? Вас что ли? :) Нет, действительно интересно, чье мнение может быть для вас авторитетно? Только чтобы это был не консультант и не придумавший свою школу\религию.

А хотя бы и меня.

[novak]

А CDT как раз призывает не только слушать, но и думать. И анализировать конкретную ситуацию, приходя к применению тех решений и инструментов, которые подходят.
Спецификой для тестирования, как ни странно, может стать неожиданность призыва подумать.

[Green]

Коллеги,

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

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

[novak]

Однако, в каком виде вы, ребята, представляете заказчику отчет о тестировании? В количестве протестированных функций? В % соотношении проверенного кода? В ощущениях? Или отчет тоже нужно отбросить (так же как и тест-план), как нечто устаревшее и не достойное высокого исскуства тестирования?

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

[Alfa]

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

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

Пока простой ответ Алексея Баранцева («нет специфики») мне наиболее понятен.

Школ вроде больше чем 4. Петтихорд, кстати тоже один из отцов CDTS.

Ага, это я напутал. Просто файл с презентацией Петтихорда называется «four_schools.pdf», вот и запало «4 школы». Хотя у него описано 5 школ, и кажется где-то я видел, что их еще больше.

[Alfa]

Они и должны быть абстрагированы. Иначе их будет гораааааздо больше.

Вот и мне хочется чтоб они были абстрагированы, но не до уровня вселенной, а только до тестирования.
Иначе получается «Бытие — бытийствует, а небытие — не бытийствует». Верно и местами полезно, но не в тестировании.

[Clauster]

Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP?

Это невозможно. Я думаю нельзя натянуть CDT на какую-то методологию, потому что методология это не контекст. Методология это то, что уже натянуто на контекст.

Теперь настала моя очередь "тыкать пальцем в книжку". В приводимых выше ссылках у Канера есть раздел, посвященный CDT для RUP и других методологий.

Тыкните конкретнее пожалуйста, интересно почитать. Может там наоборот, RUP в разрезе CDT?

[Clauster]

те, кто ратует за CDT - это прогрессивные ребята

Какой уж тут прогресс, всему этому хозяйству лет 10 не меньше.

[Clauster]

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

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

Вы же это и спрашивали? Это описано в книжке Lessons Learned in Software Testing (A Context-Driven Approach) Kaner, Bach, Pettichord. В электронном виде не встречал, в печатном на английском языке. Видел в блогах переводы некоторых "уроков".