Хабрахабр

У нас DevOps. Давайте уволим всех тестировщиков

Можно ли автоматизировать всё, что угодно? Потом всех тестировщиков уволим, конечно. Зачем они теперь нужны, «ручного» тестирования не осталось. Правильно ведь?

Здесь будут конкретные цифры и чисто практические выводы, как так получается, что у хороших специалистов всегда есть работа. Это рассказ о будущем тестирования с точки зрения DevOps. Глядите на фотографию Шекспира и бойтесь, сейчас будет решаться ваша судьба). (Или нет работы!

Текстовая версия и видео доклада — под катом.
В основе материала — расшифровка доклада Баруха jbaruch Садогурского, Developer Advocate в компании JFrog.

Видите цитату из Шекспира на картинке чуть выше? Всем привет! Сами понимаете, с тех пор у нас более вегетарианские способы избавляться от неправильных профессий. Это «Генрих VI», предложение убить всех адвокатов. Убивать мы никого не будем, просто возьмем и всех уволим.

Станем ли мы кого-то увольнять — давайте поговорим. Точней, есть такая возможность.

Как-то утром он приходит на работу и проходит мимо самой главной переговорки. Это Вася. Консультант по эффективности приходит в компанию и говорит: «Мы будем делать DevOps как в netflix*. А там его шеф приветствует нового консультанта. Мы специально летали в Кремниевую долину на конференцию, и там нам рассказали, как делают в netflix».

Это использование носит нарицательный характер. * дисклеймер: в этой статье часто используется фирма Netflix как недостижимый идеал DevOps.

Обсуждение того, действительно ли в фирме Netflix идеальный DevOps, выходит за рамки этой статьи (скорее всего, кстати, нет).


Они ставят Spinnaker, потом запускают Chaos Monkey, и все автоматизируют. И мы так будем делать и будем очень эффективными.

«А у нас как в нетфликсе — freedom и responsibility. Шеф спрашивает, а как же тестировщики. Разработчики будут сами писать тесты».

И тут Васе становится нехорошо, потому что он смотрит на свою визитку, а там…

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

Но, конечно, тут Вася просыпается.

Редактор этой статьи специально попросил написать пару абзацев, чтобы никто не сомневался в моих полномочиях рассказывать, как мы будем увольнять тестировщиков. Меня зовут Барух Садогурский, я Developer Advocate в компании JFrog.

Мы официально unicorn, и мы занимаемся автоматизацией DevOps. Компания JFrog – это стартап в Кремниевой долине, последняя наша оценка была более миллиарда долларов. Наши продукты – Artifactory, Xray, Mission Control и так далее – инструменты для той самой автоматизации, превращающий омский мясокомбинат в netflix.

В программке конференции, на которой изначально читался этот доклад, есть специальное обозначение — картинка с бутылкой с зажигательной смесью. Я сам не тестировщик, поэтому, возможно, буду рассказывать какую-то чушь. Это про меня. Значит, докладчик собирается нести какую-то ересь, и у слушателей будет подгорать. Как вы уже поняли, я очень веселый парень, меня надо срочно зафолловить. В твиттере я @jbaruch.

Разработчикам устраивают всякие опросы. У меня для вас есть новости: 80% разработчиков пишут тесты. Там спрашивают, кто пишет юнит-тесты. Вот нам компания JetBrains устраивает очень хороший State of Developer Ecosystem Report.

  • 59% пишут сами,
  • 11% видят в своем коде юнит-тесты и не знают, откуда они приходят.

Итого 70% разработчиков пользуются юнит-тестами. Это круто.

Согласно нему: Есть более углубленное исследование компании Hubstaff о тестировании с помощью разработчиков, оно чуть-чуть постарее – 2014 года.

  • 85% разработчиков пишут юнит-тесты,
  • 15% нет;
  • 40% работают по методологии test-driven development;
  • хорошее покрытие – между 34 и 66 у 31% разработчиков.

Подавляющее большинство разработчиков утверждают, что они еще и ручками что-то тестируют. Врут, конечно, но статистика такова.

Включая, естественно, омский мясокомбинат, на котором Вася работает. Начиная с 2011 года наша самая любимая цитата: «Every company is a software company». Что хотят компании? Везде есть софт и все на этом софте пытаются зарабатывать. Откуда берутся деньги? Грести бабло лопатой. А что хотят клиенты? От довольных клиентов. А когда они хотят новых фич? Новых фич. Сейчас!

Он тоже слушал всякие интересные доклады. CEO из комикса Dilbert — начальник начальника Васи. Логично. Он считает, что если клиенты хотят новых фич — значит, нужно новые фичи чаще релизить. Для этого нужно уменьшать трение в командах.

Например, в 2017 году Java перешла на более частые релизы, потому что все хотят фичи и, казалось бы, надо релизить побыстрее. Надо ли чаще релизить? Но никто ее не использует. Каждые полгода выходит новая Java.

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

Картинка не изменилась: 80%, а то и больше, всё ещё сидят на Java 8, которая вышла сто лет назад. У нас недавно был Joker, мы на нем устраивали Java Puzzlers. Ни девятую, ни десятую, ни одиннадцатую не берет никто.

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

Как мы ставим апдейты

Мы хотим этого? Приходит уведомление, что у нас есть апдейт, давайте поставим новую операционную систему. Там есть что-то полезное или у нас кассовый аппарат, который работает на Windows 98 Embedded, и больше нам ничего не надо?

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

Это было раньше, а сейчас мы уже боимся обновляться, нет былого доверия. С компанией Apple раньше не было проблем: есть новая операционная система – давай возьмем. Если же не доверяем – нужно тестировать. Если мы доверяем – нет проблем, обновляемся.

Вот нам сообщают: вышла новая Java, и к примеру, мы — компания Baidu. Мы делаем то, что называется приемочные тесты (acceptance tests). Мы берем какую-то часть серверов, начинаем менять Java. Хайлоад, 100500 серверов, клауд, JVM везде. Раз в три года нормально, но раз полгода… Вы что, охренели? Куче инженеров приходится что-то сделать и всё это проверить. Конечно, мы не будем брать эту вашу новую Java. Мы только проверять её полгода будем.

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

Если вопрос доверия решен, то с апдейтами проблем нет. Проблема именно в доверии. Если мы не доверяем, то обновляться будет тяжело. Или у нас есть фича, или нам наплевать.

Он, начиная с какой-то версии, апдейтится вообще никого не спрашивая. Возьмите Chrome. Но с другой стороны, мы доверяем тем, кто Chrome пишет. Риски там небольшие, но все-таки есть. По сути, у нас нет проблем с доверием, и мы идем по этому пути. Чаще всего, когда выходит новый релиз Chrome, ничего там не ломается.

А еще нас не будут спрашивать, хотим мы или нет, поэтому мы всегда будем апдейтить. У нас есть апдейт, риски не важны, доверяем – апдейтим. Именно так это и делается.

Крутой апдейт? Представьте, netflix выкатывает новый апдейт, и теперь мы можем пропускать не только титры и заставку, но и все скучные места. Мы его хотим? Крутой. Он будет работать? Хотим. В крайнем случае мы пойдем на YouTube, мультики посмотрим, если netflix сломался. Скорее всего, да.

Как мы его решаем? Вопрос доверия тут критичный. Мы написали книжку, которая советует, как решать эту проблему. Под словом «мы» имеются в виду два сооснователя JFrog, Фред Саймон (Fred Simon), Йоав Ландман (Yoav Landman) и ваш покорный слуга.

Он спрашивает у консультанта, как мы будем чаще апдейтить. Допустим, мы уговорили нашего CEO, он прочитал Liquid Software, и теперь он понимает, зачем ему апдейт. DevOps! Agile! А что такое DevOps?

DevOps

Давайте я вам расскажу немного теории, что такое DevOps, поскольку мы на этом зарабатываем. Взгляните на картинку, у нас были вот эти группы, команды, отделы:

И еще посередине между разработчиками Ops есть QA, которые тестируют.
Есть разработчики, есть Ops — сисадмины, которые берут то, что разработчики написали, и выкидывают на прод. Для этого у нас были отдельные отделы. То есть, разработчики сели, написали, потом отнесли тестировщикам, потестировали, отнесли сисадминам, и они на прод залили.

На английском этой прелести нет, поэтому эти разные отделы называются silos. Русский язык прекрасен: отдел всегда отдельный, это корень слова. Он называет silos «колодцами». Лучший перевод этого слова на русский привел Антон Вайс, который был лучшим докладчиком DevOops. Чтобы туда загрузить какую-то работу, нужно спуститься, а потом вытащить оттуда работу – подняться. Разные отделы – глубокие колодцы. Как мы группируем вещи, которые из колодца достаем? Удобнее всего делать это группами.

То есть, у нас есть такие «ведра работы». Естественно, ведрами. Разработчики что-то в колодце написали, мы это загрузили в ведра, достали это из колодца, отнесли ведра тестировщикам, спустили к ним в колодец.

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

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

Я не виноват! У нас есть такие инженеры, которые и швец, и жнец, и на дуде игрец. Теперь у нас все делают всё. Он и код пописал, и потестировал, и потом еще и на продакшн все это выложил – такой вот единорог. Это Dev, QA и Ops.

В том, что они не существуют. В чем проблема единорогов? Поэтому нам остается делать смесь. А те, которые существуют, их уже давно netflix нанял.

Смесь


У нас есть общая культура, общие цели. Мы вышли из колодцев, мы теперь все вместе, но у нас осталась глубокая специализация. Разработчик все-таки больше разработчик, чем Ops, а тестировщик — больше тестировщик, чем разработчик. Но тем не менее, они понимают все. Они понимают, что они делают, зачем они это делают и как оно работает.

То есть у нас появляются T-shaped people, «люди в форме буквы T».

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

DevOps — это:

  • Культура того, что у нас теперь есть общие цели, мы понимаем, что мы делаем вместе.
  • Автоматизация, чтобы релизить чаще.

Скорость и качество

Давайте поговорим про предположение о том, что существует обратная зависимость скорости и качества. Грубо говоря, чем быстрее мы будем релизить, тем хуже получится качество. И наоборот: если мы не будем спешить, то успеем все хорошенько потестировать. У нас трейд-офф!

Для того, чтобы понять, действительно ли эта зависимость существует, обратимся к научным трудам и поговорим о докладе State of DevOps от организации DORA. Я вам очень рекомендую в этот доклад хорошенько посмотреть.

В докладе говорится о том, что за пять лет опрошено больше 30 000 человек, а в 2018 году почти 2000 человек. Насколько ему можно доверять? Поэтому исследованию можно доверять. Это очень большая выборка и на основании такого количества, например, делают прогнозы на выборах в США.

Давайте посмотрим, что же DORA нам расскажет про эту обратную корреляцию. Кроме того, Николь Форсгрен, возглавляющая DORA, в отличие от нас, — ученый, поэтому там все серьезно.

Во-первых, они поделили всех опрашиваемых на три группы: Low performers, Medium Performers и High Performers.

Это Netflix (на самом деле нет, смотри дисклеймер выше). Кроме того, есть еще Elite.

Естественно, пять лет назад было намного больше Low Performers, сейчас намного больше High Performers, ведь мы уже начинаем немножко понимать, что мы делаем.

Это как-то странно. Как вы видите, пропорции меняются. Почему? Оказывается, Medium тестируют ручками больше, чем Low. Да потому, что Low вообще ничего не тестируют.

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

Чем быстрее мы релизим, тем лучше у нас качество. Но дальше корреляция не только не обратная, она прямая. Все неплохо, но медленно, потому что мы верим в то, что если не будем спешить, то и протестируем всё получше. Допустим, мы Medium и тестим ручками. А тестировщики нам не нужны. Потом приходит консультант от DevOps и говорит: «Всё, теперь автоматизируем. Всё отлично».

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

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

Нам нужно ответить на вопрос, как жить без ручного тестирования. Что же меняется? Очевидно, можно.

Он сидел и ждал, пока разработчики закончат писать. Раньше у нас был сисадмин, который выкатывал продукт на прод. Что в это время происходит со всеми остальными? После этого он брал этот продукт и шел CD-ROM вставлять и провода втыкать. Это бутылочное горлышко, затык. Все остальные ждут.

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

У нас есть тестировщики, которые тестируют продукт. То же самое с тестированием. Написали — пора тестировать. Они ждут, пока им напишут продукт. Ничего не делают, сидят ждут. Что делают все остальные, пока они тестируют? Как мы это решаем?

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

  • Для этого нужны, например, кроссфункциональные команды. Вот мы из колодцев поднялись и сели вместе. Теперь у нас лев возлежит с овцой, и тестировщик работает вместе с программистом.
  • Мы делаем Continuous Testing. Это как автоматизированное тестирование, но умнее.
  • В процессе разработки делается «брейнуальное тестирование». Это более правильный термин, чем «мануальное тестирование», потому что мануальное тестирование — оно про мозг, а не про руки. Спасибо за этот термин моему близнецу в Фейсбуке Алексею Виноградову. Брейнуальное тестирование происходит в процессе разработки. Как только появляется что-то, уже можно проверить его flow, уже можно понять, как оно работает, уже можно начать намечать какие-то corner cases, которые мы потом заавтоматизируем.
  • Мы теперь следим за разработчиком. Если он сначала не написал тест, мы ему можем дать подзатыльник. Это Test Driven Development.
  • Важен моментальный фидбэк. У нас должен быть пайплайн, который сразу же нам говорит, как только что-то сломалось. Потому что мы сразу же должны пойти и это моментально починить.
  • Участие в дизайне. Бывает такое, что вы смотрите на что-то и думаете, как мы это говно теперь будем тестировать. Но извините, а где вы были, когда все решили, что будет говно? Вы приходите на совещания и говорите, что вы не согласны, надо делать неговно. Надо участвовать в дизайне, чтобы гарантировать, что потом вы сможете это протестировать.
  • Инструменты, обвязки, стенды — то, что многие из вас делают сегодня, никуда не уходит. Наоборот, этого будет больше. Соответственно, это кто-то должен писать.
  • Chaos engineering. Вы всегда мечтали запустить Chaos Monkey в продакшн, особенно если у вас есть сеть банкоматов на Windows 95. Вот ваш шанс.
  • И наконец, нужно учить неучей дизайнить тесты. Мы же решили, что разработчики по крайней мере утверждают, что они пишут тесты. Вот теперь пусть пишут тесты, только надо их научить это делать. Кто их будет учить, откуда они знают, как писать тесты? Только вы. Больше некому.

Осталось все заавтоматизировать. На самом деле, мы умеем автоматизировать тестирование. Проблема в том, что автоматизировать можно определенную часть.

Вы все знаете этот анекдот про то, как тестировщик заходит в бар, заказывает пиво, заказывает 0 пива, заказывает 99999999999 пива, заказывает ящерицу, заказывает -1 пиво и заказывает… Вот тут баг, потому что это должно быть asdfgh, а не вот эта фигня.

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

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

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

Вот у них «брейнуальное тестирование», они могут подумать, что в баре нужен туалет. Те, кто умеет делать что-то одно очень хорошо. А есть такие, которым дай Selenium упарываться. Ну, не каждый может, но есть такие, которые могут. Не вопрос, но нужно понимать и все остальное.

Поговорим о том, как делать эту трансформацию.

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

Им можно объяснить, как правильно тестировать. Developers in test — их девелоперский бэкграунд очень полезен, потому что они понимают, как думают окружающие. Те, кто сейчас в тестировании и имеют девелоперский бэкграунд, бесценны для этого общения. Участие в дизайне, чтобы сделать тестируемым ваш продукт; евангелизм — как правильно тестировать, о чем речь; внедрение TDD объясняет, какое покрытие имеет смысл, а какое нет, какие тесты имеют смысл, а какие нет.

Казалось бы, мы их уже отправили на покой и решили, что они не нужны, но это не так, потому что понимание продукта, понимание бизнеса — критический скилл. «Брейнуальные тестировщики». Эти ребята сейчас поднимаются на верхний этаж, где сидят все самые крутые перцы, и начинают им втирать про тестирование, влиять на архитектуру, понимать продакт, участвовать в совещаниях с бизнесом и приносить свою экспертизу в понимание, как правильно тестировать, в архитектуру продукта, в тестируемость продукта, евангелизм, как важно делать Continuous Testing и глобальное видение.

Поэтому заголовки о том, что сотни тестировщиков были уволены, когда все перешли в DevOps, этого нет и не будет. Для всех этих end-to-end тестирований гигантских систем идеальны ребята, которые были мануальными тестировщиками.

Сегодня есть такие бородатые ребята, сисадмины закалки 70-х годов: «Никакого DevOps, мы будем ручками настраивать сервера». Безусловно, кто-то не захочет меняться, это нормально. Даже они не безработные, потому что существует огромное количество систем, в которых они нужны.

Если есть кто-то, кто хочет делать мануальное тестирование, и все, что я сейчас рассказывал, им совершенно неинтересно, работа есть. То же самое с тестировщиками. Приведу пример: мы вчера с Леонидом Игольником ( EVP Engineering, SignalFx) летели из Мюнхена, и выяснилось, что билет Леонида пропал в черную дыру между системами заказов Люфтганзы и системами заказов Юнайтед.

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

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

Ну какой же доклад без цитаты от Леонида. Мы приближаемся к концу, и тут я вспомнил Леонида. «Важно лишь то качество, которое видит клиент», — сказал мне однажды Леонид, мудро почесав бороду, за ужином.

— Мы только что полчаса обсуждали вот это все: процессы, стабильность, то, се. «Секундочку, — сказал я Леониду. Так давай вообще ничего не будем делать. И ты мне тут говоришь, что клиенту глубоко наплевать, что у нас происходит, лишь бы та фича, в которой он заинтересован, работала. Зачем это все втирать? Вот у нас есть ручное тестирование, мы что-то там проверили, она работает и достаточно. Artifactory пришел продавать, засранец?!».

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

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

Обратите внимание, что New Work у Low — 30%, у Medium — 40%, у High и Elite — 50%. Нам нужен New Work. Половина времени (это практически в два раза больше, чем у Low) освобождается, чтобы творить, делать новые фичи.

И это очень и очень круто.

Баруха не обещаем, но будет много других интересных спикеров. Это доклад с конференции Heisenbug 2018 Moscow, состоявшейся в декабре — а 17-18 мая в Петербурге пройдёт следующий Heisenbug. Посмотреть на программу можно на сайте конференции, приобрести билеты там же (и с первого апреля цены на билеты повысятся).

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть