Комментарии 10
До 31 августа 2011 г. вы можете бесплатно скачать промо-версию программы Octopus
До 31-го августа не все проснуться и разберутся, я думаю. Полезно иметь бесплатную версию всегда, чтобы людям было что посмотреть.
Молодцы! Хорошую работу сделали.
К сожалению посмотреть не начем, т.к. кроме SVN — все не моё.
Есть вопросы: а зачем баги автоматом запихивать в дефект-трэкер? Уж коли брать пример с Data Driven тестированием — то зачем вообще такие баги записывать в трэкер? И как разруливать (автоматически) ситуации, когда один баг приводит к падению нескольких тестов?
К сожалению посмотреть не начем, т.к. кроме SVN — все не моё.
Есть вопросы: а зачем баги автоматом запихивать в дефект-трэкер? Уж коли брать пример с Data Driven тестированием — то зачем вообще такие баги записывать в трэкер? И как разруливать (автоматически) ситуации, когда один баг приводит к падению нескольких тестов?
И как разруливать (автоматически) ситуации, когда один баг приводит к падению нескольких тестов?
Универсальный ответ не могу дать, но я вижу 3 основных сценария.
1. Некоторые test automation framework имеют свои механизмы, например, возможность задавать такое поведение выполнения тестов, что при фейле одного из последовательности тестов остальные не будут выполняться (кажется, это называется «continue after fail»).
2. При написании тестов и их проектировании в последовательности, можно самим ставить защиту от подобных ситуаций на уровне тестов (тот же «continue after fail» только на уровне самого тестового кода).
3. Никак.
Можно пытаться разрабатывать хитроумные алгоритмы, но, как правило, все не предугадаешь, и порой только опыт, приобретенный в ходе наблюдения за поведением системы может помочь в создании универсального алгоритма, пригодного для подобных поведений в Вашем конкретном окружении. Т.е. иногда можно не заморачиваться, а строить более ли менее простые, хорошо работающие механизмы…
Универсальный ответ не могу дать, но я вижу 3 основных сценария.
1. Некоторые test automation framework имеют свои механизмы, например, возможность задавать такое поведение выполнения тестов, что при фейле одного из последовательности тестов остальные не будут выполняться (кажется, это называется «continue after fail»).
2. При написании тестов и их проектировании в последовательности, можно самим ставить защиту от подобных ситуаций на уровне тестов (тот же «continue after fail» только на уровне самого тестового кода).
3. Никак.
Можно пытаться разрабатывать хитроумные алгоритмы, но, как правило, все не предугадаешь, и порой только опыт, приобретенный в ходе наблюдения за поведением системы может помочь в создании универсального алгоритма, пригодного для подобных поведений в Вашем конкретном окружении. Т.е. иногда можно не заморачиваться, а строить более ли менее простые, хорошо работающие механизмы…
Спасибо, Леша :)
а зачем баги автоматом запихивать в дефект-трэкер? Уж коли брать пример с Data Driven тестированием — то зачем вообще такие баги записывать в трэкер?
В некоторых компаниях каждый элемент Дата Дривен теста очень важен. В некоторых — вообще неважен.
В принципе, каждая из функций — autosubmit и autoclose — включается в один клик. Это дополнительная возможность, которой в некоторых случаях можно и не пользоваться, а в некоторых она очень эффективна, т.е. вы можете сказать «итак, после выполнения именно этого Data Driven теста записывать каждый сфэйлившийся тест как отдельный баг или же можно просто сказать — создавать один баг на весь DataDriven»… А можно сказать, чтобы баги не создавались, а создавался просто отчет (в случае, когда вы, например, не уверены в корректности написанного теста и не хотите, чтобы к Вам были претензии по поводу чрезмерного флуда в Баг трекинг системе:).
а зачем баги автоматом запихивать в дефект-трэкер? Уж коли брать пример с Data Driven тестированием — то зачем вообще такие баги записывать в трэкер?
В некоторых компаниях каждый элемент Дата Дривен теста очень важен. В некоторых — вообще неважен.
В принципе, каждая из функций — autosubmit и autoclose — включается в один клик. Это дополнительная возможность, которой в некоторых случаях можно и не пользоваться, а в некоторых она очень эффективна, т.е. вы можете сказать «итак, после выполнения именно этого Data Driven теста записывать каждый сфэйлившийся тест как отдельный баг или же можно просто сказать — создавать один баг на весь DataDriven»… А можно сказать, чтобы баги не создавались, а создавался просто отчет (в случае, когда вы, например, не уверены в корректности написанного теста и не хотите, чтобы к Вам были претензии по поводу чрезмерного флуда в Баг трекинг системе:).
Классная штука, молодцы.
Только автосабмит дефектов меня тоже смущает: как убедиться, что 5 пофейлившихся тестов = 5 разных багов, как избежать false-fail'ов? Что-то подсказывает, что даже если проблемы с такими некорректными ошибками будут редкими, их автозаведение всё равно не выгодно, т.к. отнимет лишнее время разработчиков, займёт время на анализ, подпортит статистику и т.д. А если ещё и посчитать ROI реализации этого функционала (думаю, времени вы немало потратили), то и тем более невыгодно.
Единственный механизм автосабмита, с которым я сталкивалась и который мне понравился — автозагрузка дампов с их проверкой на уникальность.
Только автосабмит дефектов меня тоже смущает: как убедиться, что 5 пофейлившихся тестов = 5 разных багов, как избежать false-fail'ов? Что-то подсказывает, что даже если проблемы с такими некорректными ошибками будут редкими, их автозаведение всё равно не выгодно, т.к. отнимет лишнее время разработчиков, займёт время на анализ, подпортит статистику и т.д. А если ещё и посчитать ROI реализации этого функционала (думаю, времени вы немало потратили), то и тем более невыгодно.
Единственный механизм автосабмита, с которым я сталкивалась и который мне понравился — автозагрузка дампов с их проверкой на уникальность.
Вы абсолютно правы, это неоднозначная штука. Но хорошо, когда есть такая возможность — создавать баги автоматически. К тому же, эту фичу можно не включать на ваши тесты. Все очень зависит от специфики процесса, тестов и т.д. В некоторых случаях автоматическая регистрация багов оказывается полезной и даже очень эффективной, а в других — абсолютно абсурдной! Но, так или иначе, когда тесты фейлят по вине самих же тестов, есть ответственное лицо, которое вынуждено эти тесты исправлять, потому как есть засабмиченный баг…
Не понятно в чём отличие от CI
Как на счет поддержки GIT?
Как на счет поддержки хранения конфигуарции тестов в репозитории? И автоматически брать пачку соответствующую билду?
Как на счет поддержки хранения конфигуарции тестов в репозитории? И автоматически брать пачку соответствующую билду?
1. В архитектуре системы предусмотрена расширяемость, и при необходимости ее можно в течение нескольких дней интегрировать с любым инструментом. Git довольно популярен — думаю, скоро добавим.
2. Хранение тестов в системе может быль любым, как на файловом сервере, так и в репозитории.
3. Так и происходит, пользователь может сам задавать правила, откуда Octopus будет эти тесты забирать, и куда складывать результаты.
В нашей компании тестировщики используют разные среды автоматизации тестов (Test Automation Frameworks), хранят тесты на разных серверах, поэтому реализована гибкость в выборе пути тестов. Т.е. для работы системы тесты не обязаны находится в одном конкретном месте.
2. Хранение тестов в системе может быль любым, как на файловом сервере, так и в репозитории.
3. Так и происходит, пользователь может сам задавать правила, откуда Octopus будет эти тесты забирать, и куда складывать результаты.
В нашей компании тестировщики используют разные среды автоматизации тестов (Test Automation Frameworks), хранят тесты на разных серверах, поэтому реализована гибкость в выборе пути тестов. Т.е. для работы системы тесты не обязаны находится в одном конкретном месте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация через интеграцию. Промо-версия. UPD