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

[Alfa]

Посмотрел и внимательно поизучал материалы по Context-Driven Testing:
* http://www.context-driven-testing.com/
* http://www.satisfice.com/kaner/?p=45
* http://www.io.com/~w...our_schools.pdf

И остался для меня загадкой один пункт. В чем специфика Context-Driven подхода в тестировании.
Приведу пример из кулинарии.
1. The value of any practice depends on its context.
Рецепт хорош в зависимости от наличия ингредиентов.
2. There are good practices in context, but there are no best practices.
Есть хорошие рецепты, но нет идеальных, т.к. не всегда можно приготовить то, что хочется.
3. People, working together, are the most important part of any project's context.
Кулинар — все, рецепты — ничто.
4. Projects unfold over time in ways that are often not predictable.
Неожиданности случаются, бывает подгорит.
5. The product is a solution. If the problem isn't solved, the product doesn't work.
Если человек не наелся, то надо еще готовить, проблема не решена.
6. Good software testing is a challenging intellectual process.
Ну тут явно упоминается тестирование. Но никто не мешается сказать «Good cooking …».
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
Снова про тестирование, но вместо test пожно поставить любое слово, например «cook».

Получается, что в семи принципах (http://www.context-driven-testing.com/) напрямую к тестированию относится два. Но в них слово test легко заменяется на любое другое без потери смысла, после чего сайт можно переименовать в www.context-driven-anything.com. Из статьи Канера понятней не становится.

Вот и встал вопрос адептам Context-Driven Testing (которые тут водятся!). В чем же особенность этого подхода именно в тестировании? Что в тестировании такого, что что делает контекстый подход отличающимся от его аналогов в других областях (пример про кулинарию)?

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

[barancev]

Истинная правда. Нет специфики.

[Clauster]

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

[Alfa]

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

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

[rlabs]

А по моему если они такие универсальные, то как раз наоборот:

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

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

[Clauster]

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

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

ОК, тогда приведите пример чего-то, где выделяется что-то специфичное для тестирования. Просто чтобы понять какими категориями вы мыслите. С другой стороны, тестирование оно ведь не только для ПО. Как вы например будете тестировать 18-летний односолодовый скотч? А водку?

[dlg99]

Вот и встал вопрос адептам Context-Driven Testing (которые тут водятся!). В чем же особенность этого подхода именно в тестировании? Что в тестировании такого, что что делает контекстый подход отличающимся от его аналогов в других областях (пример про кулинарию)?

Это просто отголосок принципа "каждому проекту - свою методологию".

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

На интервью же регулярно приходят(приходили) тестировщики с подходом "деньги в бидончике".
Они же, как правило, предпочитают наиболее тяжеловесные и бумагомарательные процессы. Аргументация при этом вся из области того же "бидончика" -
"А Канер писал...", "а на моей предыдущей работе делали так (месяц писали требования, а у вас документации - 3 страницы на виках)", "а почему у вас тест план не по стандарту хз311?", "а у нас Вася думал, а 10 $%$%$ кнопки жали"; и не волнует их что писал он это в 80м году, и не волнует почему там делали именно так, а здесь - иначе.

Домохозяйка интуитивно понимает, что в кастрюльку соль нужно "по вкусу" сыпать, а не 33 столовые ложки, как написано в книжке для армейских кашеваров. Так же понимает, на каком этапе нужно больше вниманию супчику уделить, а когда можно пойти газетку почитать.
А отдельные т.н. 'инженеры по тестированию' просто веруют в серебряную пулю в виде кучи спецификаций, использования стандарта Х или процесса РЮП или ЦММ, или в то, что механическое не вдумчивое тестирование приносит пользу.

Еще, почему то, все понимают, что случайно выхваченный из толпы человек не сможет приготовить обед уровня высококлассного ресторана даже по самым детальным инструкциям. В тестировании же встречаются товарищи, которые считают, что один "аналитик" на десяток-другой бездумных "кликальщиков" лучше 3х думающих инженеров.
И аутсорсят приготовление дорогого романтического ужина в макдональдс ;)

Я, лично, манифест контекстной школы воспринимаю только как призыв включать мозг ;)
С этой точки зрения - ага, нет разницы - кашку варим или тестируем.
Только почему то повара не бросаются манифесты писать типа "не кидайте ингредиенты в суп бездумно" ;)

[barancev]

