Эта статья - конспект видео-доклада Егора Бугаенко. Доклад доступен на youtube по ссылке.
Comments for other speech
Егор уже выступал с похожим докладом на другой конференции, и вот комментарии, которые он получил, были нелестными: одни комментаторы обвиняли Егора в распространении вредных практик, другие - в том, что его тезисы противоречат здравому смыслу. Основная идея Егора в том, что при разработке софта разработчики должны строить код, а тестировщики - ломать его.
Programmers build, testers - break.
Чаще всего Егор видит в командах, как тестировщик помогает разработчику строить код: программер кодит, а тестировщик сидит рядом, проверяет и затем говорит “да, твой код работает”. Книги, которые Егор приводит в качестве примера, опровергают этот тезис следующим: задача тестировщика заключается в том, чтобы доказать, что написанный программистом код не работает. Если тестировщик не нашел багов в реализованной задаче или не доказал, что код не работает, то это - плохой тестер.
Конечная задача тестера - доказательство неработоспособности написанного кода.
Иначе говоря, тестер доказывает, что код не готов к релизу и деплою, и делать это он должен постоянно.
Слом мировоззрения в software development
Чтобы достичь верной философии тестирования, Егор считает, что необходимо добиться изменения мировоззрения участников проекта. И далее тезисы, которые должны быть приняты ими.
:heavy_check_mark: 1. Testers are not second-class citizens
В продакшн уходит код хорошего качества только в случае здорового конфликта между разработчиком и тестировщиком: разработчик кодит как можно больше, а тестировщик стремится как можно больше написанного кода не пропустить в продакшн. Но этот конфликт будет происходить только в командах, где к тестерам относятся как таким же равноправным участникам команды, а не как к людям “второго сорта”. Тестерами точно не должны становиться вчерашние студенты или джуниоры. Егор считает, что…
тестерами должны становиться более квалифицированные инженеры, чем обычные программисты.
Почему? Построить проще, чем поломать построенное и, что важнее всего, доказать, что оно поломано. С ростом проекта и поиск багов затрудняется, и поддержание количества найденных багов на прежнем уровне становится дороже. Это значит, что и тестеру нужно платить больше с возрастом проекта, чтобы привлечь высококвалифицированных специалистов на эту роль. Егор даже считает, что, возможно, карьера разработчика должна идти по следующему сценарию: junior -> middle -> senior -> tester.
Чаще всего менталитет складывается так, что начинающие инженеры сначала становятся тестерами, а затем с опытом переходят в разработку. В итоге сфера получает сеньоров, код которых никто не может поломать, и написанный код этими сеньорами идет фактически без препятствий в продакшн. И тут выявляется главная проблема сложившейся ситуации:
непосредственные пользователи начинают нам доказывать, что написанный нами софт не работает.
(От меня) Думаю, что многие согласятся с тем, что лучше бы эти баги из продакшена мы нашли на этапе тестирования до релиза.
:heavy_check_mark: 2. Testers don’t tell us when to release
Во многих случаях тестеры становятся неким quality gate’ом. Программисты кодят и готовят релиз, затем передают его тестировщиками; тестировщики проверяют код и репорят баги, которые уже программисты фикстят, и затем тестеры говорят: “Окей, оно готово к релизу”. Это - еще одна фундаментальная ошибка. Как можно ожидать от тестера зеленого света деплою, если его задача - доказать, что софт нерабочий. В этой концепции он никогда и не даст зеленый свет релизу, ведь это противоречит его основной задаче. В текущей ситуации, когда тестеры становятся quality-gates-keeper’ами, им незачем доказывать неработоспособность софта. Он просто может ничего не проверять и сразу дать зеленый свет.
Кодирование и тестирование должны идти параллельно всегда в течение процесса разработки софта. Чем больше багов нарепортят тестеры, тем лучше. Чем сильнее они докажут, что софт не работает, тем лучше будет качество продукта. Когда готовится релиз, менеджер должен оценить, изменилась ли тенденция поиска багов с их фиксом. Если находить баги в релиз-кандидате становится тестерам все труднее и труднее при той же интенсивности поиска, то это значит, что качество растет. Тестеру же продукт никогда не нравится, ему всегда есть что сказать про его качество.
Если тестеру нравится продукт, который он видит, это - плохой тестер.
Менеджер, видя количество и качество найденных багов спустя некоторое время после подготовки релиза, должен принять решение: деплоим ли мы версию продукта с полученным качеством или нет. Тестеры делать этого ни в коем случае не должны.
:heavy_check_mark: 3. Testers must be rewared for bugs they find
Наиболее правильный путь мотивации - награждать за найденные баги. Чем больше багов, тем больше денег они получают. Эта мысль, по словам Егора, и вызывает много споров.
Возражения комментаторов и других разработчиков на тезисы Егора
Егор часто выступает с рассказами о своей концепции, и вот наиболее частые возражения, которые он встречает.
:x: 1. Programmers and testers must work together!
Создание конфликта между тестерами и разработчиками приведет к разладу в команде, по мнению возражающих. Звучат также тезисы, что конфликт может выйти за рамки рабочих процессов. Егор считает, что тестеры и разработчики и так работают в одной команде, и цель у них одна - выпустить качественный продукт. Однако рабочие задачи тестеров и разработчиков действительно встречные: одни кодят, другие не пропускают написанный код. Всегда должен быть конфликт интересов, иначе не будет высокого качества кода.
В ответ на возражение Егор задает встречный вопрос: “а как можно замотивировать тестировщика на поиск как можно большего количества багов?”.
Мотивация на время
Мотивация на время в офисе не сработает, ведь тестеру заплатят N денег в конце месяца в любом случае, найди он 5 багов или 50. Тем более что он в одной команде с разработчиками, и ему сказали, что у них у всех одна общая цель.
В таких условиях понятное дело, что репортов багов будет очень мало - зачем тестеру идти на конфликт с разработчиком и рассказывать ему, что его код не работает. Руководство говорит “не ссорьтесь”, а как тестеру не ссориться, если код не работает. В итоге тестер не репортит баги с мыслью “Ну не работает, да и ладно. Они все сеньоры, я джун, у меня права нулевые. Лучше покажу баг тем, кто меньше на это реагирует. Пофиксят - хорошо, а не пофиксят - не страшно.”. Тестеры должны ссориться с разработчиками, они должны иметь карт-бланш на вступление в конфликты с разработчиками.
Здоровый рабочий конфликт между тестером и программистом неизбежен.
Мотивация на скрипты
Вторая мотивация - на скрипты. “Вот тебе список из 100 шагов по скрипту. Выполни их, проверь тикет, и свободен”. Эта мотивация немного лучше, считает Егор, потому что тестер обязан покрыть некоторый объем работы. Хочешь-нехочешь, но если шаг 14 не работает по скрипту, то тестер обязан зарепортить баг, и от этого никак не отвертеться, хотя это “некомфортно”. Почему некомфортно? Потому что этот скрипт ломается уже в который раз на тикете от разработчика Пети. Петя вот сидит, Пете семью кормить. Вдруг его уволят после репорта бага? Может ну этих пользователей, пусть живут с багами, а Петя вот тут сидит. Лучше мы договоримся с Петей и закроем баг без репорта.
Второй негативный момент, связанный с внедрением скриптов тестирования, это отсутствие мотивации создавать автоматические тесты UI, интеграционные и другие виды тестов. Зачем, если сценарии тестирования.
:x: 2. Rewarding for bugs will produce more bugs.
“Если мы платим за баги, то багов будет только больше”. Тестеры смогут насоздавать бесконечное количество багов, значительных и косметических. А может даже тестеры еще и вступят в сговор с разработчиками: разработчик делает баги, тестер их репортит, а деньги за баги они делят пополам. Довольно частое возражение, говорит Егор.
Чтобы этого не допустить, нужен человек, который верифицирует баги: принимается баг или нет. Часто баги отбрасываются, потому что они “слишком абстрактные”, либо незначительные, либо косметические, либо пространные в духе “посмотрел ваше приложение, и мне что-то не понравилось”. Решение о принятии бага или его непринятии принимает архитектор проекта. Баг должен быть зарепорчен так: что не работает, как должно работать, как воспроизвести и как починить, если есть предположения.
Конечно, в сговор могут вступить и трое, включая того самого архитектора, но Егор такие случаи в практике не встречал. Команды в проектах у Егора распределенные, и связаться друг с другом им тяжелее.
Егор считает, что большое количество багов в тикет-системе - это хорошо, потому что они были зарепорчены тестерами, а не конечными пользователями. Это и есть высокое качество.
Качеством можно назвать соотношение багов, найденных тестерами, к багам от конечных пользователей,
и чем больше багов будет зарегистрировано в тикет-системе тестерами, тем меньше багов придет с продакшена.
Конечно, будут просачиваться незначительные баги, будут и ситуации, когда какому-то тестеру переплатили за баг, который оказался не таким значительным. Но это нестрашно, считает Егор, потому что альтернатива - гораздо хуже.
:x: 3. Testers will quit when complexity grows.
“Тестеры будут уходить, когда сложность проекта возрастает, и баги находить становится гораздо сложнее”. Это возражение - самое логичное, считает Егор. Когда проект сырой, то и багов будет море. Тестеры репортят баги тоннами, получают много денег и радуются. Но с ростом качества проекта поиск одного бага будет занимать уже не полчаса, как раньше, а по нескольку часов. Егор считает, что это нормально.
Когда проект молодой, можно привлекать недорогих / неопытных тестеров, а с ростом проекта и его качества привлекать уже более квалифицированных профессионалов. Сеньор-тестировщики уже не тестируют UI и законченный продукт, но смотрят и security-issue, и анализируют проект на бэкдоры и бреши, и performance-тестирование проводить и находить баги уже в этих областях.
Вопросы из зала
По поводу второго возражения. В банке N был как раз описанный сговор в одной из команд, и в итоге команду распустили. В природе человека лежит желание с кем-то договориться и хакнуть систему.
Такое может быть действительно, но Егор задает встречный вопрос: а как заведомо дефективный код попадает в master-branch? Ведь код разработчика попадает тестеру не напрямую, а через билд-пайплайны, код-ревью, юниттестирование и прочие quality gates. Если этого пайплайна нет, то это - уже дефект всей системы, и даже хорошо, что отдельно взятые двое людей его выявили. Если пайплайн “недопущения” кода разработчика в master-branch есть и если разработчик смог пройти все его шаги, а затем тестер нашел баг, то это прекрасно, считает Егор. Черт с ним со сговором, Егор готов им заплатить за выявленный дефект в продукте. Дело ведь в том, что эти двое людей показали, что в самом пайплайне есть дефект, который необходимо чинить в первую очередь.
Что произойдет с этим багом? Он вернется в систему тикетов, другой разработчик определит, что дефект был в системе пайплайна и зафиксит ее и сам баг тоже, получив свое вознаграждение.
Если пайплайна проверки кода нет и мы просто скажем “Ребята, теперь мы платим за баги”, то у проекта будут сговоры.
Ваш подход может сделать задачу нерешаемой. Баг можно найти сегодня, завтра, постоянно. Релиз никогда не выйдет. Задача тестера - сказать, что релиз соответствует требованиям. Нет ситуации, когда поиск багов прекращается.
Как понять, когда заканчивать тестирование. В любом продукте есть бесконечное количество багов. Даже в примитивном калькуляторе можно найти уйму багов. В данном случае
багом мы называем несоответствие продукта ожиданиям пользователя.
Даже незначительное несоответствие ожиданиям, вплоть до “кнопка не того цвета”, можно зарегистрировать как баг. Когда остановиться - решает менеджмент, а не тестеры. У менеджмента есть бюджет и менеджмент и решает, какой объем багов он покупает у тестировщиков. Чем больше бюджет на тестирование, тем качественней будет конечный продукт.
Ответ на вторую часть вопроса - “Задача тестера - сказать, что релиз соответствует требованиям”. Как раз программист говорит, что код соответствует спецификациям, а вот тестер ему говорит “нет, дорогой мой, не соответствует, и вот почему: …”
Согласен насчет того, что работать разработчик и тестер не должны вместе. Но это приведет к тому, что чем лучше программист напишет код, тем меньше получит тестер. Получается, что они делят один пирог, и в итоге конфликт может выйти за стены офиса.
Егор не согласен с этим утверждением. Тестер работает с кодом проекта, а не с конкретным разработчиком. Когда баг найден, менеджмент не должен искать автора этого бага. Код был пропущен пайплайном проекта, значит виновата система качества продукта и нужно чинить и ее тоже, а не обвинять конкретного разработчика.
Баг принадлежит коду проекта, а не разработчику.
Если менеджмент начнет выяснять, кто виноват в найденном баге, то появится так называемый fear-driven-development - страх разработчика сделать багис новым кодом. Это приведет к тому, что разработчики перестанут экспериментировать и будут думать “лучше я ничего не напишу, чем напишу что-то новое, и меня потом начнут винить в багах и заставлять фиксить их поздними вечерами”. Если баг уже в master-branch, то автор бага не имеет никакого значения.
Егор считает, что конфликт не должен выходить за стены офиса, ведь и программистам выгодно, чтобы баги регистрировались в системе, ведь это - еще работа, за которую платят.
Плохо только менеджменту, потому что вроде как поток багов и поток фиксов есть, деньги уходят, а качество не растет.
Тогда уже менеджмент смотрит, как работает пайплайн сборки и почему он пропускает баги от разработчиков.
Клиент покупает продукт, если этот продукт решает его проблему. Ему все равно на количество багов в системе, и количество багов не равно качеству продукта. Баги бывают разные, и бизнесу важно отсутствие критически важных багов, а не количество багов в целом. А клиенту не важно, как выглядит продукт, ему важно получить от него решение проблемы.
Егор считает, что задающий вопрсо слишком идеализирует клиента, что клиенту неважно, как выглядит продукт. Люди эмоциональны, и им важно, красиво ли выглядит продукт, быстро ли он реагирует на действия и другие мелочи. Это уже вопрос продакт-менеджмента: так ли мы делаем продукт и тот ли продукт мы делаем. Доклад не о продакт-менеджменте, а о проджект-менеджменте: принимается за аксиому, что команда разрабатывает тот продукт, который точно нужен рынку, и уже от этой аксиомы проджект-менеджмент начинает выстраивать процессы разработки.