Вы говорите разработчикам, что теперь на каждую задачу надо писать автотесты. Они кивают, ведь и сами давно об этом говорят. Но когда очередная задача приходит в тестирование – тестов нет.
Вы просите аналитиков описывать проблему пользователя в каждой задаче. Они соглашаются, ведь это поможет тестировать, а значит, улучшит качество их любимого продукта. Но когда очередная задача приходит в тестирование – описания проблемы нет.
Вас просят проверять прогоны автотестов перед каждым релизом. Вы радостно поддерживаете эту идею, ведь вы любите автотесты. Но через неделю на летучке все обсуждают, что в мастере уже три дня падает один из тестов и никто этого не замечал.
Что это? Саботаж? Немая забастовка? Инфантильность? Мой ответ – это наш мозг.
Аттеншн – занудство и теория
Уже несколько лет из каждого утюга кричат про модель психики, придуманную Канеманом и описанную в книге “Думай медленно… решай быстро”. Канеман разделил мозг на две системы:
быструю, автоматическую, принимающую решения “подсознательно”, без значительных интеллектуальных усилий, и
медленную, “рациональную”, ответственную за принятие сложных решений.
Еще быстро вспомним, что мозг от природы ленивый и старается не тратить силы зря, а значит по умолчанию активна быстрая система.
Сейчас самое время задать вопрос – И чё?
Аттеншн – субъективные выводы
А теперь возвращаемся к ситуациям из начала статьи. Представим, что происходит в голове всех этих “вредителей”.
Разработчик написал код по задаче. Перечитал постановку, убедился, что ничего не забыл. Запустил приложение локально (надеемся) и проверил, что основной сценарий работает. Выдыхает, закрывает задачу, вводит потраченное время и идет в бэклог выбирать новую задачу. Всё на автомате, ведь он работает по этому сценарию последние 2.5 года.
Аналитик читает запрос от пользователей, исследует существующую систему, продумывает решение и аккуратно вносит изменения в ТЗ. В его голове загружено решение проблемы, именно этим он занимался всё последнее время. И именно это вносит в задачу, автоматически.
Ну вы поняли.
Аттеншн – непрошенные советы
Как можно с этим бороться? Я предлагаю намеренно подключать систему 2 в тех случаях, когда вам нужно вывести человека из автопилота. Делаю это либо через фокусирование внимания, либо через создание преград. На примерах:
Тестирую задачу – вижу отсутствие багов, не вижу тестов – переоткрываю задачу. Это создает неудобство разработчику, раздражает, представляя негативную мотивацию. Плюс при переключении на эту задачу он выйдет из автопилота и подключит рациональную систему. Вероятность того, что действие “написать тесты” войдет в автоматическую цепочку выше, т.к. разработчик стремится избежать неприятных эмоций от переоткрытия, и явно обращает на это внимание.
Создаем шаблон тикета и добавляем пункт о проблеме пользователя. Теперь при написании постановки аналитик точно обратит на это внимание, выйдет из автоматического режима заполнения задачи “по привычке”. А через пару итераций это станет новой привычкой.
Создаем задачу на релиз, в которой прописываем все необходимые действия, включая прогон автотестов. Отключаем автопилот, подключаем внимательную систему 2, не оставляем шансов “забыть” (ну и стабилизируем тесты, чтобы отбить привычку игнорировать падения, но это тема другой статьи).
Короткий вывод
Другие люди искренне готовы меняться ради улучшения качества продукта. В саботировании нововведений виноват автопилот, с ним и боремся. А людей любим и бережём. Всем бобра.
mirwide
Люди ленивые, мозг молодец:) Всё будет делаться по пути наименьшего сопротивления и максимальной выгоды для себя. У Вас получается разработчику лень писать тесты, а qa не лень возвращать задачу и получать негатив в ответ. Странное и не сработает. Шаблон будет скинуться если есть возможность. Ни какая организационная мера не сработает долгосрочно, о ней нужно регулярно напоминать, как-то проверять, мотивировать. Гораздо проще делать технические ограничения, автоматически проверять покрытие кода тестами и запрещать мержить если нужный порог не достигнут.
Альтернатива, которая будет работать, поощрять рублём за качество кода, но это совсем фантастика.
vassabi
кстати, интересно была бы геймификация этого процесса, т.е.
1) иметь автомат по проверке качества (мне например понравился SonarQube - он непохо ставит оценку % покрытия кода тестами)
2) ставить 1 звезду за покрытие 80% , 2 звезды - за 90%, 3 за 95%, 4 за 98% и 5 - за 100%
4) ставить оценку PR тоже в звездах (можно в обе стороны - автор ревьюверу, и ревьювер автору)
5) делать ежемесячный топчик по категориям звезд за предыдущие три месяца (т.е. берется скользящее среднее за 3 месяца), топ10 - топ3 (смотря какой у вас бюджет) "поощрять рублем" ( + "победитель рейтинга" пропускает следующий месяц, чтобы не было серии :) )
6) трекать конфликты (когда кто-то жалуется что ему занижают оценки или что есть "клика накрутчиков")
но т.к. это все сложно для менеджмента, то разумеется фантастика :D
mirwide
Выглядит как рабочая схема
zloddey
Выглядит как г**но, извините. Идеальный способ демотивировать разработчика, чтобы он вообще перестал что-либо делать полезное.
Scarethebear Автор
Код можно покрыть бесполезными тестами, достигнуть 100% покрытия и считать себя молодцом, потратив время впустую.
Моя идея была в другом. Разработчику не лень писать тесты, он просто не привык. А тестировщик хочет, чтобы привык. И для этого пытается выключить автопилот разработчика. Тестировщику не лень, потому что он является заказчиком изменений, для него это важно.
mirwide
Непонятно. Если код проверяет SonarQube или аналог, разработчик становится вредителем и пишет фиктивные тесты, а если qa то начнет писать сам без напоминания и хорошие, даже покрытие проверять не нужно. Логические нестыковки. Думаю, что условный SonarQube проверит код лучше чем среднестатистический qa, да еще и исключен человеческий фактор и экономия рабочего времени. А qa, раз ему не лень, пусть сам пишет тесты :))
vassabi
что такое бесполезные тесты? мы же не в штуках меряем, а в % покрытия кода.
100% покрыли - значит норм.
не, я понимаю, что в идеале нужно тестировать краевые условия и т.д. , но давайте быть реалистами - не всегда пишут тесты, которые просто проверяют что при вызове функции Ф с нужными параметрами она не вызовет исключение, а не то что какую-то умную логику проверки ...
При том, что такой примитивнейший тест уже хотя бы как-то фиксирует АПИ (а не убрали параметр, добавили параметр, и все тесты зеленые, потому что никто не проверил - в продакшен!)
zloddey
"Нет привычки писать тесты" - это только вершина айсберга. Реальных причин может быть гораздо больше, и работать с ними надо по-разному. Перечислю наиболее типичные варианты:
У разработчика не срабатывает триггер "пора писать тесты" в тот момент, когда это делать эффективнее всего - в самом начале работы над задачей. Человек может не знать о существовании TDD либо не иметь практического опыта в нём. А когда задача завершена, делать для неё ещё и тесты кажется лишней работой. Привычка лучше всего нарабатывается через целенаправленные тренинги (см. code kata, code retreat).
Разработчик вспоминает про тесты, но понимает, что ему не хватит на них времени. Тесты требуют заметного времени на написание, запуск, отладку и подчистку. При наличии прессинга со стороны менеджмента ("мы должны делать всё быстрее") написание автотестов может являться невыгодной стратегией. Особенно если у разрабов мало опыта в этом деле. Поможет только снятие или ослабление прессинга.
Разработчик вспоминает про тесты и даже пытается писать их, но код написан в стиле, который "сопротивляется" тестированию. Например, бизнес-логика и работа с внешними системами (системное время, многопоточность, БД, сеть, диск и т.п.) сильно перемешаны друг с другом. Или код пронизан взаимосвязями без чёткой структуры. Обычно такой код как раз и бывает в системах, которые писали без автотестов. В итоге, недописанные тесты выбрасываются и не попадают в коммит. Здесь помогает регулярный и целенаправленный рефакторинг, который поможет отделить одни части кода от других. А рефакторинг, в свою очередь, должен опираться на автотесты, которых ещё нет :) Здесь можно раскрутить позитивный цикл изменений, но это не получится сделать быстро.
В конечном итоге, всё сводится к комбинации личного опыта разработчиков и внешних условий (качество кода, наличие инфраструктуры, отношение менеджмента, наличие времени на обучение и эксперименты). Если Вы хотите поменять поведение команды, недостаточно "просто договориться" с ними. Предоставляйте им возможности для того, чтобы выработать новые навыки и закрепить их на практике. Ищите способы сокращать цикл обратной связи при обучении. Пробуйте групповые тренинги. Находите энтузиастов в команде разработки, которые горят этой идеей и готовы тащить остальных за собой собственным примером. Гоните ссаными тряпками идеи по "геймификации" из комментов выше - потому что Вам нужен нормальный рабочий процесс, а не судорожные попытки подстроиться под безжалостные машинометрики.