* это скорее минус т.к. в них не выделяется ничего специфичного для тестирования, как для человеческой деятельности, и значит они не сильно полезней для применения в тестировании, чем в кулинарии, что немного грустно :(

Что же в этом плохого? В каждой деятельности эти принципы осбуждаются, потому что всегда находятся люди, которые пытаются слепо следовать рецептам. И если говорить о приготовлении пищи -- почитайте соответствующие ресурсы, там вы тоже найдёте постоянно встречающийся совет импровизировать, ориентироваться не на рецепт, а на вкус. Разумеется тестирование не является исключением. Но в какой-то степени, да, тестировщики чуть более консервативны в используемых подходах, методах, инструментах, чем, скажем, разработчики, архитекторы, дизайнеры. Поэтому и возникло это "движение протеста", новая школа, которая стремится сбросить шелуху стандартов, привычных техник, метрик, инструментов, и вернуться к основам, к сути тестирования. Да, конечно, для начинающего тестировщика (или кулинара) рецепты являются хорошим подспорьем в работе. Но главное -- вовремя освободиться от них, понять, когда они начинают мешать, а не помогать.

[saezar]

CDT применим реально там, где производство сосредоточено в какой то предметной области. Люди, работающие достаточное время, оказываются "в теме", и это оказывается важнее самой подробной спецификации. Команда из таких людей, мотивированная и сполченная, сделает продукт лучше и быстрее. Проучи этой же команде, до сих пор занимавшейся тестированием, сварить суп в ресторане, даже при наличии подробнейших рецептов, он будет хуже чем у команды посредственных поваров по той простой причине, что повара - в теме, а тестировщики - нет. Основная фишка CDT - "люди, которые в теме". (Исключительно мое ИМХО)

[Green]

Коллеги,

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

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

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

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

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

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

[Green]

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

Леша,
это ты, пожалуй, загнул.


Согласно тому же Канеру CDT не является методологией и применим в рамках любого подхода тестирования. Так что о "новой школе" речь уж точно не идет. Да и против привычных техник он так же не выступает.

[barancev]

Другими словами, 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."

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

[barancev]

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

Леша,
это ты, пожалуй, загнул.


Согласно тому же Канеру CDT не является методологией и применим в рамках любого подхода тестирования. Так что о "новой школе" речь уж точно не идет. Да и против привычных техник он так же не выступает.

Именно поэтому они (это не я придумал так называть, см. третью ссылку в оригинальном посте) и называют это ШКОЛОЙ (в философском понимании), а не методологией или подходом.

[dlg99]

Основная фишка CDT - "люди, которые в теме". (Исключительно мое ИМХО)

случайный факт ;)
Джеймс Бах, пропагандирующий CDT, - консалтер.
У него много мелких разнородных проектов, не всегда он детально "в теме" предметной области.
Тем не менее, он утверждал, что пользу (value) на проектах он начинает приносить через 15 минут после начала первого рабочего дня.

[Alfa]

ОК, тогда приведите пример чего-то, где выделяется что-то специфичное для тестирования. Просто чтобы понять какими категориями вы мыслите. С другой стороны, тестирование оно ведь не только для ПО. Как вы например будете тестировать 18-летний односолодовый скотч? А водку?

Например: техники дизайна тестов, тот же стандарт IEEE 829. В IEEE 829 описано как вести документацию для тестирования, а не просто «советы как лучше документировать». Т.е. народ сидел и думал, как лучше документирвать именно в тестировании.
А тестировать скотч можно по разному. Но мне больше всего нравится функциональное тестирование черного ящика (как сюда подходит слово ящик :). Встать на сторону пользователи и знаете ли … тестировать :).

[Alfa]

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

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

Хорошо, что вы обратили на это внимание. Потому что здесь то же есть некая проблема. Проблема в том, что в CDT контекст воспринимается как некая данность не подлежащая изменению. И хотя в текстах по CDT найти упоминаний «сокровенности контекста» мне не удалось (может кто видел?), вопросу изменения контекста так же не уделено внимания. В некоторых случаях можно (и нужно) изменить контекст — иначе смерть.

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

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

[barancev]

Хорошо, что вы обратили на это внимание. Потому что здесь то же есть некая проблема. Проблема в том, что в CDT контекст воспринимается как некая данность не подлежащая изменению. И хотя в текстах по CDT найти упоминаний «сокровенности контекста» мне не удалось (может кто видел?), вопросу изменения контекста так же не уделено внимания. В некоторых случаях можно (и нужно) изменить контекст — иначе смерть.

4. Projects unfold over time in ways that are often not predictable.

[barancev]

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

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

7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

[Clauster]

ОК, тогда приведите пример чего-то, где выделяется что-то специфичное для тестирования. Просто чтобы понять какими категориями вы мыслите. С другой стороны, тестирование оно ведь не только для ПО. Как вы например будете тестировать 18-летний односолодовый скотч? А водку?

Например: техники дизайна тестов, тот же стандарт IEEE 829. В IEEE 829 описано как вести документацию для тестирования, а не просто «советы как лучше документировать». Т.е. народ сидел и думал, как лучше документирвать именно в тестировании.
А тестировать скотч можно по разному. Но мне больше всего нравится функциональное тестирование черного ящика (как сюда подходит слово ящик :). Встать на сторону пользователи и знаете ли … тестировать :).

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

Смотрим книжку Lessons Learned in Software Testing (A Context-Driven Approach):
Lesson 145 - Use the IEEE Standard 829 for test documentation
Lesson 146 - Don't use the IEEE Standard 829
:)

[Clauster]

А тестировать скотч можно по разному. Но мне больше всего нравится функциональное тестирование черного ящика (как сюда подходит слово ящик :). Встать на сторону пользователи и знаете ли … тестировать :).

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