Было время, когда в разработке требовалась специализация. В книге «Как мы тестируем в Microsoft» мы рассказали историю первого тестировщика в Microsoft — его наняли для запуска игр, написанных на Basic, через новый компилятор. В тот момент разделение между тестированием и разработкой было сформировано (поначалу неглубоко).
Спустя годы в книге Проект Единорог Джина Кима (и непосредственно в его Руководстве по DevOps) рассказывалось о стене между разработчиками и операционными специалистами и демонстрировалось, как разрушение этой стены ускоряет доставку.
Стена
Я не одинок в своей ненависти к термину DevOps. Потому что DevOps — это не то, что люди делают, а то, как люди работают. DevOps возник как термин, описывающий сотрудничество разработчиков и операционной команды, о котором, как помню, шла речь в презентации 2009 года “10+ деплоев в день — сотрудничество Dev и Ops на Flickr”.
Концепция простая: сотрудничество и взаимодействие намного эффективнее, чем перебрасывание материала через стену другой команде.
Те из вас, кто работал на должностях, связанных с тестированием, могут увидеть здесь параллель. Тот самый первый тестировщик в Microsoft вырос в целую армию тестировщиков. В середине 2000-х годов в Microsoft насчитывалось около 10 000 тестировщиков, и хотя они участвовали в процессах на ранних этапах цикла создания продукта, и сотрудничали (в разной степени) с командами разработчиков, в компании было много излишнего «перебрасывания через стену».
Сейчас руководство крупных организаций уже понимает, что такие перебрасывания замедляют скорость и увеличивают риски. Там осознают, что теперь им нужно гораздо меньше тестировщиков. Доказано, что тестирование силами разработчиков (Developer owned testing, возможно с привлечением экспертов по тестированию) имеет высокую корреляцию с качеством и скоростью доставки.
Аналогичным образом, развитие культуры DevOps привело к появлению центральных команд platform engineering или developer experience, которые создают основу для инструментов и автоматизации, а также при необходимости предоставляют экспертизу, облегчая командам разработчиков работу с облачными сервисами и приложениями.
Еще в 2006 году Вернер Фогельс пропагандировал культуру You Build It, You Run It:
Наделение разработчиков операционными обязанностями значительно повысило бы качество услуг как с точки зрения клиента, так и с точки зрения технологий. Традиционная модель заключается в том, что вы подносите свое программное обеспечение к стене, разделяющей разработку и эксплуатацию, перебрасываете его через нее и забываете о нем. Но только не в Amazon. Вы создаете что-то, и вы этим управляете. Таким образом, разработчики вступают в контакт с повседневной работой своего программного обеспечения. Кроме того, они ежедневно общаются с клиентами. Такая обратная связь с клиентом необходима для повышения качества услуг.
Есть много вещей, которые мне не нравятся в Amazon, но вот это нравится, и именно поэтому я верю (и убедился), что разработчики, владеющие тестированием, улучшают доставку.
Нытик
Данные об этом уже накапливаются. Хорошие команды разработчиков оптимизируют эффективность и качество, сокращая количество перебрасываний через стену, и владея доставкой своего продукта. Но (как я видел в комментариях, когда делал подобные заявления) есть разработчики, которым плевать на эти данные, потому что они «не хотят заниматься тестированием» и «не хотят заниматься DevOps».
Эти люди тупые, у них фиксированный образ мышления.
В книге «Mindset» Кэрол Двек рассказывает об этом. Она говорит, что подход людей к обучению и вообще к проблемам определяется либо фиксированным мышлением, либо мышлением роста. Люди с фиксированным мышлением считают свои способности фиксированными и врожденными. Такие люди избегают вызовов, потому что чувствуют угрозу неудачи. А люди с мышлением, ориентированным на рост, воспринимают препятствия как возможности для обучения.
Если данные говорят, что разработчикам полезно больше заниматься тестированием и операциями, а вы отвечаете: «Это не моя работа» — ваш личностный рост будет ограничен, как и ваша карьера.
Работник (и ученик)
За свою карьеру я провел множество собеседований с людьми, претендующими на должности в сфере IT-технологий. Суперсекретный прием, который я использовал, чтобы найти хороших кандидатов в долгосрочной перспективе — сосредоточиться на обучении и майндсете. Если вы хотите добиться успеха в IT, да и в любой другой работе, связанной со знаниями, любовь к обучению и бесстрашие перед новыми вызовами в значительной степени коррелируют с долгосрочным успехом. Обратное тоже верно.
В течение многих лет я помогал организациям научиться работать с меньшим количеством тестировщиков. Я помогал командам разработчиков научиться пользоваться продуктом, который они создают (или, как выразился Брайан Финстер, «сам запускай то, что ты принес»). Я добивался в этом неизменного успеха, но случались конфликты.
Иногда разработчики не хотят учиться тестированию, или работе с сервисами, потому что считают, что они выше этого и это «не их работа». Они не верят данным и отказываются меняться. Поначалу. Начать с небольших изменений (например, юнит-тестов или интеграционных) или создать пару с тестировщиком на развертывании — это начало. Постепенно меняться, и результаты будут очевидны.
Чаще всего причиной синдрома «не хочу» (и «это не моя работа») является страх. Разработчики боятся тестирования, потому что боятся, что могут пропустить баг (между тем, тестировщики преодолели этот страх десятилетия назад). Разработчики боятся запускать свои собственные продукты, потому что боятся, что они каким-то образом разнесут весь интернет или нанесут другой непоправимый ущерб?
В основном они боятся пробовать что-то новое.
Когда тестированием и развертыванием занимается какая-то другая команда, многие разработчики переоценивают сложность тестирования.
Я много раз убеждался в том, что небольшой сеанс парного тестирования с передачей знаний быстро дает любопытство и повышение качества. Я видел, как разработчики становятся лучшими тестировщиками, чем 95 % тестировщиков, которых я знал за свою карьеру.
Кто-то на Linkedin как всегда несогласен, но я утверждаю, что простое предоставление разработчикам разрешения тестировать и использовать свои продукты — это путь к росту и зрелости.
Победа
Я не призываю все компании избавляться от тестировщиков или групп platform engineering. Экспертиза — это хорошо, но будьте осторожны, так как она может стать узким местом. Вы не хотите, чтобы команды разработчиков зависели от других команд; вместо этого команды тестировщиков, команды platform teams и dev experience должны улучшить способность этих команд выпускать качественное программное обеспечение.
Ваша QA-команда существует для того, чтобы помогать другим командам лучше тестировать — а не для того, чтобы делать за них 100% тестирования.
В общем, учитесь, развивайтесь и создавайте хорошие продукты.»
