Я проработал 5 лет разработчиком и в один день пришёл к своему менеджеру с таким сообщением: “Кажется, я понял проблему и нашёл решение. Я хочу стать QA.” С этого момента, часть своего рабочего времени я уделяю на QA. Но история началось задолго до этого…
Делай хорошо или не делай плохо
Чем сложнее вид деятельности, тем сложнее оценивать его результат. Работа, которая сводится к созданию однотипных продуктов, легко оценивается по их количеству, уровню соответствия. Но оценить результат работы разработчиков или менеджеров сложнее. Существуют KPI (Key-Performance-Indicator) и другие подходы, но это механизмы куда более сложные, их сложно внедрять, убедить в их работоспособности и прочее. Рассмотрим университет. Есть много студентов, которые изучают программирование, они выполняют задания, пишут код и предоставляют его на Code review. Студенты выполнили задания в соответствии с предложенными требованиями. Но как-то так получилось, что субъективно кажется, что некоторые работы сделаны на абсолютно разных уровнях. У меня такое происходило очень часто и за несколько лет преподавания я начал приходить к тому, что проблема была в детализации задачи, ограничениях и способах верификации.
Рассмотрим типичную ситуацию, которую приходиться решать. Я, как менеджер, ставлю задачу другому сотруднику. Он выполняет поставленные задачи и возвращается с результатом. Я смотрю, понимаю, что формально человек сделал всё, что от него требовалось. Но на деле результат меня не устраивает. Я нацелен на улучшение всего вокруг и предпринимаю попытки внести изменения. Анализирую, выделяю моменты, которые мне не понравились, затем доношу это до сотрудника: “В рамках этой задачи ты сделать X. Мне кажется, что было бы больше пользы, если бы ты вместо этого сделал Y, а также не забыл сделать ещё Z”. Образовательный контент полезен, но возникает вопрос: не забудет ли человек? А что делать, когда второй сотрудник подойдёт с таким же решением? Ему придётся предоставить аналогичную информацию? И самое страшно - а как это будет работать, если меня не будет?
Если очень сильно обобщить, то сотрудник “как-то” сделал свою задачу. Но в момент, когда я анализировал результаты, я начал рассказывать, что можно сделать не “как-то”, а “хорошо”. Это иногда рабочий способ, но очень сложный. Он неявно перекладывает ответственность за качество результата на человека, который оценивает результат. А такой подход очень плохо масштабируется, замыкается на одном человеке и создаёт Bus factor. Но ситуацию можно перевернуть и перевести “нормально и хорошо” в “нормально и плохо”.
Например, у меня есть запрос на то, чтобы по результатам устранения неожиданных проблем сотрудники проводили ретроспективу. Под ретроспективой в данном случае подразумевается любая активность нацеленная на анализ источника проблемы и проработки способов не допускать подобных проблем в будущем. Наивное решение - просить их не забыть выполнить это (“сделать хорошо”). Либо отдельно ставить задачу, пытаться оценить приоритет для этого. Но с другой стороны можно переработать процесс - сначала решить проблему, провести ретро и сделать выводы, а только потом отчитываться о выполнении. Этого можно достичь за счёт формализации процесса: описать регламент, зафиксировать требование провести ретроспективу и донести это до всех сотрудников. В таком случае для сотрудника будут более прозрачны ожидания, требования и важность, а не выполненная ретроспектива уже будет выглядеть как “сотрудник сделал плохо”.
Следующий пример: у меня есть некоторые ожидания на тему того, какую информацию сотрудники из отдела тестирования должны предоставить мне когда они сообщают о проблеме. Ситуация аналогичная: предоставляет недостаточно информации, я говорю, что нужно было посмотреть ещё какие-то детали, прошу делать “хорошо”. В этом момент можно собраться, согласовать набор требований к формату предоставления информации о проблеме. Грубо говоря, утвердить набор полей, которые будут содержаться в форме, которую нужно будет заполнять сотрудникам отдела тестирования. И не заполнение необходимых полей всё также переводит сотрудника в категорию “сделал плохо”.
”Не делай плохо” в мире разработки
В мире разработки подход с “не делай плохо” можно внедрять повсеместно. Первое что вспоминается - автоматическое тестирование. К сожалению, сказать разработчикам “пишите код без багов” не эффективно. Можно приходить с какими-то предложениями по улучшения из категории “давайте делать хорошо”. Но с другой стороны, каждая новая найденная проблема в продукте - это повод написать автоматическую проверку на то, что проблемы больше нет и она не появится. Если следовать такому подходу, то каждая проблема делает решение более качественным. И если разработчики не будут ломать уже существующие тесты, “не делать плохо”, то это уже будет приносить много пользы.
С другой стороны, хороший способ требовать что-то - это статический анализ кода. Они позволяют интегрировать требования в процесс разработки таким образом, чтобы разработчики не могли сделать “плохо”. Например, Roslyn analyzers позволяют встроить требования к коду в процесс компиляции кода, чтобы он завершался с ошибкой при нарушении. Это лишает возможности сделать “плохо”.
Ещё одним примером защиты от плохого является Continuous integration. Идея CI заключается в том, что разработчики должны регулярно вливать свои изменения в общий репозиторий, а эти изменения должны пройти через ряд проверок, прежде чем быть добавленными в общую базу. Например, CI может содержать такие шаги:
- Компиляция проекта, проверка на успешное завершение
- Запуск статических анализаторов, проверка на то, что проблемы отсутствуют
- Запуск автоматических тестов, проверка на то, что они все проходят.
- Требования обязательного ревью кода от других сотрудников
Но далеко не все требования можно верифицировать стандартными инструментами. Иногда приходится прибегать к разработке собственных. Например, есть желание при разработке проектов продвигать требования к использованию актуальных версий инструментов, писать Readme к проектам, настраивать CI, соответствовать принятому стилю кода, включать необходимые настройки для проекта. В таких ситуация проблему можно решать путем написания собственных инструментов. Именно такую задачу решает Zeya - https://github.com/kysect/Zeya. Если кратко, то это инструмент, который обходит код и сообщает о найденных проблемах, пытается их исправить и предложить добавить эти исправления в проект. Это ещё один подход решения “делай хорошо” - автоматизировать исправление проблем.
Возвращаясь к QA
Рассказ начался с того, что я теперь занимаюсь QA. QA - это сфера деятельности, связанная с обеспечением качества. И в моём случае, это качество процессов разработки. Несколько примеров задач, которые я пытаюсь решать.
Задача 1. Есть сервис, который команда DevOps предоставляет разработчикам для запуска сборки процессов сборки. Регулярно разработчики совершают ошибки при попытке использовать этот сервис. Он имеет очень не очевидный UX, требует от разработчика указывать очень много параметров, которые можно указать неправильно. Мы собираем обратную связь в рамках улучшения качества процессов. После описания проблемы мы продвигаем запрос на упрощение UX. Чем меньше разработчикам нужно будет совершать, тем меньше шанс ошибки и того, что всё нужно будет начинать с нуля, тратить лишнее время на конфигурацию запуска.
Задача 2. В результате анализа исправленных проблем выяснилось, что довольно проблематичными являются вопросы связанные с перформансом. Тестировщики обнаруживают проблему и сообщают о ней. Однако у разработчиков отсутствуют инструменты для лёгкого выявления корня проблемы. В таких случаях они начинают просить тестировщиков протестировать различные сценарии, включать более детальное логирование и снимать дампы процессов. И всё это нужно, чтобы узнать, что пару недель назад другой разработчик добавил неоптимизированный код в алгоритм. В рамках улучшения качества процессов рассматривается внедрение механизма, который бы собирал метрики о работе алгоритмов на регулярной основе и сообщал о резких ухудшениях после внесения изменений. Например, каждую ночь можно автоматически запускать тесты, собирать и сравнивать метрики и отправлять отчёты ответственным с результатами.
Задача 3. Каждый день проводится большое количество код-ревью. Разработчики указывают на проблемы, но нет какой-то гарантии, что в следующем ревью не будет указана такая же проблема. Один из способов повысить качество процессов - идентифицировать найденные возможные проблемы и реализовывать “защиту” от них. Например, замечание в ревью может быть превращено в анализатор кода или задачу на изменение дизайна кода (переписать код так, чтобы разработчик не мог неправильно написать код).