Тестирование в Agile


#1

Добрый день, коллеги.

В последнее время бомбит меня на тему тестирования в разработке по Agile.
Саму методику внедряем как можем и не много в этом понимаем, если честно.
Разрабатываем новый продукт. НЕ поддержка и НЕ доработка типовой.

Перечислю тезисно, что вызывает противоречия.

  • Методика Agile предполагает быстрое создание прототипа, чтобы проверить идею.
  • Задачи на разработку идут от историй, которые “как бы на языке Gherkin в идеале должны писаться”, по факту истории короткие. простор для “творчества” команды.
  • За спринт команда должна выдать готовый инкремент. то есть то, что “идет в production”.
    Это подразумевает что инкремент закрыт тестами.
  • Разработчик сам заинтересован сдать свою часть инкремента. Теоретически.
  • Время на разработку инкремента с тестами в два раза больше чем без тестов. Мотивация руководителя и разрабов - “тесты потом как нибудь”
  • Сделали тестирование готового функционала с запозданием на спринт.
  • Самый Главный Заказчик разработки на демонстрации говорит “все не то” и инкремент выкидываем на помойку. А делает он это в 9 случаях из 10.
  • Решили тестировать только тот один инкремент из 10 который заказчик принял. Но все равно уже даже после демонстрации и доработок.
  • Автотесты на непринятый функционал не имеют смысла. Они конечно падают, но никому нет дела до него, т.к функционал выкинут на помойку.

Очевидно, что мы не умеем готовить этот странный Agile.

Подскажите, как правильно должна вестись разработка нового продукта по Agile?
Насколько подробно должны быть написаны истории?
Что и в какой момент покрывать тестами?
Выкидывать на помойку неудачный эксперимент( + тесты) - это нормально, или лучше без тестов?

Нарастает ощущение, что я совершаю мартышкин труд, никому не нужный и бесполезный…


#2

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

Аналитик где ? где ведущий разработчик ?

Фактически тут дело не в тестировании, а то что у вас с заказчиком нет Agile процесса.

Agile - это философия, быстрое создание прототипа - это не про Agile. Быстрое создание прототипа - это про SCRUM скорее, который процесс: то есть это методика быстрой проверки гипотезы.

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

Для наведения порядка - нужно взять главного заказчика и сделать с ним Example Mapping: то есть попробовать коллективно написать фича-файлы и что важно скорее всего - прототипы интерфейсов.

Если подытожить - та ситуация которую ты описываешь, она стандартна: она означает что аналитики (люди которые анализируют цели и сценарии продукта) выпали из процесса. Они видимо там ЧТЗ пишут ?


#3

Ну в целом да, ты все верно понял. У нас есть архитектор от команды. только он не может вытащить из заказчика “Что те нада то?” В итоге: понимаем, тыкаем пальцем в небо и мимо.
У нас две задачи выходит:

  1. Наладить процесс разработки как правильно.
  2. Правильно внедрить тестирование и авто в том числе.
    Чтобы это делать мне нужно хотя бы векторное понимание каков правильный процесс по Agile и какое в нем место для тестирования.
    Можешь поделиться мудростью?

#4

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

Это начало пути. Если вы здесь свернете не туда, все остальные исправления процесса уже не помогут.

Архитектор понимает=признает, что он не может вытащить с заказчика ?

Вы понимаете причины, почему так происходит?

нужно это исправлять и одним из первых.


#5

Где представитель заказчика ? Его также не волнует что архитектор из него не может вытянуть потребности ?

Может это и не заказчик - может это прослойка ? которая скрывает заказчика.

Вообщем - если архитектора попросить написать интегральную фичу, все станет понятней.

Функциональность: Супер система
Я как <кто владелец системы>
Хочу <что он хочет>
Чтобы <на чем собирается зарабатывать>

Контекст
Допустим существует <отрасль>
И существует <отдел>
И существует <список оппеаций которые выполняются вручную>

Сценарий: Сделать <ЧтоТоАвтоматически>

Пора уже выпускать пособие архитектора… Начинающего


#6

Запиши меня в лист ожидания. Куплю как будет готово )))


#7

Пока ждёте, можно почитать “97 этюдов для архитекторов программных систем”, например.