Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Стратегия тестирования в условиях Scrum: зачем она нужна и как построить

Приветствую читателей DOU! Меня зовут Артем Безручко, я QA Engineer в Depositphotos. В тестировании уже 5 лет, занимаюсь как автоматизацией, так и ручным тестированием. Мне давно хотелось вынести тему тестовой стратегии на суд широкой публики. Все изложенные ниже методы и активности в большей или меньшей мере используются и выполняются тестировщиками нашей команды. Насколько это результативно, я продемонстрирую в конце статьи.

Материал будет полезен для представителей всех технических направлений, особенно для лидов и тех, кто пока лишь задумывается о том, как построить процесс тестирования в продуктовой компании.

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

Мне очень нравится подход Майкла Болтона. Он утверждает, что есть проверки, а есть тестирование. Автоматизация выполняет проверки и получает бинарный результат, а тестирование — это процесс, позволяющий получить развёрнутую информацию о продукте. Многие инженеры пытаются завести у себя на проектах автотесты, не совсем понимая, зачем они им. Большинство тестировщиков стремятся уйти в автоматизацию не из-за пользы для текущего проекта, а просто потому, что модно. И это проблема. Рассмотрим же, что такое тестовая стратегия и как такой подход поможет проекту.

Cтатья основана на моём докладе на online-конференции QA fwdays’20.

Стратегия тестирования: что это и чем она отличается от тест-плана

О тест-плане слышали все, многие даже писали его. Документ отвечает на основные вопросы: что, кто, когда и как тестирует? Он хорош и достаточно практичен, но только для проектов, имеющих конкретные объемы разработки, поскольку количество реализуемого функционала остается более или менее понятным до окончания построения финальной системы.

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

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

С терминами разобрались. Осталось понять, в чем беда скрама.

Waterfall никто не отменял, или Как мы докатились до Scrum

Все знают: вначале был Waterfall. Громоздкий, неповоротливый, длинный. С кучей документации и огромной инерционностью. И вот на смену ему пришел Scrum — легкий, гибкий и простой — в паре с Agile-манифестом, обещавшим разработке и бизнесу стратегию win-win. Берем спринты, нарезаем фичи и реализуем их за короткий промежуток времени. Потом следуют демо, ретро — и все по новой. На первый взгляд, гениально и просто. Но давайте остановимся на минутку и подумаем.

По Waterfall построено большинство вещей, кардинально изменивших нашу жизнь. Например, впервые отправили человека в космос и на Луну, используя именно каскадную модель разработки. Более того, серьезные медицинские проекты до сих пор применяют Waterfall. Может, он не так уж и плох?

Разберемся в предпосылках появления нового подхода в создании ПО. Agile был сформулирован людьми, которые занимались в основном коммерческой разработкой для компаний, выходящих на рынок, и предлагали свои решения широкому кругу пользователей.

Гибкие методологии были призваны устранить проблемы каскадной модели, такие как неповоротливость и инерционность. Была цель ускорить предоставление готовой продукции конечному потребителю.

Однако задача отказаться от документации и сохранения знаний не стояла. Именно с этой проблемой сталкиваются сейчас в большинстве случаев практически все молодые проекты, использующие гибкие подходы к разработке. Через полгода после запуска там уже черт ногу сломит в логике бизнеса и технической части. А если вдобавок сменится поколение инженеров, то у продукта возникнут дополнительные проблемы, которые новой команде невозможно предвидеть из-за образовавшегося информационного вакуума.

Теперь главный вопрос: как отдел тестирования помогает решать эти проблемы с помощью тестовой стратегии?

Рассмотрим лепестковую диаграмму, которая наглядно иллюстрирует, как наша команда чередует основные активности. Эту диаграмму я называю «шестеренкой тестирования»:

На окружности изображены шесть двухнедельных спринтов (приблизительно 3 месяца), каждый из которых условно разбит на 3 сектора: начало (1S — 1MS), середину (1MS — 1ME) и конец (1ME — 1E). Обозначены также уровни QA, QC, Testing и переходы между ними в разных временных рамках.

