Software quality assurance (SQA или просто QA) - это деятельность по оценке качества и обеспечению соответствия стандартам и процессам (хотя многие это считают синонимом тестированию).
Обеспечивает ли следованию процессу качество? Возможно, если процесс ориентирован на качество и имеет средства для его поддержания. И на проекте «правильные» люди.
Конечно, теоретики скажут, что процесс гарантирует качество, что все проблемы вызваны нарушением процедур, что проект «неправильный» или что все ошибки из-за людей, а не из-за процесса. На самом деле, люди являются наиболее важной частью успеха, в то время как даже полное следование процессу может привести к провалу. И в этом плане термин SQA вводит в заблуждение. SQA обеспечивает не качество продукта, а соответствие стандартам и процессам, что совсем не одно и то же.
Давайте рассмотрим именно качество продукта, а не следование процессу. Качество можно проверять или же оно может быть «встроено» в процесс создания продукта. Эти подходы дополняют друг друга. В случае, если используется только контроль, то придется тратить много времени на исправление ошибок, а если нет контроля, то повышается риск выпустить некачественный продукт.
Для повышения качества можно использовать разнообразные инструменты и подходы. Важно понимать, что нужно сделать, как это сделать и как проверить, что сделанный продукт и есть то, что нужно заказчику.
Обеспечение качества – это очень большая тема. В Интернете есть много информации по приводимым ниже техникам, в этом обзоре я просто кратко упомяну некоторые. Рассмотрим следующие области:
- Требования
- Создание
- Предупреждение проблем в будущем
Требования
Проект должен решить правильные проблемы; не просто сделать вещи правильно, но в первую очередь сделать правильные вещи. Команда должна помочь клиенту понять, что надо сделать. В случае, если заказчик объяснил свое видение продукта, команда может проанализировать требуемую функциональность с учетом видения. И указать на потенциальные проблемы или недостатки на ранней стадии, что позволит уменьшить затраты и увеличить общее удовлетворение от проекта.
Иногда заказчик не хочет предоставлять даже видение (например, это считается коммерческой тайной). Команда может попытаться объяснить недостатки такого подхода и потенциальные риски, но конечное решение все равно остается за заказчиком. Конечно, в такой ситуации команда создаст свой вариант видения, но оно может отличаться от видения клиента (скорее всего, оно и будет отличаться).
У клиента может не быть времени даже обсуждать требования. Опять-таки, это его решение. Команда может только предупредить о возможных негативных последствиях для проекта.
Для улучшения качества команда может предоставить свою экспертизу в области решения – пользовательский интерфейс (особенно специалистами по user interaction и информационной архитектуре), технические детали (например, платформа, требования к производительности или масштабируемости в зависимости от бизнес-требований к системе) или даже в бизнес-области, если у команды есть опыт работы с похожими проектами.
Создание
Команда сделала, что смогла, чтобы выяснить, что нужно сделать. Теперь вопрос – как это сделать? Для начала важно понимать, что качество имеет свою цену. В краткосрочном периоде высокое качество стоит дороже, но в долгосрочном низкий уровень качества может стоить больше (так обычно и происходит) чем высокий – команда должна постоянно исправлять ошибки, с кодом тяжело работать, нужно много времени на то, чтобы что-то изменить или добавить новую функциональность.
Нужно определиться, какой уровень качества необходим для данного проекта. А затем команда должна постоянно поддерживать этот уровень в течение всего проекта.
Для этого команда может использовать:
- Архитектуру
- Definition of done
- Peer code review
- Рефакторинг
- Тестирование (unit, integration, ручное, производительности и т.д.)
Архитектура
Раньше было очень много шума по поводу архитектуры в рамках agile подходов. Самые радикальные говорили, что архитектура должна возникать во время разработки без всякого предварительного планирования и архитектурного дизайна. Мне кажется, это преувеличение. Сумма частей не всегда есть целое, поэтому хороший дизайн небольших модулей не гарантирует хорошую архитектуру системы. На практике внимание к архитектуре зависит от сложности системы – для маленьких систем в хорошо известной области у команды уже есть готовые решения, а вот для больших систем с серьезными нефункциональными требованиями нужно отдельно заняться архитектурой. Хотя не стоит впадать и в другую крайность – заранее продумывать все мельчайшие детали; достаточно продумать наиболее важные и те, что тяжело изменить позже.
Иногда про архитектуру как-то забывают после ее создания. Естественно, со временем атрибуты качества архитектуры ухудшаются – архитектура становится менее понятной, ее тяжелее поддерживать, устойчивость нарушается и т.д. Поэтому необходимо периодически (или когда новые требования не ложатся на существующий дизайн) пересматривать архитектуру и изменять при необходимости.
Definition of done
В Scrum есть хорошая концепция “done”. История или сделана, или нет. Она не может быть «сделана, но…» или «почти сделана». Как определить, что история на самом деле сделана и нет никаких «но»? Используйте definition of done.
Definition of done – это простой проверочный список. В нем содержатся условия, которым должна удовлетворять история, чтобы считаться завершенной.
Если мы хотим встроить качество, то definition of done отличное место для этого. Например, чтобы избежать простейших ошибок, команда может решить включить условие, что «Нет новых предупреждений от PMD или FindBugs».
Идея definition of done может быть предложена кем угодно, но принимать решение об использовании должна команда (а не менеджер проекта или ScrumMaster). Если команда не видит пользы, то она найдет способ обойти эти критерии.
Definition of done можно расширить за пределы истории – например, команда может ввести definition of done для спринта или релиза (провели тестирование производительности, система хорошо работает под Windows и под Linux). Это помогает удостовериться, что система удовлетворяет нефункциональным требованиям.
Peer code review
Одним из мощных средств по улучшению качества является peer code review (к тому же оно позволяет передавать знания и выстроить общее понимание и стандарты внутри команды, а также разрабатывать навыки и учиться быстрее). Иногда команда забывает про code review, иногда сроки сдачи близки (да, deadline весьма часто где-то очень близко 
), но команда не проводит code review. Чтобы избежать этой проблемы, команда может просто включить code review в definition of done – и тогда не получится двигаться дальше, пока не провели code review.
В одной команде мое предложение по включению code review в definition of done тщательно обсудили, и затем команда пришла к выводу, что это было бы полезно. Впоследствии это помогло обнаружить несколько серьезных проблем и создать общий стиль и понимание. В другой команде похожее предложение отклонили. Спустя некоторое время вторая команда тоже пришла к выводу, что включение code review в definition of done полезно.
Рефакторинг
Код со временем ухудшается из-за постоянных изменений. Рефакторинг - одно из наиболее популярных и эффективных средств для улучшения качества кода и увеличения его понятности. Можно сделать его частью definition of done. Или выделять специальное время на рефакторинг (например, в конце спринта).
Тестирование
Unit и integration тесты увеличивают стабильность и уменьшают количество ошибок за счет обнаружения проблем на ранних фазах. К тому же они помогают продумать разнообразные варианты, делая систему более надежной.
Ручное тестирование может проводиться разработчиками (когда завершили историю), тестировщиками, а также командой Product Owner’а (это может быть и один человек) во время приемочного тестирования.
Конечно, есть много других типов тестирования, выполняющих свои особые задачи.
Перед началом использования какого-нибудь из видов тестирования стоит проанализировать, будет ли именно это тестирование полезно для проекта.
Предотвращение проблем в будущем
Отлично, команда исправила проблему. Но немного позже опять сражаются с похожей проблемой. Опять и опять. Урок не усвоен. Чтобы усвоить урок, команде нужно определить проблему, выявить, проанализировать и исправить причину проблемы. А это как раз одна из целей ретроспективы.
Качество как часть разработки
Все вышесказанное можно просуммировать как простой контрольный список:
- Сделайте требования достаточно адекватными реальной бизнес-проблеме
- Встройте качество в процесс создания
- Архитектура
- Unit/integration тесты
- Definition of done
- Рефакторинг
- Peer code review
- Протестируйте
- Проверьте, что результат это то, что запрашивалось
- Проверьте, что результат это то, что на самом деле нужно
Хм, весьма похоже на процедуру :-). Не совсем. Основное отличие – все эти практики можно использовать отдельно в зависимости от контекста. Некоторые практики могут быть бесполезными или даже вредными в конкретном проекте.
И самое главное – не забывайте про людей. Очень важно, чтобы команда понимала, как эти практики могут помочь им. И тут необходим консенсус. Jean Tabaka в ее книге “Collaboration Explained” определила консенсус как решение, которое каждый готов поддерживать и нет таких, кто категорически не согласен с этим решением. Команда должна определиться с набором практик, которые каждый член команды готов поддерживать.
А затем просто наслаждайтесь высоким качеством продукта.
