Comments 21
Ко всем этим скрамам подходит фраза «Гладко было на бумаге, да забыли про овраги»…
Причём даже не в том смысле, что реальная жизнь отличается от теории.
А в том, что сама теория (методология) кривая.
Сам я какое-то время работал QA manager, потом уехал в США и здесь SDET.
Проблема тестирования в скраме в том, что предполагается, что разработчики работают над определённым количеством задач (фич, багов) в течении спринта, а тестеры их тестируют. Так вот — тестерам всегда нужно какое-то время ПОСЛЕ разработчиков для того, чтобы:
1) протестировать то, что накодили разработчики
2) протестировать на регрессию
Понятно, что разработчики не будут в это время сидеть без дела и ждать, что там тестеры найдут, поэтому они берутся за новые задачи. Но это должны быть или задачи из следующего спринта (а этого как бы быть не должно — мы же ещё в этом спринте), или добавляются задачи в текущий спринт, но тогда тестерам нужно дополнительное время опять же ПОСЛЕ разработчиков.
Это ещё дополняется отношением разработчиков, к спринту: «ну так у нас ещё 3 дня до конца спринта». Это если у них 3 дня, то у тестеров тогда не остаётся ничего.
Поэтому с точки зрения тестирования, скрам — это костыльный процесс.
Автоматизация помогает, но
1) как автор заметил — полностью всё авто-тестами не покроешь
2) для написания тестов тоже нужно время и обычно ПОСЛЕ разработчиков.
Причём даже не в том смысле, что реальная жизнь отличается от теории.
А в том, что сама теория (методология) кривая.
Сам я какое-то время работал QA manager, потом уехал в США и здесь SDET.
Проблема тестирования в скраме в том, что предполагается, что разработчики работают над определённым количеством задач (фич, багов) в течении спринта, а тестеры их тестируют. Так вот — тестерам всегда нужно какое-то время ПОСЛЕ разработчиков для того, чтобы:
1) протестировать то, что накодили разработчики
2) протестировать на регрессию
Понятно, что разработчики не будут в это время сидеть без дела и ждать, что там тестеры найдут, поэтому они берутся за новые задачи. Но это должны быть или задачи из следующего спринта (а этого как бы быть не должно — мы же ещё в этом спринте), или добавляются задачи в текущий спринт, но тогда тестерам нужно дополнительное время опять же ПОСЛЕ разработчиков.
Это ещё дополняется отношением разработчиков, к спринту: «ну так у нас ещё 3 дня до конца спринта». Это если у них 3 дня, то у тестеров тогда не остаётся ничего.
Поэтому с точки зрения тестирования, скрам — это костыльный процесс.
Автоматизация помогает, но
1) как автор заметил — полностью всё авто-тестами не покроешь
2) для написания тестов тоже нужно время и обычно ПОСЛЕ разработчиков.
Кстати, по описанию, в Канбане, вроде бы не должно быть этой проблемы — там как раз по процессу есть время на тестирование ПОСЛЕ разработки.
Не знаю, может это мне не повезло, но вот никогда не работал по Канбану — всегда, где я работал, когда говорят Agile, то обычно это скрам со спринтами. Может потому, что он бизнесу больше нравится из-за того, что там вроде как есть бОльшая управляемость / прогнозируемость?
Не знаю, может это мне не повезло, но вот никогда не работал по Канбану — всегда, где я работал, когда говорят Agile, то обычно это скрам со спринтами. Может потому, что он бизнесу больше нравится из-за того, что там вроде как есть бОльшая управляемость / прогнозируемость?
Там есть планы хотя бы на две недели :)
В Канбане возможны очень те же «проблемы», собственно там будет происходить так нелюбимый всеми «простой ресурсов» из-за узких мест, которые хорошо выявляет наличие ограничения по WiP.
Аналитики могут завалить разработчиков и ждать пока те разгребут проанализированные задачи. Разработчики -> тестировщиков. Если есть жизнь после тестирования — то тестировщики следующих за ними (например «специалисты по развертыванию»)
Конечно хорошо бы все эти узкие места расширять. Но в моей практике не взлетело. В результате спринты остались лучше по прогнозируемости чем канбан.
Аналитики могут завалить разработчиков и ждать пока те разгребут проанализированные задачи. Разработчики -> тестировщиков. Если есть жизнь после тестирования — то тестировщики следующих за ними (например «специалисты по развертыванию»)
Конечно хорошо бы все эти узкие места расширять. Но в моей практике не взлетело. В результате спринты остались лучше по прогнозируемости чем канбан.
Лучше всего, когда тестами покрывают свой код сами разработчики. У нас обычно перед слиянием своего кода, ты его сам покрываешь автотестами.
1) Почему нельзя разработчикам добавлять новый код в ветке относящейся к следующему спринту. Так будет выпущен стабильный оттестированный спринт n и не затормозится работа над спринтом n+1
2) В идеологии канбан, насколько я помню, команд должна работать как единое целое и над тем, чтобы задачи прошли через доску быстрее. То есть часть разработчиков может вполне заняться тетированием.
Я, наверное, чего-то не понимаю, но причем тут скрам? Да, я часто сталкивался с теми проблемами, которые вы описываете, но мне кажется, что это всего лишь неумение руководства грамотно организовать процесс разработки. Разработчики всегда кодят, а тестеры всегда за ними тестируют. И если рассуждать в вашем ключе, тестеры никогда не будут успевать протестить все, что накодили разработчики, просто по определению.
Скрам ведь не говорит, что разработчики должны кодить всю неделю фичи из спринта. Скрам говорит всего лишь об итерациях, в течение которых происходит разработка. Но ведь эти итерации нужно грамотно реализовать, не так ли? Скажем, использование TDD несколько снижает нагрузку на тестеров в конце спринта. И мне бы хотелось поработать в компании, где сумели грамотно TDD применить.
Вы пишете правильные вещи, я согласен. Но конкретно в нашем случае мы решаем эти проблемы следующим образом:
1) начало спринта. задач в тестировании нет, автотестер занимается тем, что вкручивает дополнительные фичи в проект (как пример, Allure отчеты, реализация паралелизации тестов в GRID и так далее). Либо же оптимизация кода, рефакторинг. В общем есть чем заняться.
2) конец спринта. задачи все в тестировании, либо закрыты, на разработке задач не осталось. Разработчики занимаются тем же самым. Оптимизация кода, рефакторинг, внедрение дополнительно функционала, не так ценного для бизнеса, но очень ценного технически.
3) На мой взгляд все подобные проблемы решаются грамотным планированием, пониманием, что такое Agile и правильно построенными коммуникациями.
1) начало спринта. задач в тестировании нет, автотестер занимается тем, что вкручивает дополнительные фичи в проект (как пример, Allure отчеты, реализация паралелизации тестов в GRID и так далее). Либо же оптимизация кода, рефакторинг. В общем есть чем заняться.
2) конец спринта. задачи все в тестировании, либо закрыты, на разработке задач не осталось. Разработчики занимаются тем же самым. Оптимизация кода, рефакторинг, внедрение дополнительно функционала, не так ценного для бизнеса, но очень ценного технически.
3) На мой взгляд все подобные проблемы решаются грамотным планированием, пониманием, что такое Agile и правильно построенными коммуникациями.
все подобные проблемы решаются грамотным планированием, пониманием, ...
Эта фраза означает, что «да, нам нужны костыли».
То, что этот костыль вы называете «грамотным планированием» особо ничего не меняет.
Это означает, что применением Скрама не получается делать нормальное планирование, поэтому приходиться добавлять «понимание».
Такие вот реалии.
Все больше и больше набирает обороты использование методологий семейства Agile, так называемых гибких методологий, в сфере IT
Вот уже лет двадцать как, а у кого то, все еще, обороты не набраны :-(
Заголовок — «Автоматизация тестирования по методологии Scrum» — явно ошибочен. Scrum никак не описывает автоматизацию тестирования (а описывает управление проектом), и даже, строго говоря, не является методологией. Впрочем статья в целом никак не соотносится с SEO-ориентированным заголовком.
По теме статьи, считаю, что ветвь — выделения в команду QA-автоматизатора, чтобы «свести ручную работу к минимуму» — тупиковая, ну и особенно, если других тестировщиков в команде нет. Так называемая «ручная» работа, а на самом деле «мозговая» — является краеугольным камнем тестирования, она приносит наибольшую пользу всему проекту, поэтому нет никакого смысла сводить её к минимуму. Что вероятно имел в виду автор — свести к минимум регрессионное тестирование (небольшую часть работы тестировщика), что разумно — но работает это гораздо лучше, когда сами программисты занимаются этой частью автоматизации. Роль типичного «автоматизатора» должна по моему мнению заключаться в обучении программистов и помощи им в технических вопросов. Или другими словами — автоматизатор, это такой же девелопер, с бОльшими познаниями в технологии написания автотестов.
По теме статьи, считаю, что ветвь — выделения в команду QA-автоматизатора, чтобы «свести ручную работу к минимуму» — тупиковая, ну и особенно, если других тестировщиков в команде нет. Так называемая «ручная» работа, а на самом деле «мозговая» — является краеугольным камнем тестирования, она приносит наибольшую пользу всему проекту, поэтому нет никакого смысла сводить её к минимуму. Что вероятно имел в виду автор — свести к минимум регрессионное тестирование (небольшую часть работы тестировщика), что разумно — но работает это гораздо лучше, когда сами программисты занимаются этой частью автоматизации. Роль типичного «автоматизатора» должна по моему мнению заключаться в обучении программистов и помощи им в технических вопросов. Или другими словами — автоматизатор, это такой же девелопер, с бОльшими познаниями в технологии написания автотестов.
Считаю неправильным в общем случае навешивать на разработчиков основного кода и автоматизацию тестирования на уровне большем чем юнит-тесты, ну, максимум, интеграционные тесты. Роль типичного автоматизатора должна, по моему мнению, заключаться в разработке функциональных, приёмочных, нагрузочных и прочих высокоуровневых тестов. Да, ему нужны навыки разработки, но несколько другие чем у обычных разработчиков, в общем случае ему не обязательно даже знать основной язык на котором разрабатывается система. Полезно, позволяет упростить/ускорить тестирование отдельных кейсов, но не обязательно. Вполне может обходиться высокоуровневыми средствами, абстрагированными от основного языка разработки.
Согласен с вами. Зачем в принципе программисту изучать тот же TestComplete для Blackbox-тестирования десктопного приложения. Учитывая, что по времени написание таких тестов будет примерно аналогично собственно разработке функционала.
> Учитывая, что по времени написание таких тестов будет примерно аналогично собственно разработке функционала.
Если считать это верным (к счастью, это не всегда верно) — то можно сразу поставить крест или на скраме. или на автоматизации с TestComplete — просто не будете успевать в одной итерации решить эти две задачи.
Если считать это верным (к счастью, это не всегда верно) — то можно сразу поставить крест или на скраме. или на автоматизации с TestComplete — просто не будете успевать в одной итерации решить эти две задачи.
Ну тут можно поступить так:
а) Автоматизация — это хорошо и полезно, но не настолько, чтобы тормозить из-за этого весь процесс, она может идти параллельно
б) BDD — если ручные тестировщики начнут писать в этом формате, а ароматизаторы только имплементировать эти шаги, то после первичного завала, через несколько месяцев объем работы будет уже вполне вменяемый
а) Автоматизация — это хорошо и полезно, но не настолько, чтобы тормозить из-за этого весь процесс, она может идти параллельно
б) BDD — если ручные тестировщики начнут писать в этом формате, а ароматизаторы только имплементировать эти шаги, то после первичного завала, через несколько месяцев объем работы будет уже вполне вменяемый
А зачем их решать в одной итерации? Задача разработки в одной итерации, её результат — оттестированый вручную сценарий, покрытие автотестами в следующей, её результат фиксация этого оттестированного и, может, уже работающего в проде сценария.
Хочу напомнить, что «юнит-тесты и интеграционные» и должны составлять львиную долю автотестов (см. «пирамида автотестирования», так что даже противоречия тут никакого нет.
Считаю, что высокоуровневые автотесты не могут ускорить тестирование — только замедлить могут.
Ускорить можно прогоны регрессии. Успевать с автоматизацией высокоуровневой регрессией в скраме — чрезвычайно сложно, хотя наверное возможно, если иметь хороших специалистов. В данном случае важно убедить всех членов команды, что спринт не может считаться успешным, если не закончены задачи автоматизации регрессии. На практике — очень непростое дело.
Считаю, что высокоуровневые автотесты не могут ускорить тестирование — только замедлить могут.
Ускорить можно прогоны регрессии. Успевать с автоматизацией высокоуровневой регрессией в скраме — чрезвычайно сложно, хотя наверное возможно, если иметь хороших специалистов. В данном случае важно убедить всех членов команды, что спринт не может считаться успешным, если не закончены задачи автоматизации регрессии. На практике — очень непростое дело.
Количественно, в штуках, да, львиную. По времени при нормальной архитектуре юнит-тесты практически не отнимают времени, интеграционные (в узком понимании) отнимают побольше, но не сильно. А вот тестирующее всё приложение в целом — много.
Основная задача автотестов — именно выявление регрессий. Грубо, в случае высокоуровневых сначала проходим сценарий ручками, а потом фиксируем его поведение автотестом. Вплоть до трансляции событий ручного прохождения в код, даже не глядя в результат трансляции.
Необязательно закрывать спринт задачами автоматизации выявлений регрессий, можно закрывать ручным тестированием, а открывать следующий автоматизацией. Так можно и устранить временной разрыв. В начале спринта тестировщики пишут автотесты на прошлый, а по мере готовности задач разработчиков тестируют их ручками.
Основная задача автотестов — именно выявление регрессий. Грубо, в случае высокоуровневых сначала проходим сценарий ручками, а потом фиксируем его поведение автотестом. Вплоть до трансляции событий ручного прохождения в код, даже не глядя в результат трансляции.
Необязательно закрывать спринт задачами автоматизации выявлений регрессий, можно закрывать ручным тестированием, а открывать следующий автоматизацией. Так можно и устранить временной разрыв. В начале спринта тестировщики пишут автотесты на прошлый, а по мере готовности задач разработчиков тестируют их ручками.
Sign up to leave a comment.
Автоматизация тестирования по методологии Scrum