Из диаграммы следует, что основные задачи лежат в плоскости тестирования и контроля качества. И только один раз за все время отдел взлетает на уровень обеспечения качества, с вершины анализирует пройденный путь и пытается заглянуть за горизонт событий, в будущее.

Ремарка. В Украине границы между должностями и обязанностями QA, QC и Tester бессовестно размыты. Это вносит дополнительный хаос в и без того сложные процессы разработки. Если повезет, я напишу на эту тему отдельную статью.

У большинства команд бывают критические периоды, когда проблемы начинают сыпаться со всех сторон: баги пролазят на прод, тестовые окружения перестают быть стабильными и консистентными, количество flaky-тестов растет, спринты не закрываются. И ты вроде делаешь все, что надо, но результата не видно. В таком случае приходится принимать решение, как быть дальше: поменять компанию или проявить характер и вырваться из порочного круга. Мы остановились на последнем варианте. Наша команда на тот момент состояла из 11 человек: 2 Node.js разработчика, 1 Front-end, 5 PHP Back-end и 3 тестировщика.

Рассмотрим подробно, что именно мы делали для повышения вероятности успешного закрытия спринта и решения проблем.

Начало спринта

Типичная ситуация: после планирования разработчики перегружены задачами, а у тестировщиков, наоборот, дефицит работы. Самое время заложить фундамент качественного и эффективного тестирования на весь спринт. Вариантов несколько.

Пойти в разведку

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

1. Что будет реализовано в тикете?

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

Пример: «Добавить на главную страницу новый баннер с недорогим платежным планом за $X,XX» — изначально поставленная задача. Но с момента ее создания изменилось видение, и Product Owner написал разработчику — в обход таск-трекера и всей команды, — что баннер нужно отображать только для Украины. Для девелопера это мелочь, всего одна строка в конфиге, а для остальной команды — неочевидные требования.

2. Зачем это делается? Какова бизнес-цель?

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

3. Что будет задето этой задачей?

На первый взгляд, простой вопрос. Но ответ на него иногда вскрывает настолько неочевидные связи, что задавать его стоит в протокольном порядке. У нас был случай, когда при добавлении нового типа подписки переставала приходить рассылка, будучи соотнесенной с другими платежными планами. А в случае с баннером (см. пункт 1) была нарушена логика трекинга поведения пользователя.

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

4. С какими сложностями есть вероятность столкнуться при тестировании и эмуляции?

Разработчик проанализирует сотни строк кода, прежде чем написать свои. А если он хороший инженер, то задумается еще и над тем, чтобы его творение было пригодно для тестирования. Задав подобный вопрос, вы сможете избавить себя от часов бессмысленных исследований.

Пример. Когда мы внедряли оплаты и подписки для мобильных приложений через Apple, было достаточно сложно тестировать граничные значения и интеграцию с основным проектом. Разработка сделала приятную схему на API с хорошо конфигурируемыми мок-объектами, что значительно облегчило жизнь тестировщикам.

5. Согласовать критерий качества приемки задачи

Один из удивительных законов Мерфи применительно к разработке ПО формулируется так: «Все, что может быть понято двояко, будет понято двояко». Именно поэтому у нас инженеры проговаривают основные пункты приемки фичи, чтобы исключить возможные разночтения. Очень важно, чтобы сотрудники находились в одном контексте и имели единую систему координат и точку отсчета при работе над задачей.

6. Есть ли у разработчика пожелания и советы по тестированию задачи?

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

7. Подготовить альфа-версию чек-листа.

Очень полезная активность. Все скрытые нюансы, граничные значения и сущности после основательной беседы с разработчиком находятся в оперативной памяти нашего мозга. Самое время освободить ее и запечатлеть в виде первой версии чек-листа. В нем необходимо отметить основные модули, связи и специфические условия — одним словом, все, что поможет любому инженеру моментально найти точки входа для быстрого развертывания процесса тестирования.

8. Проверить описание задачи в Jira и исправить или дополнить на основе полученной информации в вышеперечисленных пунктах

