Home

Оригинальная публикация: https://www.testdetective.com/2018/05/code-review-for-testers.html

Перевод: Анна Радионова

Код-ревью очень важное явление в процессе разработки ПО. Ставшее популярным, благодаря сообществу разработчиков ПО с открытым исходным кодом, оно сейчас является стандартом для любой команды девелоперов. Если оно выполняется правильно, то польза заключается не только в уменьшении количества багов и лучшем качестве кода, но и в обучающем эффекте для программиста.

И хотя код-ревью и запросы на включение кода (pull requests) хорошо известны разработчикам, эти понятия все еще остаются не до конца понятны тестировщикам. В большинстве scrum команд, в которых мне приходилось работать, инженеры-тестировщики по умолчанию не принимали участия в процессе просмотра запросов на изменение кода. Самое время изменить подобное мышление тестировщиков (и команд!). В этой статье я бы хотел рассмотреть код-ревью с позиции тестировщика и обозначить его преимущества для тестировщиков и scrum команд.

Погодите, но ISTQB говорит, что…

Я должен сделать небольшое отступление: да, я знаком с подходом тестирования черного/серого ящика. Я считаю, что тестирование без знаний подробностей устройства системы может быть эффективным. Оно направлено на решение проблем, связанных со знанием точек решения и условий процесса. Однако, проведение функционального тестирования черного ящика наиболее эффективно перед крупным релизом или после длительной итерации внедрения фичи. Я считаю, что в процессе небольших поэтапных изменений и частых выпусков продукта, наличие в команде тестировщика, который знаком с кодом, дает массу преимуществ для улучшения качества продукта. Такая практика позволяет ему сконцентрироваться на фактических изменениях и ознакомлении с архитектурой системы.

Такой вид поэтапного тестирования (давайте называть его agile), естественно, не исключает проведение тестирования черного ящика перед крупными релизами.

Тестировщик, просматривающий код реализации проекта

Итак, вы - тестировщик в scrum команде – зачем вам проводить код-ревью? Разве не удобнее дождаться, пока изменения не будут залиты на тестовое окружение и затем приступить к своей работе? Прежде всего,  инженер-тестировщик несет ответственность за качество продукта, а качество имеет значение на всех этапах разработки. Современные подходы тестирования содержат много информации об анализе требований и методологии процесса (бывает даже так, что тестировщикам приходится выполнять обязанности скрам-мастера), но почти не содержат информации о фазе кодинга, которая является важнейшей составляющей процесса. Тестировщик, как и любой другой член команды, должен принимать участие в код-ревью, обращая внимание на качество реализации и соответствие требованиям бизнеса.

Второе, о чем нужно знать, это диапазон тестирования. Начиная тестирование, ознакомившись с кодом, вы можете определить фактический объем, который необходимо покрыть тестами, а также критичные участки в коде, которые являются основой логики приложения.

Команда, просматривающая код тестировщика

Как правило, коду, не предназначенному для продакшна,  как и автоматизированным функциональным тестам, уделяется меньше внимания. Мне понятны причины такого явления, однако, считаю, что мы упускаем несколько моментов при таком подходе. Автоматизированные тесты (за исключением юнит-тестов и интеграционных)   обычно пишутся тестировщиками, обладающими более слабыми навыками программирования, чем разработчики (конечно, это не является правилом). Для того, чтобы они могли совершенствоваться в программировании, их код должен просматриваться коллегами. Это способствует не только улучшению качества кода, но и имеет образовательную ценность.

Вывод

Этап код-ревью крайне недооценен в процессе тестирования и обеспечения качества. Если вы тестировщик, который работает в рамках итерационной разработки, я абсолютно уверен, что ознакомление с пулл-реквестами должно являться неотъемлемой частью вашей работы после ознакомления с требованиями. С другой стороны, ваш код также должен просматриваться другими сотрудниками, что лично для меня явилось ключевым фактором в освоении автоматизации тестирования.

Обсудить в форуме