Чистый код и тестирование: где начинается зона ответственности QA

Насколько важно соблюдать чистоту кода, знают все разработчики. А как насчет тестировщиков? Имеет ли это какое-нибудь отношение к ним? Если вы до сих пор считаете, что такие вопросы могут возникать только на «странных» проектах с «плохими» девелоперами, тогда мы идем к вам 🙂

robot_dreams опросил пять опытных QA-инженеров о том, как выглядит чистый код глазами тестировщика, как тестировать код не самого лучшего качества и нужно ли самому тестировщику учить паттерны проектирования и принципы SOLID.

Что такое чистый код с точки зрения тестировщика

Чистый код легко понимать, сохранять и поддерживать. А значит, как считает Юрий Вороненко, Senior Software Development Engineer in Test в Very Good Security inc и лектор курса QA Automation, такой код должен:

1. быть оформлен по стандарту (convention);

2. хорошо читаться;

3. не содержать дубликатов;

4. соответствовать принципам SOLID;

5. содержатьюнит-тесты на каждый класс.

«Если мы говорим о чистом коде в контексте тестирования, то это когда QA-инженер сам занимается написанием тестов и соблюдает определенные правила для поддержания чистоты кода. Для меня это код без лишнего усложнения, то есть использования "магических переменных" или "магических чисел", когда никто не понимает, что означает твоя переменная»

Юрий Сердюк, Software QA Automation Engineer

Сергей Сахненко, QA Lead / Community building manager и лектор курса QA Manual, тоже говорит, что чистый код легко понять, поэтому в идеале в нем не должно быть сложных конструкций:

«Понятный и читаемый код легче анализировать на наличие багов. Он также позволяет сосредоточиться на тестировании функциональности и логики, а не тратить лишнее время на разгадку неявных или запутанных разделов».

Как некачественный код влияет на тестирование

«”Плохой” код не только увеличивает количество багов, но и провоцирует их возникновение в неожиданное время и в неожиданных местах».

Олекса Мащиць, QA Team Lead

Тестировщики отмечают, что плохо читаемый и не покрытый юнит-тестами код может приводить к ошибкам на этапеинтеграционного илие2е-тестирования.

Юрий Вороненко, Senior Software Development Engineer in Test в Very Good Security inc, говорит, что именно поэтому очень важно следовать стандартам написания кода — чтобы избегать тривиальных ошибок, которые обязательно всплывут на следующих этапах тестирования.

«Ничего нового здесь нет: нужно хорошее покрытие юнит-тестами, наличие код-ревью, продуманная архитектура и соблюдение минимальных правил кодинга на проекте, чтобы все разработчики работали как команда, а не каждый добавлял уникальные подходы, что увеличивает беспорядок и риск возникновения кучи багов — например, интеграционных».

Олекса Мащиц, QA Team Lead

Интересно! Когда код чистый, тестировщику гораздо легче понять, какой функционал выполняется, без дополнительной коммуникации с девелоперами. Юрий Сердюк, Software QA Automation Engineer, делится, что у него был опыт, когда перед началом тестирования он просматривал pull request — и на этой стадии уже можно было найти какие-нибудь баги. «Но замечу, что это требует от тестировщика хотя бы каких-то базовых знаний кода», — добавляет Юрий.

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

Что касается нефункциональных требований к коду, то плохо читаемый код приводит к сложностям на этапах код-ревью, исправления ошибок, адаптации для новых инженеров на проекте. Также такой код часто приводит к ошибкам, поскольку инженер может просто упустить условие.

«Риски, которые можно получить в будущем, могут стать роковыми для бизнеса. Добавление новых фич может стать очень долгим процессом, с каждой фичей система будет становиться медленнее, новые сотрудники будут больше времени тратить на ознакомление с кодом, чем на выполнение задач».

Юрий Вороненко,
Senior Software Development Engineer in Test в Very Good Security inc.,
лектор курса QA Automation

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