Задачи в таск-трекерах сделали людям огромное одолжение, освободив их от бумажной работы. Запомните: таск в Jira — это документ, значит, он должен быть полным и оформлен согласно стандартам. Никогда не пропускайте этот пункт и обновляйте описание тикетов, как только получаете новую информацию.

Закрыть долги

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

1. Кейсы, не записанные в TestLink или другой тест-трекер

Всегда найдется сьют, который следовало бы проапдейтить, или функционал, для которого не созданы тест-кейсы.

2. Несозданные тикеты на автотесты

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

3. Пропущенные статьи в Wiki

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

4. R&D

Новые инструменты появляются постоянно, и сообщество предлагает большой выбор методов и подходов к работе. Где, как не в боевом окружении, их тестировать?

Середина спринта (тикеты непосредственно берутся в тестирование)

Рабочие дни идут, и вот таски планомерно заполняют столбик «Тестирование». Следующие действия качественно влияют на процесс, поэтому я настоятельно рекомендую именно такой порядок активностей.

Перед началом любых действий по задаче, которая требует тестирования, нужно перечитать описание и повторно переговорить с разработчиком (кратко). Цель — уточнить, одинаково ли все участники понимают задачу, а также убедиться, что ничего не изменилось, не встретились «подводные камни», которые внесли поправки.

Затем следует провести тест-дизайн, углубив анализ задачи на основе альфа-версии чек-листа, написанного ранее.

Бросаться на задачу с шашкой наголо и кромсать ее исследовательским тестированием — это похвально, но только после детальной проработки общего плана работ. Основные его пункты:

  • разбить объект на модули и логические составляющие;
  • обозначить связи с другими модулями системы;
  • выделить smoke-набор для TestLink/Wiki.

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

Любая деятельность ценна тем, что она что-то производит. Продукт тестирования => обратная связь по тикету. И чем быстрее она возвращается к разработчику, тем лучше. Но не стоит жертвовать полнотой информации, необходимо соблюдать баланс.

На техниках и подходах к ручному тестированию я останавливаться не буду. Надеюсь, все читатели прекрасно ими владеют.

Заведение отчетов об ошибках

Хочу обозначить два полезных момента:

  1. Пред заведением бага стоит проверить его наличие в трекере, чтобы не плодить дублей.
  2. После оформления саба надо сообщить разработчику. Не стоит рассчитывать, что он читает почту или правильно настроил нотификации.

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

По завершении тестирования тикета остается выделить кейсы для автотестов, оформить кейсы в TestLink и завести статью в Wiki.

Конец спринта

Благодаря четкому выполнению всего вышеописанного в последние день-два нагрузка на отдел тестирования снижается, высвобождая время для анализа проделанной работы.

Назначенный человек оценивает работу в спринте по следующим пунктам:

  1. С какими проблемами столкнулись, как их решали?
  2. Что нового узнали о работе системы? Нужно ли это документировать?
  3. Какие новые фичи зарелизены? Нужно ли закрывать их автотестами?
  4. Формирование задач для отдела тестирования на основе предыдущих пунктов.

Активности над спринтами

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

На следующем планировании один человек из отдела тестирования берет на себя задачу под названием «Пересмотр тестовой стратегии».

Таск включает следующие разделы:

1. Анализ проделанной работы за квартал/полгода

Просматриваются задачи, анализируются их характер, специфика и направление. Какие фичи релизились, какие заморозились, какие проблемы были наиболее распространены? Что автоматизировано, какую документацию создавали, какая не пригодилась? Также уточняется вектор будущего развития продукта, возможно, перечень технологий, которые планируется внедрить. Основные цели:

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

2. А не глупости ли мы делаем?

Этот вопрос я задаю себе каждый раз, когда тестирую новый подход, инструмент или технику в работе и организации команды. Но на этот раз вопрос стоит глобально. Цель — найти активности, на которые тратится больше времени, чем они принесут пользы. У нас такими оказались тест-отчеты. Мы составляли их еженедельно, тезисно описывая неочевидные связи и возникшие проблемы. Время расходовалось, а польза стремилась к нулю.

