Черпаю мысли из забытых мною книг,
Стараясь перед Богом оправдаться,
Но что с того, что я смогу признаться,
В соавторстве закрученных интриг.
Когда вы только начинаете разрабатывать программный продукт, возникает искушение не писать ТЗ и быстро набросать макет продукта, который обсуждали «в прошлый понедельник».
Команда разработчиков пока еще небольшая и все можно обсудить, не вставая из-за стола.
Если удача улыбнулась и продукт оказался востребованным, значит его надо уже тестировать для отторжения от разработчиков.
Приглашаем в проект тестировщика и, если опять фортуна к нам лицом, неизбежен вопрос: на основе чего тестировать?
Завтра схожий вопрос уже от технического писателя: Как продукт должен работать, чтобы его правильно описать?
А теперь, ВНИМАНИЕ, главный вопрос!
Как фиксировать требования к продукту в условиях, когда нет ТЗ на конечный продукт, потому что никто пока не знает - что в итоге в него войдет?
Проблема осложняется еще и тем, что теперь большинство новых фич готовятся с учетом пожеланий реальных или вероятных покупателей продукта, которые еще менее терпеливы, чем дети.
Итак, в начале долгого пути у нас есть макет продукта без требований к нему. Он не оттестирован и не описан.
Так выглядит упрощенный agile в большинстве стартапов.
Технология промышленной разработки программных продуктов крепко отличается. И вот почему.
В таких проектах появляется несколько команд, каждая из которых ведет разработку своей части на основе функциональных требований, разработанных аналитиками.
Появляется необходимость их координации. Необходимо добиться того, чтобы требования к системе все команды понимали одинаково. Возникает необходимость проводить межкомандную отладку. Команды должны писать требования к реализации или хотя бы фиксировать как именно реализованы функциональные требования. Для будущих поколений разработчиков также будет полезна информация почему реализовано именно так, а не иначе. Тестировщиков надо выделять в отдельную команду т.к. большинство ошибок возникает на стыках команд разработчиков.
Разработка методом последовательного наращивания функционала таит в себе мину замедленного действия. В какой-то момент выясняется, что принятая изначально архитектура не может вместить в себя новую фичу или не справляется с возросшей нагрузкой. Этой проблемы не возникает, когда весь функционал и нагрузка заранее известны. Бывает, что и системное ПО, на котором вы базируетесь, меняет API, а еще хуже … архитектуру. И тогда возникает необходимость в рефакторинге. Он убивает все, что приносит радость в жизни, и.... затягивает сроки спринтов в разы. Его почти невозможно предусмотреть. Появляется необходимость в регрессионном тестировании значительной части продукта. В такие моменты начинает расти технический долг.
Из запланированных фич исчезает все, кроме самого необходимого, без чего фича уже и не фича. Тестируются только положительные сценарии. Метод борьбы с ростом затрат автотесты для устоявшегося функционала.
Когда продукт начинает продаваться, появляется необходимость в его поддержке. От службы поддержки появляются запросы на исправления багов. Возникает желание в исправлении только в следующей версии, не отвлекая ресурсы от разработки новых фич. Если же идти навстречу заказчикам и править баги в старом релизе, то начинают сыпаться уже согласованные спринты следующего релиза. Так как каждый исправленный баг требует тестирования в старом релизе и, в дальнейшем, проверки в правильности портирования в текущий. Разработчикам приходится переключаться с разработки новых фич на исправление ошибок и обратно. Можно заставить заказчика ждать нового релиза, обещая, что баги будут исправлены в нем. Но заказчики не готовы ждать. Поэтому, чтобы не потерять заказчика и деньги за техподдержку, приходится править ошибки в старом релизе.
Продукт приобретает свойства промышленного и … появляются релизы, состоящие только из багфиксов.
Это никому, кроме заказчиков, не нравится. Потому что надо отвлекаться на старый код. А это переключение контекста. А это трата времени и срыв текущего спринта. Правда, это подталкивает разработчиков к разработке автотестов, документированию кода, чего так все не любят и, что, до момента появления багфикс релизов, всем представляется прихотью менеджеров и пустой тратой времени.
Поэтому в тестировании может находиться по несколько релизов одновременно: релиз багфиксов, выпускаемый релиз, текущий спринт следующего релиза…
Чуть подробнее об автотестах. Перед командами стоит вопрос надо ли их разрабатывать и, если надо, то в каком объеме. Все наверняка знают про TDD (Test Driven Development). Но в продукте, где уже отлаженный функционал может меняться по несколько раз, это ведет к затратам на разработку теста при каждом изменении. В этом случае все тесты, кроме последнего, идут в корзину. Совсем не писать автотестов – другая крайность. Тогда все перекладывается на ручное тестирование, что ведет к недотестированию и поставке заказчикам полуфабрикатов. Это еще хуже. Каждая команда выбирает компромиссное решение. Обычно тесты пишутся на стабильный функционал, для проверки форматов, на нагрузку. Юнит тесты используются для функций со сложной логикой и/или большим количеством веток исполнений. Все тесты запускаются автоматически при каждой сборке компонентов продукта в системе CI (continuous integration). Идеальный вариант, если есть возможность воспользоваться бэта тестерами. Например, ... из числа лояльных заказчиков.
- Why you call this version “beta”?
- Because it’s betta than nothingНародная мудрость
