Эта статья - конспект видео-доклада Егора Бугаенко. Доклад доступен на youtube по ссылке.
Егор уже выступал с похожим докладом на другой конференции, и вот комментарии, которые он получил, были нелестными: одни комментаторы обвиняли Егора в распространении вредных практик, другие - в том, что его тезисы противоречат здравому смыслу. Основная идея Егора в том, что при разработке софта разработчики должны строить код, а тестировщики - ломать его.
Чаще всего Егор видит в командах, как тестировщик помогает разработчику строить код: программер кодит, а тестировщик сидит рядом, проверяет и затем говорит “да, твой код работает”. Книги, которые Егор приводит в качестве примера, опровергают этот тезис следующим: задача тестировщика заключается в том, чтобы доказать, что написанный программистом код не работает. Если тестировщик не нашел багов в реализованной задаче или не доказал, что код не работает, то это - плохой тестер.
Конечная задача тестера - доказательство неработоспособности написанного кода.
Иначе говоря, тестер доказывает, что код не готов к релизу и деплою, и делать это он должен постоянно.
Чтобы достичь верной философии тестирования, Егор считает, что необходимо добиться изменения мировоззрения участников проекта. И далее тезисы, которые должны быть приняты ими.
В продакшн уходит код хорошего качества только в случае здорового конфликта между разработчиком и тестировщиком: разработчик кодит как можно больше, а тестировщик стремится как можно больше написанного кода не пропустить в продакшн. Но этот конфликт будет происходить только в командах, где к тестерам относятся как таким же равноправным участникам команды, а не как к людям “второго сорта”. Тестерами точно не должны становиться вчерашние студенты или джуниоры. Егор считает, что…
тестерами должны становиться более квалифицированные инженеры, чем обычные программисты.
Почему? Построить проще, чем поломать построенное и, что важнее всего, доказать, что оно поломано. С ростом проекта и поиск багов затрудняется, и поддержание количества найденных багов на прежнем уровне становится дороже. Это значит, что и тестеру нужно платить больше с возрастом проекта, чтобы привлечь высококвалифицированных специалистов на эту роль. Егор даже считает, что, возможно, карьера разработчика должна идти по следующему сценарию: junior -> middle -> senior -> tester.
Чаще всего менталитет складывается так, что начинающие инженеры сначала становятся тестерами, а затем с опытом переходят в разработку. В итоге сфера получает сеньоров, код которых никто не может поломать, и написанный код этими сеньорами идет фактически без препятствий в продакшн. И тут выявляется главная проблема сложившейся ситуации:
непосредственные пользователи начинают нам доказывать, что написанный нами софт не работает.
(От меня) Думаю, что многие согласятся с тем, что лучше бы эти баги из продакшена мы нашли на этапе тестирования до релиза.
Во многих случаях тестеры становятся неким quality gate’ом. Программисты кодят и готовят релиз, затем передают его тестировщиками; тестировщики проверяют код и репорят баги, которые уже программисты фикстят, и затем тестеры говорят: “Окей, оно готово к релизу”. Это - еще одна фундаментальная ошибка. Как можно ожидать от тестера зеленого света деплою, если его задача - доказать, что софт нерабочий. В этой концепции он никогда и не даст зеленый свет релизу, ведь это противоречит его основной задаче. В текущей ситуации, когда тестеры становятся quality-gates-keeper’ами, им незачем доказывать неработоспособность софта. Он просто может ничего не проверять и сразу дать зеленый свет.
Кодирование и тестирование должны идти параллельно всегда в течение процесса разработки софта. Чем больше багов нарепортят тестеры, тем лучше. Чем сильнее они докажут, что софт не работает, тем лучше будет качество продукта. Когда готовится релиз, менеджер должен оценить, изменилась ли тенденция поиска багов с их фиксом. Если находить баги в релиз-кандидате становится тестерам все труднее и труднее при той же интенсивности поиска, то это значит, что качество растет. Тестеру же продукт никогда не нравится, ему всегда есть что сказать про его качество.