3. Сбор метрик по команде и проблемам

В этом пункте источником информации выступает таск-трекер. Собираем численные показатели:

  1. Баги от пользователей, относящиеся к нашей команде.
  2. Баги от пользователей, относящиеся ко всей компании.
  3. Баги, найденные тестировщиками нашей команды.
  4. Задачи, назначенные на отдел тестирования.
  5. Задачи, выполненные отделом тестирования.

4. Укрепление положительных активностей

Этот пункт призван укоренить действия, которые нетипичны для специалистов нашей области, но оказались нам по силам и принесли ощутимый результат.

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

Вторая такая активность — создание расширения для Google Chrome, которое в пару кликов приводит тестового пользователя в состояние готовности к тестированию.

Обычно для создания предусловий требуется от 1 до 5 минут, а благодаря приложению это делается в 3-4 клика за 10 секунд. Вроде не так уж и много, но в течение дня это экономит от 30 минут до часа. При масштабировании на всех тестировщиков профит заметно ощутим.

5. Анализ сохраненных знаний, систематизация

Проводится вычитка созданных статей и тест-сьютов. Цель — выбросить ненужное и устаревшее, организовать полезное, создать задачи на документирование и исправление нужного.

6. Чего не хватает отделу тестирования в целом?

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

Пример. Depositphotos использует много платежных систем для удобства пользователей по всему миру. Естественно, для Бразилии нужны одни провайдеры платежей, а для Канады — совсем другие. Налоги, которые платят пользователи в той или иной стране, записываются в отдельный налоговый сервис, а уже по нему компания предоставляет отчеты в соответствующие органы.

Так вот, при добавлении нового провайдера в Канаду после введения специального налога в провинции Квебек транзакции перестали попадать в сервис. Итог — приличный штраф для компании.

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

7. Пересмотр тестовой стратегии

На основе полученных данных необходимо внести коррективы в изначальный процесс тестирования.

8. Проверка знаний команды, выделение личных векторов развития

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

Результат применения тестовой стратегии

Что решает такой подход?

  1. Теряется минимум знаний о работе системы.
  2. Формализуются процессы и подходы. Снижается шанс любого сотрудника допустить ошибку.
  3. Понижается порог входа для нового сотрудника.
  4. Уменьшается bus-фактор.

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

Баги: тестировщики против пользователей

Каждый 13-й баг находит пользователь (показатель >10 — хороший). Количество оформленных багов показывает тенденцию к уменьшению, а количество проблем пользователей стабильно. На основе этого можно предположить, что кастомеры находят проблемы спустя длительное время после релиза фичи. Уменьшение количества найденных багов говорит о том, что больше проблем выявляется на этапе анализа требований и более плотного взаимодействия разработки с тестированием. Ну, или это признак ухудшения работы команды тестирования.

Задачи, выполненные инженерами тестирования и назначенные на отдел

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

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

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

Выводы

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

Хочу дать несколько небольших советов тем, кто решит делать что-то подобное в своей команде.

Будьте последовательными

Каждую активность проверяйте, анализируйте и аргументируйте. Не нужно бездумно копировать сторонние подходы. Вы не знаете и никогда не узнаете всех нюансов, которые привели другие команды к их результатам.

Будьте системными

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

Будьте профессиональными

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

Это все, о чем я хотел рассказать. Спасибо, что прочитали! Если появятся вопросы, я с удовольствием отвечу на них в комментариях.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному15
LinkedIn

Схожі статті




10 коментарів

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

