Итак. В 2018 году на Heisenbug (Московская конференция по тестированию) Барух Садогурский (Developer Advocate в компании JFrog) презентовал интересный кейноут, в котором рассказал о своих основных идеях того, «куда надо идти». В 2019 году на том же Heisenbug состоялся сиквел его доклада про то, КАК идти, чтобы достичь этой цели. С одной стороны, мне бы хотелось поддержать версию движения Б. Садогурского, которую он транслировал, но во первых мне она еще не известна, а во вторых рискну сформулировать свое видение и описать свой личный путь, основываясь на своем опыте.
Для контекста (он вымышлен и любые совпадения с реальными кейсами чистая случайность) представим некоторую региональную ИТ-компанию-вендор с достаточно большим подразделением, занимающимся разработкой. В рамках этого подразделения есть функция тестирования, которая состоит условно из 30 человек различного уровня знаний и навыков.
В представленной компании есть несколько продуктов, которые долгое время находятся в релизе и начальный этап их разработки пройден более 7-8 лет назад. Учитывая, что компания является вендором, она следит за своими продуктами и регулярно их развивает, но не переделывает «с нуля». Это означает, что в продуктах содержится большое количество легаси-кода, «древних» технологических и архитектурных решений. Тестирование на этих продуктах на начальных этапах не рассматривалось, раньше их разработка велась по принципу «быстрей-быстрей и в продакшн», но сегодня в работе присутствует большой объем ручного тестирования — как регрессионного, так и тестирования новых функций. Идеологически разработка продуктов ведется под прессингом бизнесовых потребностей так, что времени на переосмысление идеологий и рефакторинга самих продуктов нет. Это делается только в тот момент, когда все понимают, что дальше это работать не будет от слова «совсем».
Помимо старых продуктов, компания занимается разработкой абсолютно новых решений с применением новейших технологий и архитектурных подходов. Но и тут не все гладко, так как общее давление со стороны потребностей бизнеса не ослабевает. Тестирование на таких проектах уже присутствует на ранних стадиях разработки, однако, все так же превалируют «ручные решения», которые дают наиболее быстрые результаты и позволяют разработчикам писать исключительно продуктовый код, не задумываясь про то, как это будет тестироваться.
Теперь несколько слов про структуру: как и сказал, в составе функции тестирования порядка 30 человек. Из них 17-19 — это младшее звено с опытом работы в этой сфере не более 1 года. Зачастую, это люди без технического образования, но с «горящими глазами» и большим желанием работать в ИТ-сфере (почему у них есть это желание — отдельная тема для рассуждений). Оставшиеся 11-13 человек — старшее и среднее звено: 3-4 человека представляют старшее и 7-10 человек — среднее. Вся функция тестирования распределена на 13-15 различных продуктов/проектов с различной степенью участия, сложности и вовлеченности.
Это последняя вводная.
К сожалению, по-прежнему существует некоторое непонимание ценности, которую может принести функция тестирования. Все потому, что результат работы в виде (например) новой фичи всем виден, понятен и практически «осязаем» — при ее реализации общее качество продукта повышается, за продукты компании становится, как минимум, не стыдно. В то же время присутствует некоторый культ разработчиков, где справедливы высказывания: «Разработчик основной игрок, и если его нет, то остальных можно уволить», а также «Разработчики — это дорогой ресурс и они должны писать только продуктовый код и не отвлекаться на неважные активности». Базируясь на этих высказывания, сформировалась некоторая «культура» в данной компании.
И, как говорится, в чем же проблема? Зачем что-то менять, если и так все работает? Зачем куда-то двигаться, если есть рабочая модель, и она приносит свои дивиденды?
Эти вопросы логично могут возникнуть у человека, который платит за всю разработку. Но есть те самые 3-4 человека в функции тестирования, которые считают себя недооцененными, которые видели первый доклад Б. Садогурского и не только, которые видят обратную сторону сложившейся ситуации и хотели бы изменить происходящее в лучшую сторону и, тем самым, решить несколько «больных» проблем.
Далее — чистая фантазия и предложения, основанные на материалах различных авторов и специалистов в ИТ-области.
Начнем с определения целей и задач в рамках изменений. Меркантильную сторону осознанно опустим и поднимать не будем, это отдельная тема для холивара, тем более она сыграла немалую роль в сложившейся ситуации данной компании.
В первую очередь, мы хотим в короткий срок получить пул качественных(!) продуктов, которые будут приносить достаточно высокую прибыль. Нужно понимать, что «прибыльный» не означает «качественный».
Что нам нужно сделать для достижения цели? Прежде всего, предлагаю рассматривать путь именно с точки зрения техники, а не коммерции. Для достижения цели требуется акцентироваться на том, что продукты должны удовлетворять потребности конечных пользователей, при этом иметь низкие затраты как на разработку новых функций, так и на сопровождение уже находящихся в продакшене. То есть, при разработке мы должны: а) четко понимать вектор движения, б) делать продукты достаточно надежными, чтобы не возникало проблем с их эксплуатацией, говоря простым языком, делать так, чтобы при работе пользователя с продуктом ошибки не возникали. Исходя из этого у нас должно существовать так называемое Zero Bug Policy на все продукты, то есть наше тестирование, как процесс, должно давать нам гарантию отсутствия ошибок продакшене.
Второй аспект — ориентированность на конечный результат всего процесса разработки, что позволит нам не разрабатывать то, чем пользователь не сможет пользоваться или не сможет понять КАК этим пользоваться. Про вторую часть упомянем только вскользь, ибо тема очень обширна, но не затронуть ее не получится.
Итак, наша цель: "Быстро, качественно и за разумные деньги" (дёшево, вероятнее всего, сходу сделать может не получиться).
Теперь попробуем соотнести то, что было дано, с намеченной целью.
Быстро. Да, возможно, но мы ставим под удар качество: существующие ручные процессы обеспечения качества смогут дать достаточную скорость исполнения только на небольших продуктах с простыми пользовательскими историями. При этом профиль компании — разработка достаточно сложных решений автоматизации бизнес процессов. Вывод — «быстро» не получается, так как ручной труд априори на больших объемах будет проигрывать любому автоматизированному решению.
Ориентация на результат. Возможно, но требует от участников генерации ценности достаточно глубокого погружения в предметную область и больших временных затрат на донесение этой ценности до конечного исполнителя. При этом исполнители — это разработчики, которые в рамках одного из утверждений должны максимально тратить время на написание кода без отвлечения на среду.
Из всего этого следует, что для решения главной задачи к процессу тестирования необходимо привлекать не только специалистов из области QA, но и разработчиков. В то же время для увеличения скорости поставки ценности необходимо более внимательно рассмотреть процессы автоматизации поставки и автоматизации проверки того, что именно поставляется.
По моему собственному мнению, основанному на опыте, требуется:
Что же нам нужно сделать, чтобы убедить участников в необходимости изменения подходов и мировоззрения?
Как аргументировать — почему им необходимо заниматься еще чем-то, кроме их любимого программирования функционального кода? Предлагаю сделать акценты непосредственно на те проблемы, которые возникают у них при такой организации. Их тут несколько:
Как разработчикам поможет тестирование или как помочь им решить обозначенные вопросы?
А что же бизнес? Почему ему должна быть интересна эта трансформация? Почему ему имеет смысл вкладываться финансами в этот подход? Выстраивая объяснение пойду тем же путем. Какие проблемы есть сейчас у этого бизнеса, какие проблемы приходиться решать при работе в ИТ-сфере и при разработке высокотехнологичных продуктов? Опять же, буду опираться тут именно на свое мнение:
Допустим, бизнес согласился с необходимостью изменений процессов и готов «купить все это сразу». Сколько это будет стоить и на какие расходы следует закладываться?
Сказать что этот путь однозначно выгоднее относительно ручного решения — нельзя, но все его преимущество раскрывается на дельтах операционных расходов и удовлетворенности конечных пользователей. Мы можем сравнить это с приобретением дорогого, но надежного автомобиля, который не требует затрат, кроме бензина и штатного ТО, и приобретение старого подержанного автомобиля. Да, цена нового выше на старте, но расходы на эксплуатацию ниже, а комфорт и «чувство спокойствия» — выше. С подержанным на старте затраты низкие, но в процессе эксплуатации затраты вырастают и уже спустя незначительное время могут сопоставляться со стоимостью первичной покупки.
Идем дальше. Не забываем наш контекст и вспоминаем состав функции тестирования.
Что же произойдет с существующей функцией тестирования? Если еще раз просмотреть состав этой функции, то с 90% уверенностью можно сказать, что 60% сотрудников из всего состава не пригодятся в новом виде функции, но есть несколько НО.
Если вы помните, что мы упоминали новые и старые продукты нашей компании. Переход новых продуктов на описанную мной модель поставки будет относительно безболезненным, так как они либо еще не в релизе, либо только-только вышли в него. В то же время, продукты давно находящиеся в эксплуатации не позволяют сходу применить подобные концепции. Это не означает, что на них надо поставить крест, там есть, что изменить, но это будет не быстро — сдвинуть процесс с мертвой точки, получить более надежные и быстрые процессы поставки.
Именно поэтому пласт функции «ручного» тестирования не перестанет существовать в одночасье, для этого придется приложить много усилий. У части «ручных» тестировщиков будет время вырасти либо в автоматизаторов, либо в QA-инженеров. Вполне очевидно, что на время этого переходного процесса функцию опоры возьмут на себя среднее и старшее звено — они наиболее вероятные кандидаты на встраивание в новые концепции прямо завтра на разных уровнях. Старшее звено, обладающее опытом и знаниями, также знакомое с концепциями автоматизации и ShiftLeft-тестирования готово выполнять роли QA-инженеров уже завтра, среднему звену на это потребуется какое-то время, но так же достаточно быстро смогут встроиться в роли или QA-инженера или инженера автоматизации.
Однозначно я еще не ответил на какие-то вопросы в этой широкой теме. Вот на какие, пока не понимаю. Жду ваших комментариев.
Дано
Для контекста (он вымышлен и любые совпадения с реальными кейсами чистая случайность) представим некоторую региональную ИТ-компанию-вендор с достаточно большим подразделением, занимающимся разработкой. В рамках этого подразделения есть функция тестирования, которая состоит условно из 30 человек различного уровня знаний и навыков.
Компания
В представленной компании есть несколько продуктов, которые долгое время находятся в релизе и начальный этап их разработки пройден более 7-8 лет назад. Учитывая, что компания является вендором, она следит за своими продуктами и регулярно их развивает, но не переделывает «с нуля». Это означает, что в продуктах содержится большое количество легаси-кода, «древних» технологических и архитектурных решений. Тестирование на этих продуктах на начальных этапах не рассматривалось, раньше их разработка велась по принципу «быстрей-быстрей и в продакшн», но сегодня в работе присутствует большой объем ручного тестирования — как регрессионного, так и тестирования новых функций. Идеологически разработка продуктов ведется под прессингом бизнесовых потребностей так, что времени на переосмысление идеологий и рефакторинга самих продуктов нет. Это делается только в тот момент, когда все понимают, что дальше это работать не будет от слова «совсем».
Помимо старых продуктов, компания занимается разработкой абсолютно новых решений с применением новейших технологий и архитектурных подходов. Но и тут не все гладко, так как общее давление со стороны потребностей бизнеса не ослабевает. Тестирование на таких проектах уже присутствует на ранних стадиях разработки, однако, все так же превалируют «ручные решения», которые дают наиболее быстрые результаты и позволяют разработчикам писать исключительно продуктовый код, не задумываясь про то, как это будет тестироваться.
Функция тестирования
Теперь несколько слов про структуру: как и сказал, в составе функции тестирования порядка 30 человек. Из них 17-19 — это младшее звено с опытом работы в этой сфере не более 1 года. Зачастую, это люди без технического образования, но с «горящими глазами» и большим желанием работать в ИТ-сфере (почему у них есть это желание — отдельная тема для рассуждений). Оставшиеся 11-13 человек — старшее и среднее звено: 3-4 человека представляют старшее и 7-10 человек — среднее. Вся функция тестирования распределена на 13-15 различных продуктов/проектов с различной степенью участия, сложности и вовлеченности.
Культура
Это последняя вводная.
К сожалению, по-прежнему существует некоторое непонимание ценности, которую может принести функция тестирования. Все потому, что результат работы в виде (например) новой фичи всем виден, понятен и практически «осязаем» — при ее реализации общее качество продукта повышается, за продукты компании становится, как минимум, не стыдно. В то же время присутствует некоторый культ разработчиков, где справедливы высказывания: «Разработчик основной игрок, и если его нет, то остальных можно уволить», а также «Разработчики — это дорогой ресурс и они должны писать только продуктовый код и не отвлекаться на неважные активности». Базируясь на этих высказывания, сформировалась некоторая «культура» в данной компании.
Постановка задачи
И, как говорится, в чем же проблема? Зачем что-то менять, если и так все работает? Зачем куда-то двигаться, если есть рабочая модель, и она приносит свои дивиденды?
Эти вопросы логично могут возникнуть у человека, который платит за всю разработку. Но есть те самые 3-4 человека в функции тестирования, которые считают себя недооцененными, которые видели первый доклад Б. Садогурского и не только, которые видят обратную сторону сложившейся ситуации и хотели бы изменить происходящее в лучшую сторону и, тем самым, решить несколько «больных» проблем.
Далее — чистая фантазия и предложения, основанные на материалах различных авторов и специалистов в ИТ-области.
Решение (возможное)
Начнем с определения целей и задач в рамках изменений. Меркантильную сторону осознанно опустим и поднимать не будем, это отдельная тема для холивара, тем более она сыграла немалую роль в сложившейся ситуации данной компании.
Рисуем картину будущего. К чему стремимся?
В первую очередь, мы хотим в короткий срок получить пул качественных(!) продуктов, которые будут приносить достаточно высокую прибыль. Нужно понимать, что «прибыльный» не означает «качественный».
Что нам нужно сделать для достижения цели? Прежде всего, предлагаю рассматривать путь именно с точки зрения техники, а не коммерции. Для достижения цели требуется акцентироваться на том, что продукты должны удовлетворять потребности конечных пользователей, при этом иметь низкие затраты как на разработку новых функций, так и на сопровождение уже находящихся в продакшене. То есть, при разработке мы должны: а) четко понимать вектор движения, б) делать продукты достаточно надежными, чтобы не возникало проблем с их эксплуатацией, говоря простым языком, делать так, чтобы при работе пользователя с продуктом ошибки не возникали. Исходя из этого у нас должно существовать так называемое Zero Bug Policy на все продукты, то есть наше тестирование, как процесс, должно давать нам гарантию отсутствия ошибок продакшене.
Второй аспект — ориентированность на конечный результат всего процесса разработки, что позволит нам не разрабатывать то, чем пользователь не сможет пользоваться или не сможет понять КАК этим пользоваться. Про вторую часть упомянем только вскользь, ибо тема очень обширна, но не затронуть ее не получится.
Итак, наша цель: "Быстро, качественно и за разумные деньги" (дёшево, вероятнее всего, сходу сделать может не получиться).
Теперь попробуем соотнести то, что было дано, с намеченной целью.
Быстро. Да, возможно, но мы ставим под удар качество: существующие ручные процессы обеспечения качества смогут дать достаточную скорость исполнения только на небольших продуктах с простыми пользовательскими историями. При этом профиль компании — разработка достаточно сложных решений автоматизации бизнес процессов. Вывод — «быстро» не получается, так как ручной труд априори на больших объемах будет проигрывать любому автоматизированному решению.
Ориентация на результат. Возможно, но требует от участников генерации ценности достаточно глубокого погружения в предметную область и больших временных затрат на донесение этой ценности до конечного исполнителя. При этом исполнители — это разработчики, которые в рамках одного из утверждений должны максимально тратить время на написание кода без отвлечения на среду.
Из всего этого следует, что для решения главной задачи к процессу тестирования необходимо привлекать не только специалистов из области QA, но и разработчиков. В то же время для увеличения скорости поставки ценности необходимо более внимательно рассмотреть процессы автоматизации поставки и автоматизации проверки того, что именно поставляется.
Что нужно сделать для решения главной задачи?
По моему собственному мнению, основанному на опыте, требуется:
- Больше погружать разработчиков в продуктовые цели их продукта;
- Убедить бизнес, что затраты на автоматизацию важны и дают больше экономической пользы при всех экономических затратах.
- Разумно автоматизировать все, что поддается автоматизации, максимально исключить ручную работу из процесса поставки ценности.
- Внедрить Zero Bug Policy, без которого пользователи будут сталкиваться с проблемами, отталкивающими от наших продуктов. Кстати, успешный пример «ДоДо» говорит о том, что это вполне достижимо.
Что же нам нужно сделать, чтобы убедить участников в необходимости изменения подходов и мировоззрения?
Разработчики
Как аргументировать — почему им необходимо заниматься еще чем-то, кроме их любимого программирования функционального кода? Предлагаю сделать акценты непосредственно на те проблемы, которые возникают у них при такой организации. Их тут несколько:
- Разработка того, что никому не будет нужно. ИМХО, это одна из первых проблем. Разработчики делают что-то, сохраняя уверенность в том, что делают это правильно, но в конечном итоге получают не тот результат, что хотел конечный пользователь. Почему? Потому что задачи и проблемы им транслируют не те, кто в конечном счете пользуются продуктом, а менеджеры или заказчики, которые впоследствии не пользуются этими продуктами. Почему так происходит? Все люди имеют различные взгляды. Если бы перед разработчиком ставилась не чисто техническая, а функциональная задача с описанием результата на выходе (а еще лучше — с описанием проблемы, которую должна решить эта задача), то понимания результата было бы больше и, как следствие, число случаев разработки чего-то ненужного бы сократились. Да, это всем известная истина, но проблема-таки не уходит, её нужно решать с бизнесом, обосновывая чуть иным способом постановки задач на разработку. О том, как донести это до бизнеса — далее.
- Необходимость переключения между контекстами. Зачастую, в процессе разработки с наличием ручного тестирования результаты тестирования запаздывают, как следствие разработчиком приходится отвлекаться на решение задач, появляющихся в итоге тестирования. Что мешает разработчикам после реализации проверять самостоятельно свой результат? Есть два момента. Первый — недостаточность знаний и навыков в области обеспечения качества. Второй — разработчики часто считают, что это не их работа, и, как следствие, не желают делать её. В одном из ранних подкастов RadioQA есть целый выпуск про разработку без тестировщиков, где достаточно подробно описан этот эффект и причины такого «нежелания».
Как разработчикам поможет тестирование или как помочь им решить обозначенные вопросы?
- Получать больше информации о предметной области или о назначении решаемых задач. Какие типичные вопросы задает разработчик при знакомстве с задачей? «Как это сделать?» «А что надо сделать тут?» «А как сделать это при том, что известно только это?» «А как это повлияет на вот ту функцию?» Все эти вопросы ориентированы на уточнение реализации поставленной задачи, а не на понимание вариативности этой задачи. Что делает тестировщик, когда знакомится с новым описанием новой функции? Он также задает вопросы, но чуть иначе: «А что будет, если?» «А почему это должно быть так?» «Что я должен получить в итоге?» «Что у меня есть в начале?» «Как это должно быть связано вот с этим?». То есть практически все вопросы нацелены на выявление именно пользовательского сценария и понимание результата работы этой функции.
Что важно? Задавая не только уточняющие вопросы (как надо реализовать), но и вопросы, направленные на понимание итогового результата, можно получить больше информации о задаче, сделать ожидаемое не только привычными методами, но и более простыми и эффективными. В позитивном сценарии это поможет не писать лишний код или создавать ровно то, что требуется конечному пользователю, что нам и нужно.
Кто-то спросит: «Почему мне, как разработчику, это должно быть интересно или я должен думать об этом?». Ответим — для того, чтобы не разрабатывать «в стол». Результаты опроса разработчиков в моем окружении показывают насколько демотивирует то, когда ты что-то делаешь, но не выпускаешь в релиз (кладешь на полку).
- Другой вопрос: «Почему мне, как разработчику, нужно заниматься тестированием, если у нас есть тестировщики?» или «Почему мне надо заниматься разработкой какого-то дополнительного кода, который не выполняет поставленных продуктовых задач?». Тут можно предложить другое. Автоматизированные тесты по своей сути все тот же код, который подчиняется все тем же законам программирования с небольшим нюансом. Когда разработчик работает в рамках большого продукта, он вынужден подчинятся правилам разработки и выбранным в рамках продукта технологиям, и писать на том языке, котором пишется этот продукт, использовать те фреймворки, которые используются в этом продукте. При написание теста это делать не обязательно: никто не заставляет использовать тот же язык или те же подходы: при реализации автоматизированного тестирования можно легко попробовать абсолютно новый язык и получить опыт работы с ним.
Есть одно простое правило, которого придерживаются разработчики при написание продуктового кода — максимальная оптимизация того, что делаешь, оптимальный расход ресурсов, оптимальная производительность, (желательно) максимальная пересипользуемость и так далее. При разработке автоматизированных тестов тоже есть правила, есть темплейты, есть свои фреймворки, но они другие. Их задача в том, чтобы дать возможность максимально быстро сделать код теста, который будет работать… Просто будет работать.
Оптимизация и скорость выполнения в автотестах — вторичные моменты и про них вспоминают далеко не сразу. Так что если вдруг есть желание попробовать с Kotlin, Java или с любым другим языком, но проект пишется совсем не на том языке, что хочется (например, на C#), можно изменить его на желаемый посредством разработки автотестов.
- «А как мне тестировать? Я же ничего в этом не понимаю. Я же просто разработчик». Тут как раз на помощь придут тестировщики, точнее QA инженеры, хорошо знающие все технологии, на которых пишется основной продукт. Благодаря имеющимся знаниям они могут помочь в грамотном обучении разработчиков тому, как и что можно протестировать, как правильно подбирать данные, что именно стоит сделать генератору данных, чтобы максимально закрыть риски по их типу и на что не стоит вообще обращать внимание. В таком тандеме тестировщики максимально используют свои знания, а разработчики не делают лишней и ненужной работы.
- «А как же скорость? Она же страдает!». Да, она будет страдать на ранних этапах разработки проектов и да, конечно, с самого начала погружаться в полную автоматизацию — дорого. Что сделать так, чтобы расходы были оптимальными? Как минимум, мы должны четко понимать как и что стоит автоматизировать. А также имеет смысл не бездумно все закрывать тестами и стремиться к 100% покрытию кода, а делать это исходя из рисковой модели. В этом то же помогут QA-инженеры.
- «Скорость! Мы хотим получать достаточно быстрые поставки. А еще хотим чтобы нам верили и наши продукты были без ошибок!». Тут предлагаю менять сам подход к разработке. Если раньше модно было все запустить в режиме отладки локально, то сейчас зачастую для серьезных приложений требуется некоторая инфраструктура для работы. Вот тут как раз хорошо подходят все новые веяния про докерезацию, про реализацию различных стендов. Важно другое: еще на этапе самой первой разработки необходимо задумываться о том, как это будет поставляться на рабочие стенды, то есть не просто все развернуть руками, а настроить автоматизированный процесс развертывания. Что нам это даст? Когда наступит время для поставки в продакшн нам будет достаточно сменить только точку выкладки, а не настраивать весь процесс с нуля. Что это даст разработчику? Больше уверенности в том, что он все делает правильно, ибо скрипты поставки проверены уже не на один круг и проблем в релизе с этим не должно возникать.
Бизнес
А что же бизнес? Почему ему должна быть интересна эта трансформация? Почему ему имеет смысл вкладываться финансами в этот подход? Выстраивая объяснение пойду тем же путем. Какие проблемы есть сейчас у этого бизнеса, какие проблемы приходиться решать при работе в ИТ-сфере и при разработке высокотехнологичных продуктов? Опять же, буду опираться тут именно на свое мнение:
- «Что больше всего может не устраивать бизнес?». Зачастую разработка забывает, что продукт нужно не только разработать, но еще и продать, для чего провести достаточно большой комплекс мероприятий, в том числе подготовить его к выходу на рынок. Делать это после того как продукт будет разработан — гарантированный провал, именно поэтому большую часть работ по подготовке каналов продаж и продвижению нового продукта начинают чуть ли не в тот же момент, когда начинается разработка.
«Что будет, если разработка опоздает к назначенной дате релиза? Или разработка выдаст на рынок недостаточно качественный продукт?» Будут убытки. Причем не только материальные, но и репутационные. Бизнесу важно быть уверенным, что к моменту старта продаж продукт будет не просто готов, а будет еще и надлежащего качества. При наличии ручных этапов тестирования в процессе разработки неминуемо потребуется либо перезакладываться на сроки, либо учитывать риски срывов на этих этапах. Прогнозировать человеческий фактор можно, но это сложно и (мое мнение) не менее дорого.
- «Что еще волнует бизнес?» Само собой, его беспокоят капитальные вложения при разработке. Но капитальные вложения, по большей части, хоть и объемные, но ведутся на начальном этапе, т.е. до выхода в релиз, или как минимум до выхода в релиз затраты не компенсируются продажами. Наряду с капитальными вложениями есть еще и операционные расходы, которые начинают вносить свою лепту уже на этапе эксплуатации и важно постараться их максимально минимизировать.
«Почему достаточно дорогая (в разрезе капитальных расходов) автоматизация в этом случае выигрывает по отношению к ручному подходу?» Мое мнение — это очевидный фактор. Автоматизация — та же разработка. При наличии ручного тестирования любое изменение в большом технологичном продукте повлечет за собой достаточно серьезные затраты по регрессионному тестированию для обеспечения гарантии того, что это изменение не внесло критических ошибок. Автоматизированные тесты, мало того, что не требуют платы регулярной зарплаты, так и предоставляют более быстрое решение, которое способно автономно выдать результат состояния системы еще до выхода к конечному пользователю. Это означает, что пользователь не потеряет доверие к качеству продукта. Почему это важно? Сошлюсь еще раз на Б. Садогурского и его прошлогодний доклад, где четко и доходчиво сказано, что «все новое нас интересует только в том случае, если мы уверены в том, что новое будет работать так же надежно, как и все старое» и, ИМХО, завоевать это доверие конечного пользователя стоит дорого.
- И последняя боль бизнеса — скорость поставки новых функций. Это та самая любовь к пользователю, то самое наше желание получить желаемое здесь и сейчас. Лично я ни один раз готов был заплатить больше за то, чтобы получить желаемое прямо сейчас, а не спустя время. И это не зависит от типа продукта, который мы потребляем.
А как происходит в разработке? Сегодня я говорю что именно я хочу, а получаю желаемое только спустя какое-то время. Причем за это я еще и должен заплатить немало. Поэтому исключение из цепочки поставки ручного труда значительно ускоряет процесс поставки, что важно конечному пользователю и, значит, важно и бизнесу. Еще раз оговорюсь, что на начальном этапе увидеть преимущества в скорости поставки будет затруднительно, ибо придется потратить дополнительное время на организацию автоматизированных процессов, зато потом, когда продукт уже доступен пользователю, эта скорость будет очевидна. То есть, любое изменение не будет занимать большого количества дополнительного времени на подтверждение качества этого изменения.
Допустим, бизнес согласился с необходимостью изменений процессов и готов «купить все это сразу». Сколько это будет стоить и на какие расходы следует закладываться?
- В первую очередь, потребуется учесть дополнительные затраты, связанные с некоторым замедлением основной разработки, что обусловлено дополнительной работой разработчиков, направленной на автоматизацию проверки качества. О чем это я: если за время X делалось Y новых функций при наличии ручных тестировщиков, то, при необходимости дополнительно закрывать ответственные места автоматизированными тестами, за то же время X будет разрабатываться Z новых функций, причем Z < Y. Но тут есть небольшая не линейная зависимость: чем больше в абсолюте будет разработано функций в продукте, тем массивнее это соотношение будет претерпевать изменение, и в определенный момент (который в каждом продукте наступает рано или поздно) это соотношение изменится в обратную сторону.
- Вторая затратная часть — это QA-инженеры. К сожалению, сложившийся образ профессии слово «инженер» немного уничтожил. Действительно, QA-инженеров мало, а те, кто есть на рынке, по своей стоимости сравнимы со стоимостью разработчиков. В то же время есть и бонус: мы не испытываем в них такую большую потребность, как при ручном подходе, так как в основном они выполняют роль экспертов в области, и, как следствие, они в состоянии своим малым количеством сопровождать большое количество разработчиков.
Откуда их брать — отдельный вопрос, на который нет однозначного ответа. Богатые компании просто их покупают. А мы, если вы помните, находимся в контексте региональной компании, вполне возможно, что и богатой, и, вполне возможно, готовой купить таких инженеров, но их просто нет в той локации, где находится компания. И это отдельная проблема.
- Автоматизированные тесты — следующий вектор затрат. Это достаточно специфичная область разработки, текущие разработчики могут не владеть ей, и подобных специалистов также придется воспитывать или нанимать. Так как это, по своей сути, все те же разработчики, мы опять сталкиваемся с затратами, сравнимыми с наймом разработчиков. Бонус у них такой же, как и QA-инженеров. Они могут быть как включены в команды разработки, так и существовать в виде выделенного подразделения. В случае, если они выделены в отдельную группу, такая группа может работать как «спецназ» — заходить на продукт, закладывать основной вектор и архитектуру, затем передавать его продуктовой команде на развитие и поддержание, а сама переходить на другой продукт. Подобный сценарий спорен и не факт, что самый эффективный, но реально способный к существованию.
- Ну и последний, как мне кажется, вектор затрат — это оборудование и материальная база (хотя, вполне возможно, я что-то еще не учитываю). При организации автоматизации нам понадобятся дополнительные затраты на организацию тестовой и демонстрационной инфраструктуры. Не все же делать в бою, хотя и такая практика применима при наличии достаточного количества оборудования в бою. Кроме того, нам понадобится выделять для продуктовых команд разработки ресурсы для отладки процессов поставки, прогона автоматизации, а, в некоторых случаях, закупаться дополнительным клиентским оборудованием (мобилки), тратить дополнительные средства на профессиональные среды оркестрации и управления всем этим окружением.
Сказать что этот путь однозначно выгоднее относительно ручного решения — нельзя, но все его преимущество раскрывается на дельтах операционных расходов и удовлетворенности конечных пользователей. Мы можем сравнить это с приобретением дорогого, но надежного автомобиля, который не требует затрат, кроме бензина и штатного ТО, и приобретение старого подержанного автомобиля. Да, цена нового выше на старте, но расходы на эксплуатацию ниже, а комфорт и «чувство спокойствия» — выше. С подержанным на старте затраты низкие, но в процессе эксплуатации затраты вырастают и уже спустя незначительное время могут сопоставляться со стоимостью первичной покупки.
Идем дальше. Не забываем наш контекст и вспоминаем состав функции тестирования.
Тестировщики
Что же произойдет с существующей функцией тестирования? Если еще раз просмотреть состав этой функции, то с 90% уверенностью можно сказать, что 60% сотрудников из всего состава не пригодятся в новом виде функции, но есть несколько НО.
Если вы помните, что мы упоминали новые и старые продукты нашей компании. Переход новых продуктов на описанную мной модель поставки будет относительно безболезненным, так как они либо еще не в релизе, либо только-только вышли в него. В то же время, продукты давно находящиеся в эксплуатации не позволяют сходу применить подобные концепции. Это не означает, что на них надо поставить крест, там есть, что изменить, но это будет не быстро — сдвинуть процесс с мертвой точки, получить более надежные и быстрые процессы поставки.
Именно поэтому пласт функции «ручного» тестирования не перестанет существовать в одночасье, для этого придется приложить много усилий. У части «ручных» тестировщиков будет время вырасти либо в автоматизаторов, либо в QA-инженеров. Вполне очевидно, что на время этого переходного процесса функцию опоры возьмут на себя среднее и старшее звено — они наиболее вероятные кандидаты на встраивание в новые концепции прямо завтра на разных уровнях. Старшее звено, обладающее опытом и знаниями, также знакомое с концепциями автоматизации и ShiftLeft-тестирования готово выполнять роли QA-инженеров уже завтра, среднему звену на это потребуется какое-то время, но так же достаточно быстро смогут встроиться в роли или QA-инженера или инженера автоматизации.
Однозначно я еще не ответил на какие-то вопросы в этой широкой теме. Вот на какие, пока не понимаю. Жду ваших комментариев.
