- Что это и как возникло
- Канбан и Scrum — тоже Toyota
- Связь между Lean и Agile
- QA-отдел по Lean
- Чем удобна методология
- Этапы
- Лучшие практики
- Как будет выглядеть Lean в моем QA-отделе
Lean QA описывается одной фразой “обрезать все лишнее” — чтобы не тратить время тестировщиков на второстепенные вещи. Если правильно внедрить принцип Lean в QA, на выходе получают приложение класса “лексус”
Волшебная японская методика, о которой слышали все лиды, но вряд ли применяют
Lean — это “японская” методика, которая является интегральной, то есть касается всех процессов в компании; в первую очередь, конечно, она влияет на разработку, но, как убедимся далее, на тестирование тоже. Справочники определяют Lean как “бережливое производство”, “экономное производство”, указывая на происхождение термина из истории японской промышленности середины XX века. Lean-методика возникла в весьма специфических условиях, когда японские промышленники, оперируя в сложнейшей обстановке, в разоренной войной стране, не видели иного выхода, кроме как делать свою продукцию очень дешевой и очень качественной — одновременно.
Бизнес семьи промышленников Тоёда после II Мировой Войны был на грани краха. Копия немецкого “жука” не зашла потребителям, как и копии “доджей” и “шевролетов”; ремонт американских военных автомобилей тоже не позволял компании удерживаться на плаву; в конце концов массово забастовали рабочие, и глава династии удалился в отставку, а вскоре и умер. Перед Тоёдами восстал вопрос — что делать, как развиваться дальше. В Америку “изучать опыт” был отправлен наследник и будущий руководитель компании Эйдзи Тоёда, который лучше подходил для этого — любимым занятием молодого Эйдзи было то что сейчас принято называть реверс-инжинирингом, “шевролетов” и “фордов”. Побывав на американских заводах, Эйдзи оценил циклопические масштабы производства, но крайне удивился расточительности американцев. Из поездки были сделаны соответствующие выводы: взято все лучшее, и привнесена специфическая бережливость и внимательность к деталям — так и появились принципы Toyota. То есть Lean-методика Toyota, фактически сделавшая компанию мировым лидером на рынке легковых автомобилей. Лидером она остается и сейчас.
Кроме экономного промышленного производства, бывает еще Lean-логистика, Lean-строительство, и даже Lean-почта (в североевропейских странах). Правительство некоторых стран тоже бывает “Lean”. Подобные практики иногда аппробируют и в медицине: в последние годы муниципальные поликлиники в некоторых городах России переводятся в режим “экономного обслуживания”.
Канбан и Скрам это тоже Toyota
На заводах семьи Тоёт также изобрели канбан, то есть сначала это была заводская практика отмечать детали особыми этикетками; числится за этой совершенно необычной семьей-корпорацией и изобретение кайдзен — практика близкая по смыслу к CI/CD, заключается в непрерывном совершенствовании процессов. Апологеты Scrum несколько десятилетий спустя считали кайдзен одним из источников “философии Scrum”.
Почему называется “Lean”? Какая связь между Lean и Agile?
В жизни “lean” говорят о человеке, когда он из толстого, неповоротливого превращается в стройного, подтянутого, “убирает бесполезный жир”, а в ИТ Lean — это о том, как “обезжирить” все процессы, оставляя только нужные. Это существенно упрощает разработку и тестирование — и тогда команде легче быть Agile, то есть гибкой, приспособленной к быстрым изменениям, да и просто комфортной для сотрудников. В этом заключается связь между Agile и Lean.
QA-отдел по Lean: никаких задержек и проактивный поиск лишнего
В QA-тестировании Lean означает в первую очередь повышенное внимание команды к баг-трекинговой системе; как только получен баг-репорт, баги фиксятся как можно скорее, и, важно, с мобилизацией усилий всей команды. В философии “бережливого производства” баги считаются не просто багами, ошибками, это хуже — они являются источником задержек. Потеря времени — самая страшная вещь в философии экономного тестирования.
Тестирование идет непрерывно и особым образом, ориентированным на проактивный поиск “блокирующих элементов”, которые не дают добавленной стоимости в разработке и QA. Апологеты Lean считают, что в процессе тестирования всегда обнаруживаются элементы, не дающие никакой ценности. Значит целью каждого из тестировщиков (а тем более лида) должно быть поиск и устранение этих малоценных вещей.
“Убрать лишнее” — “лишнее” здесь означает “все в разработке и тестировании, не приносящее ценности конечному пользователю”. Все “лишнее” неизбежно “висит” на конечной стоимости продукта/сервиса, и это снижает прибыль ИТ-компании. Компания выпускает продукт позже, а значит проигрывает в гонке на время.
Чем удобна Lean-методика
- Всеобъемлющее улучшение процессов в QA. Совершенствуется не только разработка, а все процессы, начиная от сбора требований и далее до продакшена.
- Lean-тестирование известно среди QA-лидов по своей главной характеристике “убрать лишнее”. Это понимание есть, но от слов к делу обычно не переходят, поскольку лиды недооценивают выгоды — явное повышение качества софта, ускорение продакшена, и в целом улучшение рабочей обстановки в компании.
- Есть хоть и небольшое, но сплоченное Lean-комьюнити. Agile-методика намного более известна и намного шире применяется; Lean-методика имеет более раннее происхождение, хоть и начала внедряться позже. Поэтому Lean-комьюнити как бы более “традиционное” и узкое.
- Универсальность, то есть пригодность Lean-принципов ко всем QA-процессам. “Японскую экономность” можно внедрить практически в каждый аспект разработки и тестирования. Если Lean правильно внедрен и команда усвоила принципы, научилась “работать по Lean”, дальше все пойдет проще, в том числе на новых проектах.
- Постоянное обучение. Методология изначально ориентирована на постоянное обучение (то есть повышение квалификации персонала), и эксперименты. Lean чуть меньше фокусируется на требованиях чем другие методики, и больше на качестве как конечной цели, во всех аспектах софта.
Lean: этапы и временные рамки
- Находят “лишнее”, “второстепенное” в QA-процессах. Находят, “фиксят”, и/или устраняют.
- Создаются отдельные чекпоинты для команд — и тестировщиков, и разработчиков. Руководство обеспечивает, чтобы обе команды были преданы общему делу, и обладали солидарным чувством ответственности за продукт, переходящим в чувство собственника (ownership).
- Проблемы должны решаться методично, это значит “не хаотично”. Статистически доказано, что так время до выхода на рынок (time-to-market, TTM) получается короче. “Хаотичное тестирование”, пусть даже очень талантливыми людьми — плохая практика. Когда Lean правильно внедрен, то сотрудники, “прикрепленные к функциям” и направлениям, сосредотачиваются на совершенствовании своих функций и продукта в целом, и у них еще, как правило, остается время на эксперименты, инновации — за это Lean ценится опытными тестировщиками.
- Методологию можно внедрить за время порядка месяца — этого достаточно, чтобы небольшая команда восприняла принципы Lean и начала работать “по Lean”.
- Lean могут принять не только команды (особенно в стартапах), но даже и отдельные люди (допустим на фрилансе) — замечая улучшение индивидуальной продуктивности.
Лучшие практики Lean
- Оптимальное использование имеющихся ресурсов. Lean-testing: ничего лишнего не делается, поэтому ничего нужного не теряется! Всякий имеющийся ресурс используется оптимально, на всем протяжении жизненного цикла проекта.
Применяются принципы минимально жизнеспособного теста и минимально жизнеспособного процесса.
Персонал QA-отдела любит работать с эффективными и простыми тестами — так экономится время тестировщиков и повышается их продуктивность на рабочем месте, что понятно, ибо никто не любит делать “лишнюю работу”. В результате приложение радует стейкхолдеров и пользователей. Клиенты получают свои приложения с требуемой функциональностью. А самые важные бизнес-клиенты, дающие большую часть прибыли компании — качественную поддержку, которую они так ценят.
- Малое время выхода на рынок. Методики Lean и Agile сходны в том, что экономится время в цикле — и быстрее разворачиваются проекты. QA-команды работают явно быстрее, а значит релизы делаются чаще. Учитывая обязательное применение CI-CD (то есть непрерывной разработки, деплоя и интеграции), приложения непрерывно дорабатываются идеальной Lean-командой. У лида крепнет уверенность, что ожидания пользователей будут правильно выполнены.
Чтоб быстрее доставлять приложение на рынок, в Lean чаще чем обычно применяются виртуализированные тестовые окружения, и автоматизация интеграционного тестирования. Тестировщики создают кастомные виртуальные окружения. Создаются виртуальные снепшоты тестового окружения, что ускоряет работу тестировщиков (особенно воспроизведение багов).
- Как мы уже знаем, в Lean повышенное внимание уделяется баг-трекинговой системе, упорядоченности репортов (и в целом качеству баг-репортов), то есть подсистема тест-менеджмента должна быть близкая к идеальной.
В QA-командах с множеством удаленных сотрудников существует проблема “избыточности информации”, ее дублирования/перекрывания, которая возникает, по сути, из неэффективной коммуникации. То есть remote-автоматизаторы могут даже, грубо говоря, “делать одну и ту же работу” одновременно. Это (и многое другое) решается применением специализированных, тщательно подобранных инструментов управления тестированием. В “идеальной” Lean-системе удобно организованы конфигурации, удобно планируются ресурсы, ведется учет изменений (тестовых) данных, фиксируется почему и когда они сделаны, и каковы результаты.
Как будет выглядеть Lean в моем QA-отделе?
Статистически, самые распространенные негативные вещи в QA, побороть которые помогает методика Lean:
- слишком частое, хаотическое переключение между задачами — упорядочивается;
- частично выполненная работа — или успешно завершается, или прекращается;
- “излишняя функциональность”, насчет которой нет уверенности, приносит ли пользу — от нее отказываются;
- разбухшая “очередь задач” — не накапливается;
***
Время, затраченное на тестирование, можно — и нужно — экономить, уменьшая количество “избыточной” информации в системе, “избыточных” действий, “избыточных” функций в приложении.