Это само по себе говорит об очень больших проблеммах в тестировании. Значит, что в бэклог-рефайнменте (грумминг) и планинге тестировщики участия не принимают если эти процессы вообще существуют. Помимо того, что это не по эджайлу и не по Скраму (:-)), это несет следующие проблемы:
1. Выявление дефектов требований упущено. Все они пошли в работу и стоимость их уже многократно возросла.
2. Тестировщик к девелоперу как максимум может ходить для выяснения настроек энвайронмента. Если он ходит к нему за требованиями, это симптом некачественного тестирования. Он тестирует видение девелопера со всеми ошибками и допущениями. Отвлекает его и вряд ли может привнести что-то сверх того, что девелопер мог бы сделать сам. По сути, превращает тестировщика в подсобного рабочего для девелопера.
3. Задачи не оцениваются тестированием, соответственно, вся стратегия ситуативна (т.е. отсутствует, а есть лишь тактика). Принцип «что успеем, то успеем»
4. Тестировщики не являются равноправными участниками процесса. Помимо уже описанного это еще и просто демотивирующий фактор.
5. Как таковой общей команды нет. Есть подкоманда девелоперов и подкоманда тестировщиков. Нет общей ответственности и целей. Это почти всегда дает не слишком высокие результаты по качеству.

Назначенный человек оценивает работу в спринте по следующим пунктам:
С какими проблемами столкнулись, как их решали?

Это должна делать вся команда (так называемый silent writing). Проблемы:
1. Подкоманда тестирования не чувствует своей ответственности за результат этого процесса, скажется когда придет время выполнения.
2. Субъективное цензурирование и приоритизация.

Каждый 13-й баг находит пользователь (показатель >10 — хороший). Количество оформленных багов показывает тенденцию к уменьшению, а количество проблем пользователей стабильно

Для того, чтобы это утверждать надо сравнивать не количество, а «вес» severity. Если пользователи находят 1 критический дефект, а команда тестирования 13 миноров это вряд ли можно назвать хорошим результатом. Сравнивайте вес, а не количество.

Совет
1. Добивайтесь включения тестировщиков во все фазы. Особенно — в грумминг и планирование. Активно выясняйте и тестируйте требования еще на этапе получения их. Это сэкономит много времени потом и повысит качество.
2. Работайте как одна команда, а не как две отдельных подкоманды. Баг на проде — это ответственность всей команды, а не только тестировщиков.
3. Будьте равноправными участниками процесса разработки, а не хвостиком девелопмента. Не девальвируйте профессию тестировщика.

По Waterfall построено большинство вещей, кардинально изменивших нашу жизнь. Например, впервые отправили человека в космос и на Луну, используя именно каскадную модель разработки. Более того, серьезные медицинские проекты до сих пор применяют Waterfall. Может, он не так уж и плох?

На Луну отправляли не по «классическому ватерфолу» (который мы видим, например, в строительстве). Там было множество параллельных подпроектов с несколькими итерациями. Например Запуску ракеты с астронавтами на Луну предшествовали испытания ракеты-носителя, которым предшествовала разработка и стендовые испытания двигателей (не в одну итерацию), насосов и т.д.
Кроме того, есть обоснованные подозрения, что «классический» ватерфол никогда не существовал для разработки софта и что это лишь выдумка продавцов Скрама. В частности, критики ватерфола сслыаются на этот стандарт: www.product-lifecycle-management.com/...​ownload/DOD-STD-2167A.pdf. И критикуют его руководствуясь принципом «не читал, но осуждаю». Т.к. на первой же странице, в п.1.2. однозначно упоминается итеративность процесса разработки софта.

Сергей, спасибо за комментарий и такую глубину проработки и аргументации.
Вероятно я недостаточно акцентировал на некоторых процессуальных моментах внимание, выставив на передний план самые больные проблемы и подход к их решению.
1. Груминг и планирование присутствуют и тестировщики принимают в нем активное участие. Дополнительно — требования задач тестируются сразу после создания — настроен процесс нотификаций в slack.
2. Тестировщик к девелоперу ходит не только за выяснением деталей окружения, но для построения одного понимания задачи и качественной командной работы, также для страховки от «непредвиденных ситуаций», на которые я ссылался в статье.
3. Это ложное утверждение, я ответил выше.
4. Тестировщики являются равноправными членами процесса. Это важный пункт командной работы.
5. Не понимаю на чем основаны этот вывод, он тоже ложный.

