Comments 8
Разве в agile команде возможен «тестировщик-автоматизатор»?
Текст протворечит своим же утверждениям: «Тестирование НЕ фаза. Все занимаются тестированием.»
Это раз.
Два.
«Автоматизация не требует вмешательства человека. Их запуск не требует наблюдения (например, на ночь).» — смешной бред.
Три. Вы все еще делите тестирование на ручное и автоматизированное? Почитайте определения.
Четыре. А можно примеры если не по пунктам, то хотя бы по заголовкам? С чиселками.
Текст протворечит своим же утверждениям: «Тестирование НЕ фаза. Все занимаются тестированием.»
Это раз.
Два.
«Автоматизация не требует вмешательства человека. Их запуск не требует наблюдения (например, на ночь).» — смешной бред.
Три. Вы все еще делите тестирование на ручное и автоматизированное? Почитайте определения.
Четыре. А можно примеры если не по пунктам, то хотя бы по заголовкам? С чиселками.
Большое спасибо за вопросы!
«Тестирование не фаза» — это действительно так. В начальных стадиях внедрения Agile методологии в команду, первые вопросы, которые возникают: «Что будет делать тестирование в первые несколько дней спринта?» и «Что будут делать разработчики, пока тестировщики тестируют в конце спринта?»
«Все занимаются тестированием» — именно так решаются проблемы, озвученные выше. В момент, когда разработчик закончил создание нового функционала, в agile команде для него готовы тестовые сценарии, подготовленные тестировщиками. Автоматизатор в этот момент читает документацию и пишет автоматические тесты, постоянно взаимодействуя с командой. В конце разработки у нас есть протестированная фича и автотесты, которые помещаются в регресс и проверяют этот функционал.
Как только тесты помещены в регресс, они не должны требовать вмешательства человека до тех пор, пока не будет изменений этого функционала.
Поделитесь, пожалуйста, своим опытом работы в agile команде. Когда у вас происходит тестирование и автоматизация?
«Тестирование не фаза» — это действительно так. В начальных стадиях внедрения Agile методологии в команду, первые вопросы, которые возникают: «Что будет делать тестирование в первые несколько дней спринта?» и «Что будут делать разработчики, пока тестировщики тестируют в конце спринта?»
«Все занимаются тестированием» — именно так решаются проблемы, озвученные выше. В момент, когда разработчик закончил создание нового функционала, в agile команде для него готовы тестовые сценарии, подготовленные тестировщиками. Автоматизатор в этот момент читает документацию и пишет автоматические тесты, постоянно взаимодействуя с командой. В конце разработки у нас есть протестированная фича и автотесты, которые помещаются в регресс и проверяют этот функционал.
Как только тесты помещены в регресс, они не должны требовать вмешательства человека до тех пор, пока не будет изменений этого функционала.
Поделитесь, пожалуйста, своим опытом работы в agile команде. Когда у вас происходит тестирование и автоматизация?
В момент, когда разработчик закончил создание нового функционала, в agile команде для него готовы тестовые сценарии, подготовленные тестировщиками. Автоматизатор в этот момент читает документацию и пишет автоматические тесты, постоянно взаимодействуя с командой.
Увеличение количества рабочих центров и специализация это прямое противоречие Agile. Кроме того, описанная система предельно медленная и неустойчивая к флуктуациям.
У меня в команде автоматизация не отделяется от разработки, аналитики и тестирования. Чем по вашему agile команда отличается от не-agile?
Такое ощущение, что взяли презентацию без самого доклада. Т.е. обрывочные тезисы, взятые со слайдов, без всякого объяснения.
Как (методология) Agile связан(а) с Тестированием
Резюмируя, лучше бы материал не просто нашли в закромах, но и подготовили к публикации.
Тема-то, и в самом деле интересная.
Как (методология) Agile связан(а) с Тестированием
- Тестирование продвигает проект — каким образом? как связано с Agile?
- Тестирование НЕ фаза — как связано с Agile?
- Все занимаются тестированием — кто все? как связано с Agile?
- Сократите задержку обратной связи — начинайте тестировать как можно раньше и чаще — хороший лозунг, но как он связан с Agile?
- Тестирование отражает ожидания — чьи ожидания? как связано с Agile?
- Поддерживайте чистоту кода и фиксите баги быстро — как как связано с тестированием или Agile?
- Избавьтесь от излишков документации — и это поможет тестированию?
- Тестирование — часть “Критерия готовности” (“DoD”, Definition of Done) — Как процесс или активность может быть частью критериев?
- От “Тестирования после Разработки” к “Разработке через Тестирование” — как связано с Agile?
Резюмируя, лучше бы материал не просто нашли в закромах, но и подготовили к публикации.
Тема-то, и в самом деле интересная.
Статья содержит только основные идеи создания автоматических тестов в Agile команде. Мы неоднократно рассматриваем эти идеи внутри нашего курса. Тема действительно интересная, все больше команд пробуют Agile методологию и задают одни и те же вопросы.
Возможно, что в рамках освещения курса будем постепенно раскрывать уже дополнительно, т.к. такой материал обычно как раз и выявляет отдельные пункты интереса, которые уже и расписываем потихоньку или рассматриваем на открытых уроках.
Возможно, что в рамках освещения курса будем постепенно раскрывать уже дополнительно, т.к. такой материал обычно как раз и выявляет отдельные пункты интереса, которые уже и расписываем потихоньку или рассматриваем на открытых уроках.
Статья содержит только основные идеи создания автоматических тестов в Agile команде.
Извините, не нашел, по большей части вижу только обрывки фраз. Можете привести несколько примеров идей из статьи?
Я понимаю, что тема горячая, но за два десятка лет с начала использования Agile в разработке ПО от создателей курсов ждешь гораздо более зрелого материала.
Надеюсь, что читатели статьи сделают правильные выводы о качестве курсов.
Если вы ссылаетесь на материал, значит считаете что он вполне раскрывает тему. Оригинал, к сожалению, не выдерживает никакой критики. Такое впечатление, что автора заставили сделать презентацию на тему к которой он имеет отдаленное отношение и он просто скидал все в кучу что нашел в поисковике. Тот кто на собственном опыте подтвердил или опроверг какие либо тезисы об автомтизации и agile, поделился бы опытом, а не «лозунгами» которми кормят заказчиков, чтобы продать им больше часов.
Что это было? о_О
И как вы представляете этот процесс автоматизации? Юнит тесты что, бывают не автоматическими? Не говоря уж о том, что юнит тесты тестируют код, а не продукт.
Разработка в узком смысле. Не тестирование. Из название должно быть понятно. Использовать полноценный TDD с какими либо тестами, кроме модульных у вас не получится, я вас уверяю. Следовательно тестирование как таковое тут вообще не при чем.
А юнит тесты не могут быть частью регрессии? Модульное тестирование на самом деле всегда еще и регрессионное. И с чего бы автоматизация регрессиинных тестов — это бест аджайл практика, а автоматизация аксептенс тестов — это не бест. Вроде должно быть ровно наоборот. Второе явно более серьезное мероприятие. И является большими инвестициями в готовность к изменениям.
Может конечно это из какой-то умной книжки взято, я не знаю. Но исходя из моего опыта звучит, простите, как-то бредовато.
Best Practices в Agile Тестировании
Автоматизация юнит-тестирования.
Разработка через тестирование.
Автоматизация регрессионного тестирования.
Исследовательское тестирование.
Автоматизация юнит-тестирования
И как вы представляете этот процесс автоматизации? Юнит тесты что, бывают не автоматическими? Не говоря уж о том, что юнит тесты тестируют код, а не продукт.
Разработка через тестирование
Разработка в узком смысле. Не тестирование. Из название должно быть понятно. Использовать полноценный TDD с какими либо тестами, кроме модульных у вас не получится, я вас уверяю. Следовательно тестирование как таковое тут вообще не при чем.
Автоматизация регрессионного тестирования
А юнит тесты не могут быть частью регрессии? Модульное тестирование на самом деле всегда еще и регрессионное. И с чего бы автоматизация регрессиинных тестов — это бест аджайл практика, а автоматизация аксептенс тестов — это не бест. Вроде должно быть ровно наоборот. Второе явно более серьезное мероприятие. И является большими инвестициями в готовность к изменениям.
Может конечно это из какой-то умной книжки взято, я не знаю. Но исходя из моего опыта звучит, простите, как-то бредовато.
Sign up to leave a comment.
Автоматизация тестирования и Agile