Почему знать паттерны проектирования — не привилегия разработчиков

Олекса Мащиц, QA Team Lead, говорит, что любая информация о проекте для тестировщика будет полезна, но важный вопрос — будет ли он ее использовать? «На практике мы нечасто заходим в эту сторону из-за отсутствия квалификации, к сожалению», — делится опытом Олекса.

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

«Качество фреймворка тестирования напрямую зависит от грамотного использования паттернов, архитектуры фреймворка в целом. От этого зависит, как можно быстро добавлять новые тесты и поддерживать существующие. В общем, все как в разработке, только мы пишем продукт, который тестирует другой продукт», — говорит Юрий Вороненко, Senior Software Development Engineer in Test в Very Good Security inc.

«Тестировщики могут использовать шаблоны для создания упорядоченных тестовых случаев, управления тестовыми данными, создания инфраструктур автоматизации, улучшения расширяемости и улучшения сотрудничества с разработчиками. Это не только привилегия разработчика — обе роли могут извлечь выгоду из использования шаблонов проектирования для повышения качества кода и удобства обслуживания»

Ростислав Биляев,
Senior QA Automation в Adidas,
лектор курса QA Automation

Что делать, если нужно тестировать плохо написанный код?

Ростислав Биляев, Senior QA Automation в Adidas, предлагает несколько шагов:

1. Сотрудничайте с разработчиками для рефакторинга

2. Внедряйте шаблоны проектирования

3. Используйте модели

4. Определите приоритеты тестирования и автоматизации

5. Пропагандируйте качественные практики кодирования и документируйте проблемы

В целом говорят, что ситуации, когда разработчики ни в какую не соблюдают чистоту кода, случаются крайне редко. Но все же, если такое произойдет с вами, Сергей Сахненко, QA Lead / Community building manager, делится двумя базовыми советами:

1. Общайтесь с разработчиками: высказывайте опасения относительно влияния плохого кода на тестирование и качество продукта. Попытайтесь донести, какие преимущества чистый код может иметь для процесса тестирования.

2. Настройте автоматизированное тестирование: оно поможет обнаруживать баги, даже если код имеет низкое качество.

«Инженер по качеству должен заниматься не только тестированием, но и принимать участие в планировании, формировании процессов разработки, настройке чек-листов, которые, в свою очередь, сводят риски, связанные с ошибками программного обеспечения, на минимум. Если с менеджментом были согласованы подходы и процессы контроля качества и вы все правильно настроили, то разработчик просто не сможет вылить плохой код в ветку, его не пропустят quality gates»

Юрий Вороненко,  Senior Software Development Engineer in Test в Very Good Security inc

Олекса Мащиц, QA Team Lead, говорит, что разработчики будут стремиться улучшать качество своего кода, если грамотно указать на потери по времени и риски, возникающие в результате написания некачественного кода.

Отдельной темой здесь может идти автоматизация тестирования, которая отберет часть «грязной» работы у мануальных тестировщиков и будет «мозолить глаза» разработчикам, мол, «Все тесты упали! Снова!». Такой статус никому не нравится.

Инструменты, помогающие тестировать код

Ростислав Биляев, Senior QA Automation в Adidas, отмечает, что выбор инструмента тестирования часто зависит от тестируемой системы (SUT) и ее конкретных требований:

«Различные инструменты удовлетворяют разные потребности в тестировании, например: модульном, интеграционном тестировании, тестировании браузера, API, производительности и т. д. Важно выбрать инструмент, соответствующий характеру SUT и желаемым целям».

Юрий Вороненко, Senior Software Development Engineer in Test в Very Good Security inc, подчеркивает, что с точки зрения функционального тестирования это, конечно, юнит-тесты. Если тестирование нефункциональное, то помогут разного родалинты — с ними легко находить ошибки на уровне оформления кода, документации. Один из мощных инструментов — SonarQube.