Как перестать контролировать качество ПО — без потери качества?

Когда заходит разговор о качестве ПО, люди, как правило, имеют ввиду соответствие каким-либо требованиям. Мы в IT Test рассматриваем его шире. Это не только соответствие требованиям, но и сами требования.  Точнее их дополнение своими, ориентированными не на заказчика, а на конечного пользователя. По сути, качество — это «сделать красиво» со многих сторон: дизайна, разработки, заказчика и пользователя.

Как это сделать?

Качество ПО — это стезя разработки

Почему качество ПО напрямую связывают с тестированием, ведь оно определяется тем, как сделан продукт. А не тем, как он протестирован?

— Просто так сложилось.

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

Устойчивость к изменениям

В долго живущих продуктах важны качество системы и её устойчивость к изменениям. А изменения всегда неизбежны.

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

Кодовая база — это не то, что можно сдать и забыть. Это среда, в которой мы живём, и нужно сделать её удобной для постоянной работы. Изменение, добавление или удаление кода не должно вызывать страх.

Что делать, если нет детальных требований?

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

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

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

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

Баги «избежны», но не все

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

Баги — это нормально, если они быстро чинятся и критические баги, ломающие основные сценарии, возникают крайне редко. Или не возникают вообще.

Если каждая задача, отправленная на тестирование, возвращается или при починке одного бага всплывает три новых, значит с качеством ПО что-то не так.

Баги есть и будут всегда

Мы всегда стараемся изменить восприятие заказчиков к багам, подойдя к этому вопросу немного с другой стороны. Количество багов зависит не только от кода, но и от того, что считать багом. В любом ПО, вне зависимости от его качества, можно найти баг, но он не всегда является таковым. Временами его исправление — это просто генерация лишней работы.

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

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

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

Протестировать всё в нашем мире было бы классно конечно, но здесь есть более важные вещи.

А что тестировать?

Главная задача тестировщика — сделать так, чтобы багов было как можно меньше. То есть чем меньше багов найдено, тем лучше.

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

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