Вторая часть
1. Анализ работы ответственного предоставляется всей команде и подразумевает живое общение.
2. Информация поступает от отдела по работе с клиентами. Все объективно и «без купюр»

Третья часть

1. Абсолютно согласен, но для формата статьи больше подходят «Общие цифры» на них я и остановился. Количество багов с которыми столкнулись пользователи приоритета «критический» «блокирующий» за период год ± составили 1-2 штуки. И подлежали подробному анализу.

Как завершение.
Скрам, аджайл очень спорные темы. И каждый их «готовит» по-своему. Человеческие процессы, особенно разработки, тяжело подстраиваются под книжные шаблоны. Особенно в больших компаниях и их продуктах, которые давно представлены на рынке.

Ни в коем случае не претендую на истину в последней инстанции.
Я старался поделится опытом ошибок и пути по которому прошла наша команда для их решения.

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

Тем не менее, то, что вы пишете сейчас не очень согласовано с тем, что написано в статье.

1. Груминг и планирование присутствуют и тестировщики принимают в нем активное участие. Дополнительно — требования задач тестируются сразу после создания — настроен процесс нотификаций в slack.

Если Грумминг присутствует и тестировщики активно в нем участвуют, значит требования уже проанализированны. Откуда тогда эта активность?

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

Все эти вопросы должны быть отвечены еще до начала спринта иначе как вы вообще можете что-то оценить и спланировать?:

1. Что будет реализовано в тикете?
2. Зачем это делается? Какова бизнес-цель?
3. Что будет задето этой задачей?
4. С какими сложностями есть вероятность столкнуться при тестировании и эмуляции?
5. Согласовать критерий качества приемки задачи

Остальные вопросы еще можно отложить, но не эти.

Если статья не соответствует описанию, измените статью. Зачем она, если все на самом деле оказывается совсем не так и выясняется только в комментариях?

Комментарии призваны раскрыть недостающие части статьи, это хорошо, что Вы задаете такие вопросы. Я повторюсь — акцент был на ключевых моментах. Поэтому сейчас постараюсь максимально четко ответить на Ваши, Сергей, вопросы.

Добавлю данных, чтобы мы друг-друга лучше понимали. Наша команда работаем над проектом depositphotos.com поверте на слово, тут очень много бизнес-логики и неочевидных связей.

Наш груминг поверхностный и в нем не тратится время на выяснение ВСЕХ технических деталей. Главная цель — понимать вектор работы. Основное исследование проводится инженером непосредственно в спринте. Оттуда и происходит такая активность.

Вторая часть про вопросы.
У нас практикуется изменение требований задачи непосредственно в спринте. Это требует адекватной реакции со стороны команды. Озвученные вопросы призваны страховать всех участников разработки. А планирование происходит с учетом рисков, естественно.

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

Так а тестовые стратегии тут причем? То, что описано в статье — это не более, чем описание реализации тестового процесса, причем, практически не отличающегося от классического, описанного в ISTQB.

Но процесс тестирования и тестовая стратегия — это как бы несколько разные вещи.

Спасибо за вопрос, Ольга.
Тестовая стратегия описывает план подхода к тестированию в цикле разработки ПО.
Другая дефиниция гласит, что стратегия это общий, недетализированный план, охватывающий длительный период времени, способ достижения сложной цели.
У нас были цели и план, которые мы выполнили и достигли. Процесс тестирования был его неотъемлемой частью. Что и продемонстрировано в статье.

Автору, вероятно, надо было сказать «...и мы приняли стратегическое решение...», отсюда и название.

Попробуйте Agile в класическом понимании — откажитесь от спринтов.

упреждая пену : советую посомтреть доклад Dave Thomas: Agile Is Dead

Как ни странно, на данный момент мы уже не работаем по спринтам. Статья относится к периоду полугодовой давности. SCRUM это то, что пробует большинство команд, и в некоторых случаях, он себя исчерпывает. За доклад «Agile Is Dead» спасибо.

Шикарнейший доклад, тоже рекомендую всем.

Підписатись на коментарі