Вопросы подкорректировали, ещё раз спасибо за внимательность!

Спасибо за точность, формулировку вопроса исправим.

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

Спасибо :)

На этот паттерн система тоже реагирует. Плед, лосьон и сумка — это всего лишь один из примеров.

Да, именно после этой волны недовольства они начали помещать «нужные» купоны среди «ненужных», чтобы клиенты думали, что это случайность.

Спасибо, исправлено.

У коллеги с программой лояльности Амазона грустный, даже обидный опыт. Он регулярно покупает на сайте blu-ray диски, а Амазонка в благодарность периодически присылает ему купоны на бесплатную закачку mp3 музыки. А проблема в том, что, когда он проходит по присланной ссылке, чтобы воспользоваться щедрым предложением, его ждет облом — сам же Амазон запрещает скачивание с белорусских айпишников, поскольку справедливо считает, что страна не гарантирует защиту прав интеллектуальной собственности.
И да, коллега писал в службу поддержки, но до сих пор получает свой бонус, который так и не может реализовать.

1. В архитектуре системы предусмотрена расширяемость, и при необходимости ее можно в течение нескольких дней интегрировать с любым инструментом. Git довольно популярен — думаю, скоро добавим.
2. Хранение тестов в системе может быль любым, как на файловом сервере, так и в репозитории.
3. Так и происходит, пользователь может сам задавать правила, откуда Octopus будет эти тесты забирать, и куда складывать результаты.
В нашей компании тестировщики используют разные среды автоматизации тестов (Test Automation Frameworks), хранят тесты на разных серверах, поэтому реализована гибкость в выборе пути тестов. Т.е. для работы системы тесты не обязаны находится в одном конкретном месте.

Мы не противопоставляем Осьминога и Continuous Integration. Это полноценная и законченная реализация CI, основанная, дополненная и используемая в личном опыте.

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

И как разруливать (автоматически) ситуации, когда один баг приводит к падению нескольких тестов?

Универсальный ответ не могу дать, но я вижу 3 основных сценария.
1. Некоторые test automation framework имеют свои механизмы, например, возможность задавать такое поведение выполнения тестов, что при фейле одного из последовательности тестов остальные не будут выполняться (кажется, это называется «continue after fail»).

2. При написании тестов и их проектировании в последовательности, можно самим ставить защиту от подобных ситуаций на уровне тестов (тот же «continue after fail» только на уровне самого тестового кода).

3. Никак.
Можно пытаться разрабатывать хитроумные алгоритмы, но, как правило, все не предугадаешь, и порой только опыт, приобретенный в ходе наблюдения за поведением системы может помочь в создании универсального алгоритма, пригодного для подобных поведений в Вашем конкретном окружении. Т.е. иногда можно не заморачиваться, а строить более ли менее простые, хорошо работающие механизмы…

Спасибо, Леша :)

а зачем баги автоматом запихивать в дефект-трэкер? Уж коли брать пример с Data Driven тестированием — то зачем вообще такие баги записывать в трэкер?

В некоторых компаниях каждый элемент Дата Дривен теста очень важен. В некоторых — вообще неважен.
В принципе, каждая из функций — autosubmit и autoclose — включается в один клик. Это дополнительная возможность, которой в некоторых случаях можно и не пользоваться, а в некоторых она очень эффективна, т.е. вы можете сказать «итак, после выполнения именно этого Data Driven теста записывать каждый сфэйлившийся тест как отдельный баг или же можно просто сказать — создавать один баг на весь DataDriven»… А можно сказать, чтобы баги не создавались, а создавался просто отчет (в случае, когда вы, например, не уверены в корректности написанного теста и не хотите, чтобы к Вам были претензии по поводу чрезмерного флуда в Баг трекинг системе:).

… мне еще есть куда стремиться :)

Спасибо, чудный скриптик. С удовольствием смотрела, как он убивал строчку за строчкой :)

Это зависит во многом от того, какие проекты составляют портфель компании — преимущественно долгосрочные или краткосрочные.
Уже после того, как анкета была запущена и ответило приличное количество людей, созрели пару уточняющих и полезных вопросов — о масштабах проектов и способе параметризации выполнения автотестов (через UI, config-файлы и т.п.)
Хорошая мысля, как известно, приходит пасля :)

Нет клиентов — нет проблем. :)

При составлении вариантов ответа я старалась, чтобы список не превышал 4-6 наименований и включал в себя свободных и коммерческих «представителей». Наиболее часто встречающиеся интсрументы отражены (вероятно, не все), и есть поле Другое, где можно вписать. Если по результатам Mercurial окажется популярным, то при интерпретации результатов я его выведу из Другое отдельной категорией.

Да, вопрос сознательно так сформулирован. Сочетание «автоматизированное тестирование» несет в себе элемент условности, потому что зачастую ряд перечисленных действий тестировщик выполняет вручную.
По сути, цель этого вопроса — выявить уровень и глубину автоматизации.