8 мая 2018

Код-ревью как инструмент работы тестировщика

Анастасия, Test Engineer Noveo, всегда рада возможности взглянуть на, казалось бы, уже незыблемые истины под другим углом и обсудить новую точку зрения с коллегами. Вслед за статьей о тестировщиках-автоматизаторах мы предлагаем вашему вниманию Настин перевод о роли тестировщика в код-ревью с комментариями наших тестировщиков.

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

Несмотря на то, что код-ревью и pull-реквесты широко распространены среди разработчиков, они продолжают быть своего рода terra incognita для QA-инженеров. В большинстве Scrum-команд, с которыми мне приходилось работать, тестировщики изначально не участвовали в ревью кода и pull-реквестов. Пришло время изменить устоявшуюся точку зрения! В этой статье я хочу рассмотреть код-ревью и отметить преимущества его применения с позиции как тестировщика, так и команды, работающей по методологии Scrum.

Подождите, но в описании стандарта ISTQB сказано, что…

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

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

Такой способ инкрементального тестирования (можно сказать, гибкого тестирования), конечно же, не исключает тестирование методом черного ящика перед большими релизами.

Ревью реализации кода команды

Итак, если вы — инженер-тестировщик, почему вам тоже необходимо участвовать в код-ревью? Не будет ли удобнее дождаться, пока новую версию продукта развернут в тестовой среде, и только потом приступать к работе?

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

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

Ревью реализации кода автотестов

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

В заключение

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

Оригинал статьи: https://www.testdetective.com/2018/05/code-review-for-testers.html

Наш взгляд

Антон, старший QA-инженер:

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

На мой взгляд, статье не хватает хорошего примера «а вообще зачем это нужно», поэтому я постараюсь привести таковой. Предположим, что разработчик делал фичу A, но при этом сделал незапланированный рефакторинг кода и в его рамках изменил реализацию фичи Б. Допустим также, что разработчик забыл или не знал, что следует дать знать команде об этом незапланированном рефакторинге. В итоге тестировщик проверяет функциональность А, которая успешно работает, и не уделяет внимание функциональности Б, затрагивая ее только в момент общей регрессии (если ее вообще затрагивают), что не очень хорошо сказывается на продукте. Если бы тестировщик присутствовал на code-review с остальной командой, то смог бы увидеть все изменения и протестировать функциональность Б, чтобы убедиться, что изменения в коде не ухудшили его работу.

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

Конечно, возможные трудности — совершенно не повод не учиться участвовать в код-ревью. Мне кажется, если QA-инженер давно работает с проектом, велика вероятность, что он уже хорошо знает его архитектуру и представляет, что и как происходит “под капотом”. Возможно, знание кода проекта может натолкнуть на какие-либо специфичные кейсы, которые в обычном случае мы не рассматриваем из-за незнания структуры продукта.

Татьяна, QA-инженер:

Я немного не согласна с автором статьи. Мне кажется, что QA-инженер должен ревьюить автотесты других тестировщиков, а программисты должны ревьюить программистов.

Тестирование с помощью белого и серого ящика — это одно, а ревью кода программиста — совсем другое дело. Какой смысл тратить время и силы на то, что другой программист сделает за 15 минут? Какую полезную информацию может получить тестировщик, присутствуя на ревью? Что полезного он сможет от себя добавить касательно кода?

Мое видение проекта таково: за качество продукта отвечает не только QA, но и все члены команды. Код — это сфера ответственности программистов, пользовательские сценарии, удобство, логика — сфера влияния тестировщика. Каждый должен заниматься своим делом, ради одной цели: качественный продукт, который будет удобен и полезен пользователям.

А что думаете вы?

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: