Служба качества ИТ-компании: зачем и кому она нужна
Всем привет! Меня зовут Екатерина Ремизова, я директор по качеству ИТ-компании SimbirSoft. Мы разрабатываем программное обеспечение на заказ. Чтобы поддерживать качество разработки, специалисты нашей службы качества проводят комплекс мероприятий, по результатам которых совершенствуют процессы. В статье постараюсь объяснить, зачем компаниям нужно иметь такое подразделение, и поделюсь нашим опытом создания службы качества.
«85% проблем качества вызваны процессами производства и только 15% — исполнителями».
Джозеф Джуран — архитектор качества, экономист, теоретик менеджмента, автор «Справочника по контролю качества» (Quality control handbook)
Служба качества (СК) ИТ-компании контролирует исполнение процесса на каждом этапе жизненного цикла проекта. Она помогает организовать все процессы в компании так, чтобы продукт был готов в срок с минимальными затратами, соответствовал задачам бизнеса и ожиданиям пользователей.
СК способствует установлению стандартов процессов разработки и внедряет их в работу, согласовывает критерии качества продуктов, разрабатывает и внедряет метрики, по которым можно оценить качество работы всей компании.
Вот чем еще занимается СК:
- регламентирует взаимодействие направлений и отделов компании, которые работают над проектом;
- отвечает за разработку (совместно с функциональными подразделениями) и внедрение новых процессов;
- разрабатывает и внедряет инструменты мониторинга и контроля процессов;
- отслеживает уровень удовлетворенности клиентов;
- проводит аудиты работы на каждом уровне организации, в производственных и вспомогательных процессах, которые обеспечивают ее работу.
Как я уже упоминала, СК отвечает даже за те процессы в компании, которые напрямую не связаны с разработкой продукта. Например, служба качества может собирать, анализировать и контролировать деятельность пресейла с целью собрать данные для принятия решений по изменению процессов.
Если в компании нет четкой системы обеспечения качества, могут возникнуть следующие проблемы:
- Сложно воспроизводить процессы в компании. При старте очередного проекта всегда приходится выстраивать разработку с нуля. Служба качества организует все процессы один раз, а потом немного их корректирует и адаптирует под новые проекты. Например, в SimbirSoft для работы на каждом проекте внедряются таск-трекер и базовые метрики — план-факт, процент возврата задач, процент Bugfix.
- Возрастает цена ошибки. Исправить недоработку на этапе тестирования, когда продукт уже готов, — дороже, чем если выявить ее при разработке. И дешевле, если сделать это на этапе формирования требований. Служба качества помогает выстроить процессы на любых проектах, чтобы системно подойти к вопросу качества продукта и не допускать типовых ошибок в разработке до того, как приложение будет готово к релизу. Иногда от этого зависит не только прибыль, но и репутация. Например, если фармацевтическая компания не проверит новый препарат, увеличивается риск, что он окажется опасным для пациентов.
Мы на своем опыте убедились, что даже если немного отступить от стандартов и не проконтролировать качество, это может привести к неприятным последствиям на проекте.
Однажды 31 декабря по желанию заказчика мы зарелизили очередное обновление мобильного приложения для онлайн-тренировок. Спустя некоторое время из-за высокой нагрузки на сервер приложение «упало». Мы, конечно, быстро отреагировали, накатили изменения, и всё обошлось, но команде пришлось понервничать и поработать в выходные.
Чтобы такое не повторилось, доработали свои процессы. Например, создали чек-лист, по которому можно проверить, нужно ли продукту нагрузочное тестирование.
Читать полный кейс
Мы считаем, что СК нужна всем компаниям независимо от масштаба, ведь любому бизнесу необходимо контролировать процессы, предотвращать ошибки, а также вовремя выявлять и исправлять недоработки.
Мы в SimbirSoft начали выстраивать работу службы качества еще в 2012 году. Тогда были, конечно, немного другие условия, требования и бизнес-процессы. Но нижеперечисленные действия — базовые, они актуальны и сейчас. Если вы тоже хотите создать свою службу качества, вы, конечно, можете ориентироваться на этот чек-лист. Однако при этом обязательно учитывайте особенности бизнеса.
Шаг 1. Сформировать команду из штатных специалистов
Сотрудники службы качества должны быть погружены во внутренние процессы — знать обо всех тонкостях и целях компании. Можно нанять внешних специалистов, но основная часть команды должна быть из «своих».
Количество сотрудников в команде СК может быть разным — всё зависит от объема задач.
Шаг 2. Определить обязанности и сферу деятельности, разработать и внедрить стандарты
Разработайте стандарты, на основе которых СК будет оценивать качество продукта и процессы компании. Опираться можно на собственный опыт — принять в качестве эталона лучшие процессы и практики, которые уже действуют в организации. И на базовые методологии: Agile, Waterfall, канбан, ISTQB — универсальную программу тестирования — и другие. Главное — не внедрять всё подряд, а выбирать то, что подойдет вашей компании, исходя из ее целей и компетенций. Также в качестве стандартов используются основные бизнес-процессы компании, требования государства, если таковые имеются, и т. д.
За основу стандарта проведения внутренних аудитов можно взять ISO 19011 — «Руководящие указания по проведению аудита систем менеджмента». Адаптируйте его под вашу компанию. Например, мы используем этот стандарт для двух направлений.
- Основное. Поэтому оптимизировали этот стандарт таким образом, чтобы проводить параллельные аудиты быстрее. Упростили процесс интервью и сбор данных. А еще автоматически рассчитываем метрики качества и прочее.
- Дополнительное — наем сотрудников. Здесь мы ничего не меняли, так как нам подошли стандартные процессы.
Когда команда СК знает, на что ориентироваться, — можно считать, что она готова к работе уже на 50%.
Шаг 3. Отслеживать работу компании с помощью службы качества
Проводить аудиты и оценивать результаты тоже можно по ISO 19011 — это один из самых логичных и понятных стандартов. Все результаты аудитов и инцидентов фиксируются. Из этой статистики можно выделить повторяющиеся ошибки. Далее СК анализирует ошибки, которые из раза в раз встречаются в разных проектах, выявляет их причины и предлагает решения.
На внедрение службы качества мы советуем закладывать около года — за такой срок получится сформировать команду, разработать документацию и организовать основные процессы. С технической стороны создать СК можно быстро, больше всего времени уходит на психологическую адаптацию. Сотрудникам нужно погрузиться в процессы обеспечения качества, перестроиться с разработки на аналитику.
Другим отделам необходимо привыкнуть к критике от аудиторов и проникнуться доверием к ним, особенно если раньше в компании этого не было. Мы в SimbirSoft выстроили настолько доверительные отношения между командами, что после стольких лет работы коллеги стали сами приходить в службу качества с просьбой провести внеплановый аудит.
На ком лежит ответственность за качество программного обеспечения?
Agile методология разработки программного обеспечения и DevOps, и в особенности их упор на юзер экспириенс, обращают наше внимание на людей, стоящих за продуктами. Но действительно ли процесс разработки имеет значение или же цель попросту оправдывает средства? Лондонская P3X или People, Product, and Process Exchange в значительной степени сфокусирована на точке пересечения трех этих P, причем, пожалуй, последняя из них является наиболее интересной, поскольку объединила в себе самое большое количество акронимов — разработка через тестирование (TDD — test-driven development), разработка на основе поведения (BDD — behavior-driven development), непрерывная доставка (CD — continuous delivery), разработка на основе предметной области (DDD — domain-driven development) и многие другие — чтобы помочь командам определить, как систематически создавать лучшие системы.
Соучредитель Agile Testing Fellowship Джанет Грегори завершила свой основной доклад о процессе обеспечения качества программного обеспечения, попросив собравшихся поднять руки, если они чувствуют момент волшебства в своей agile-команде и чувствуют, что несут миру качество. Лишь несколько человек из аудитории, предположительно полностью состоящей из практикующих agile разработчиков, подняли руки.
Как так получилось, что с момента подписания Agile-манифеста прошло 17 лет (на момент доклада), а все еще так мало людей вышли за рамки созерцания теней на стене пещеры? Быть может, у нас все еще нет правильного диалога. Быть может, мы все еще не ведем его с правильными людьми. Или, может быть, диалог вообще не являются частью наших процессов.
В то время как манифест ставит людей и их взаимодействия выше процессов и инструментов, все же в процессах есть что-то по своей природе истинно человеческое. Возможно, изучая наши процессы, мы сможем лучше реагировать на изменения, расширять наше сотрудничество и уменьшать количество ошибок — все в целях своевременного и регулярного удовлетворения клиентов. Грегори взяла на вооружение подход к качеству, известный нам уже многие поколения, и применил его к современным agile-группам разработчиков программного обеспечения в надежде, что каждый станет совладельцем того, что выпускает в свет.
Но что такое «качество»?
Грегори отмечала, что субъективное определение качества зачастую должно быть определено заранее. Чтобы с чего-то начать определение качества, она предложила «Пять подходов к определению качества» Дэвида А. Гарвина 1984 года:
Трансцендентный (абстрактный) — Атмосфера, врожденное совершенство, универсально узнаваемые достоинства
На основе ценности — Цена и стоимость
С точки зрения пользователя — Ценность для пользователя — это то, что будут представлять большинство людей, думая о качестве
На основе продукта — Что необходимо вашим пользователи? (например, какой именно вид молока из представленных)
На основе производства — Методы, процессы, стандарты, требования, спецификации — Правильно ли мы наладили производство?
Грегори визуализировала насущность каждой категории следующим образом, где самые насущные находятся ближе к центру, и применила это к современной agile-среде.
Подход на основе производства
Во-первых, все должно работать, поэтому производственное качество лежит в основе.
Грегори утверждает, что оно предполагает проектирование через тестирование, потому что «написание чистого кода значительно сокращает количество доработок. Давайте делать правильно с первого раза, чтобы не плодить баги. Тогда мы сможем релизить с уверенностью».
TDD, практика разработки автоматизированных тестов до самого тестируемого программного обеспечения, что, в свою очередь, приводит к уменьшению связанности этого программного обеспечения, является важной частью производственного качества. Грегори процитировала исследование, в котором говорится, что команды, которые внедрили TDD, получают в итоге на 60-90 процентов меньше дефектов, чем те, кто его не практикует, но TDD отнимает в среднем на 15–30 процентов больше времени на разработку.
Многие команды сталкиваются с этим компромиссом между качеством и скоростью.
«Может случиться, что PO (Product Owner — владелец продукта) говорит, что предпочел бы качеству реализацию новой фичи. Кто должен принимать такие решения?»
Помимо TDD, Грегори рассказала, что производственные процессы включают в себя:
Написание кода для обеспечения поддерживаемости
Мониторинг логов ошибок
Исследовательское тестирование по историям (stories)
Тестирование продукта на соответствие спецификациям
Автоматическое создание тестов для быстрой обратной связи
Статический анализ платформы
Четкое определение состояния ”Готово”
Наконец, она сказала: «Практики, такие как DevOps, стараются снизить риск клиента во время релиза их клиентам».
Подход на основе продукта
Проще говоря, если производственное качество, заключается в том, чтобы что-то работало, то продуктовое качество — это обеспечение того, чтобы оно работало должным образом. Например, мы склонны платить больше за более высокое качество и мы более снисходительны, если ломается что-то, что стоит очень дешево. Исключение могут составлять бесплатные приложения, от которых мы ожидаем, что они должны хорошо работать.
Грегори отмечает, что то, что определяется как продуктовое качество, зависит от целевой аудитории. Кому-то из бухгалтеров может быть очень нужна панель для клавиатуры, которую больше не делают в большинстве портативных компьютеров в настоящее время.
Вся суть заключается в двух вопросах:
Создаем ли мы то, что нужно?
Добавляем ли мы функционал, который нужен?
Разработку через приемочные тесты (ATDD) или, как ее иногда называют, разработка на основе сюжетного тестирования — привлечение ключевых клиентов к этапу TDD
Устранение ошибок, например, командный хакатон с целью найти как можно больше багов
Исследовательское тестирование фич
Подход с точки зрения пользователя
Именно здесь точки зрения разнятся. Как сказала Грегори: «Разные люди выбирают разные вещи. У них разные желания, разные потребности. Если мы пытаемся предоставить покупателю право выбора, нам все-равно нужно удовлетворить его».
Но не забывайте, продолжила она, «мы также делаем предположение, что у потребителей достаточно информации, чтобы они могли принять квалифицированное решение».
Она рассказала о приложении, которое она когда-то использовала, которое она сочла очень недружелюбным. Оказалось, что пользователям оно нравилось, потому что он точно соответствовало их принципам работы. А она не работала в этой сфере. Все дело в удовлетворении конкретных вариантов использования конкретных пользователей.
Подход на основе ценности
Это просто то, за что люди готовы платить. Трудно судить о ценности, практически невозможно, не узнав мнение потенциальных клиентов.
Качество с точки зрения ценности, оценивается с помощью некоторой комбинации следующих факторов:
Трансцендентное качество
И, наконец, самое сложно измеримое качество — трансцендентное. Грегори объясняет, что это связано с тем, что эмоции сложно измерить, а трансцендентное качество получается сочетанием артистизма, вовлеченности и лояльности клиентов.
Как мы измеряем качество программного обеспечения?
В целом, если вы согласны со шкалой качества Гарвина, значительную долю качества программного обеспечения измерить трудно. Она процитировала Изабель Эванс относительно оценки качества программного обеспечения. Существует множество примеров производственного качества:
Количество ошибок в продакшене
Серьезность ошибок в продакшене
Количество дней с момента последнего запуска в продакшн
Количество новых обращений в службу поддержки за X дней с момента последнего релиза
Индикатор сборки остается зеленым
Нет непройденных автоматизированных тестов (случайных сбоев)
Статический анализ кода кодовой базы не выявляет проблем
Количество исправлений на низком уровне
Одни и те же баги не всплывают повторно
Также можно существует мера качества с точки зрения пользователя в форме опросов удовлетворенности пользователей.
Однако вы не можете реально измерить качество с точки зрения продукта, ценности или трансцендентное качество. Однако вы можете обсудить и оценить все пять уровней качества. Тестирование — важный показатель качества, но Грегори напоминает, что продуктовые группы не могут отрицать ценность обсуждения качества друг с другом, с пользователями и с конкурентами.
И конечно, командам необходимо соблюдать баланс между желанием избегать ошибок и скоростью разработки.
Вся команда несет ответственность за качество
Очевидно, что обеспечение качества — или попытка решить эту неверно названную невозможность — это задача не только одного отдела тестирования, которому код просто спихивается.
Вся команда владеет качеством
«Если ваша организация, если ваша компания начинает с заботы о качестве, вы, вероятно, добьетесь успеха, потому что все остальное встанет на свои места. Все будет работать естественным образом. Но если вы начнете с идеи, что скорость — это самое главное, не обращая внимания на качество, есть вероятность, что в долгосрочной перспективе вам придется много переделывать, исправлять много неподдерживаемого кода, и ваше качество будет снижаться все дальше и дальше,» — говорит Грегори.
Но она не раскрыла никакого секретного рецепта идеального стремления к качеству.
«Какие подходы к качеству вы используете, меня не волнует, но вам нужно задаться вопросом, когда вы смотрите на ваши процессы — приводит ли это к уверенности в релизах?» — говорит Грегори. «Измеряет ли качество процесса качество продукта?»
Она процитировала соавтора BDD Book 1: Discovery Себа Роуза: «Когда мера становится целью, она перестает быть хорошей мерой».
«Независимо от того, как вы это измеряете, это должно привести к разговору, дискуссии о том, что вам нужно», — говорит Грегори.
Она продолжила: «У команды есть качество, но нужно думать шире. Качество в процессах и качество в практике. Компетентность в вашей команде, компетентность в том, как вы доставляете программное обеспечение».
В конце она сказала, что любой диалог в этом направлении лучше всего начинать с людей, пытающихся решить проблему.
«Давайте встроим управление качеством в наш процесс и научимся говорить о том, что мы делаем», — сказала Грегори.
Кто ответит за качество?
У нас новая важная тема — качественная разработка IT-продуктов. Мы часто говорим на HighLoad++, как сделать нагруженные сервисы быстрыми, а на Frontend Conf — классный пользовательский интерфейс, который не тормозит. У нас регулярно есть темы про тестирование, и DevOpsConf про объединение разных процессов, включая тестирование. А про то, что можно назвать качество в целом, и как над ним комплексно работать — нет.
Исправим это на QualityConf — будем развивать культуру думать о качестве конечного продукта для пользователя на каждой стадии разработки. Привычку не зацикливаться на своей зоне ответственности, и ассоциировать качество не только с тестировщиками.
Под катом поговорим с главой программного комитета, руководителем тестирования в Тинькофф.Бизнес, создателем русскоязычного QA-сообщества Анастасией Асеевой-Нгуен о состоянии отрасли QA и миссии новой конференции.
— Настя, привет. Расскажи, пожалуйста, о себе.
Анастасия: Я руковожу тестированием в банке, отвечаю за очень большую команду — нас больше 90 человек. У нас важная бизнес-линия, мы отвечаем за экосистему для юридических лиц.
Я училась на мехмате и изначально хотела стать программистом. Но когда у меня появилось интересное предложение, я решила попробовать себя в роли тестировщика. Как ни странно, это оказалось моим призванием. Сейчас всю свою работу я вижу именно в этой отрасли.
Я ярый адепт дисциплины Quality Assurance. Мне небезразлично, какие продукты создаются, как относятся к качеству в компании, в команде и, в принципе, в процессе разработки.
Для меня очевидно, что сообщество в этом направлении недостаточно зрелое, по крайней мере в России. Не всегда мы понимаем, что обеспечение качества — это не только сам факт тестирования приложения на соответствие требованиям. Мне бы хотелось изменить эту ситуацию.
— Ты употребляешь слова Quality Assurance и тестирование. В глазах обывателя эти два термина очень часто пересекаются. Чем они отличаются, если копать глубоко?
Анастасия: Скорее, не отличаются. Тестирование — часть дисциплины Quality Assurance, это непосредственная деятельность — сам факт того, что я что-то тестирую. Видов тестирования на самом деле очень много, и за разные виды тестирования отвечают самые разные люди. Но у нас в России, когда появилась волна аутсорсеров, которые поставляют тестировщиков в компании, тестирование свелось к единственному виду.
В большинстве случаев ограничиваются только функциональным тестированием: проверяют, что то, что накодили разработчики, соответствует спецификации и всё.
— Расскажи, пожалуйста, какие еще есть дисциплины обеспечения качества? Что еще, кроме тестирования, сюда входит?
Анастасия: Quality Assurance — это, в первую очередь, про создание качественного продукта. То есть мы задаемся вопросом, какими атрибутами качества должен обладать наш продукт. Соответственно, если мы это понимаем, то можем сопоставить, кто влияет на эти атрибуты качества. Не важно, разработчик, проджект-менеджер или продуктолог — это человек, который влияет на развитие продукта, на его бэклог, на его стратегию.
Тестировщик лучше начинает осознавать свою роль. Он понимает, что его задача не только тестировать на соответствие требованиям, но и тестировать требования, подвергать сомнению формулировки, которые исходят от продуктолога, вскрывать все неявные требования и ожидания клиента. Когда мы поставляем новую функциональность нашему клиенту, мы должны действительно удовлетворить его ожидания и решить его боль. Если мы будем думать обо всех атрибутах качества, клиент будет доволен и будет понимать, что компания, чьим продуктом он пользуется, действительно заботится о его интересах, а не работает по принципу «лишь бы выпустить фичу».
— Кажется, то, что ты сейчас описала, — это задача продуктолога. Это, в принципе, не про тестирование и не про качество — это вообще про product management, нет?
Анастасия: В том числе. Quality Assurance — это не дисциплина, за которую отвечает один конкретный человек. Сейчас есть популярное направление в тестировании, подход, который называется Agile Testing. В его определении прямо звучит, что это командный подход к тестированию, который включает в себя определенный набор практик. За реализацию этого подхода отвечает вся команда, даже не обязательно, чтобы в команде был тестировщик. Вся команда ориентирована на то, чтобы доставить ценность клиенту, и чтобы эта ценность соответствовала его ожиданиям.
— Получается, что качество пересекается чуть ли не со всеми окружающими дисциплинами, накладывая рамки на всё вокруг?
Анастасия: Верно. Когда мы задумываемся о том, что хотим создать качественный продукт, мы начинаем думать о различных атрибутах качества. Например, как проверить, что мы действительно сделали фичу, которая нужна нашему клиенту.
Тут всплывает такой вид тестирования, как UAT (user acceptance testing). К сожалению, в России он редко практикуется, но иногда присутствует в SCRUM-командах, как демо для конечного клиента. В зарубежных компаниях это достаточно распространенный вид тестирования. Перед тем, как открыть функциональность для всех клиентов, мы сначала делаем UAT, то есть приглашаем конечного потребителя, который проводит тестирование и сразу дает фидбэк — действительно ли продукт соответствует ожиданиям и решает боль. Только после этого происходит масштабирование на всех остальных клиентов.
То есть мы ориентируемся на бизнес, на конечного клиента, но при этом не забываем про технологию. От технологий тоже сильно зависит качество продукта. Если у нас будет плохая архитектура, мы не сможем быстро выпускать фичи и соответствовать ожиданиям клиента. Может быть много багов при попытке масштабировать, или при попытке сделать рефакторинг мы можем что-то сломать. Это все будет влиять на удовлетворённость клиента.
С этой точки зрения, архитектура должна быть такой, чтобы мы могли писать чистый код, который позволит быстро вносить изменения и не бояться, что мы все разломаем. Чтобы итерации доработки не растягивались на несколько месяцев просто потому, что у нас так много легаси, и нужно делать длительные этапы тестирования.
— Итого уже задействованы разработчики, архитекторы, продуктологи, продакт-менеджеры, сами тестировщики. Кто еще задействован в процессе обеспечения качества?
Анастасия: Теперь представим, что мы уже доставили клиенту фичу. Очевидно, за качеством продукта нужно следить, и когда он уже в продакшене. На этом этапе могут проявиться ситуации с неочевидными сценариями, так называемые баги.
Первый вопрос — как мы работаем с этими багами после того, как уже выпустили продукт? Как мы, например, реагируем на нагрузку? Клиент будет не очень доволен, если страница загружается больше 30 секунд.
Тут вступает в игру эксплуатация или, как сейчас называют, DevOps. По факту это люди, которые отвечают за эксплуатацию продукта, когда он уже на проде. Сюда входят различные виды мониторинга. Есть даже подвид тестирования — тестирование на проде, когда мы позволяем себе что-то не тестировать до выкатки и тестируем это сразу на проде. Это ряд мероприятий с точки зрения организации инфраструктуры, которые позволяют быстро отреагировать на инцидент, повлиять на него, исправить.
Инфраструктура тоже важна. Часто бывают ситуации, когда во время теста, невозможно удостовериться, что у нас действительно все то, что мы хотели бы дать клиенту. Выкатываем на прод — и начинаем ловить неочевидные ситуации. А все потому, что инфраструктура в тесте не соответствует инфраструктуре на проде. Отсюда вытекает новый вид тестирования — тестирование инфраструктуры. Это различные конфигурации, настройки, миграция баз данных и т.д.
Отсюда возникает вопрос — возможно, команде нужно использовать инфраструктуру как код.
Я верю в то, что инфраструктура напрямую влияет на качество продукта.
Надеюсь, на конференции будет доклад с реальным кейсом. Напишите нам, если готовы на своем опыте рассказать, как инфраструктура как код влияет на качество. Инфраструктура как код позволяет проще проверять все настройки и тестировать то, что иначе просто невозможно. Поэтому в процесс разработки качественного продукта вовлекается и эксплуатация.
— А что насчет аналитики и документации?
Анастасия: Это относится больше к enterprise системам. Когда мы говорим про enterprise, сразу в голову приходят такие люди, как аналитики и системные аналитики. Иногда их называют техническими писателями. Они получают задание на написание спецификации и выполняют его, например, месяц.
Неоднократно доказано, что написание такой документации приводит в очень длительным итерациям разработки и длительным итерациям доработки, потому что в процессе тестирования выявляются баги, начинаются возвраты. В результате появляется очень много петель, которые увеличивают стоимость разработки. Кроме того, это может внести уязвимости. Мы вроде бы написали эталонный код, но потом внесли изменения, которые ломают идеально продуманную архитектуру.
В итоге получается не совсем качественный продукт, потому что в архитектуре уже появились заплатки, код в некоторых местах недостаточно покрыт тестами, потому что сроки поджимают, нужно быстрее закрыть все баги. А все потому, что в изначальной спецификации не были учтены все моменты, которые нужно реализовать.
Разработчики — не вредители и не пишут специально код с ошибками.
Если бы мы изначально продумали спецификацию, в которой были бы освещены все необходимые моменты, то всё было бы реализовано именно так, как и нужно. Но это утопия.
Наверное, написать идеальную спецификацию на 100 страниц невозможно. Поэтому нужно задуматься об альтернативных способах написания документации, специфицирования, постановки задач, которые бы приближали нас к тому, чтобы разработчик делал именно то, что надо.
Тут в голову приходят подходы из Agile — пользовательские истории с acceptance критериями. Это больше применимо для команд, которые развиваются маленькими итерациями.
— Что на счет usability-тестирования, удобства использования продукта, дизайна?
Анастасия: Это очень важный момент, потому в команде есть дизайнеры. Чаще всего дизайнерами пользуются как сервисом — либо отдел дизайнеров, либо дизайнер на аутсорсе. Часто встречаются ситуации, что вроде бы дизайнер послушал продуктолога и сделал то, что понял. Но когда приступаем к итерации, выясняется, что на самом деле сделано не то, что ожидали: дизайнер что-то забыл, не до конца продумал поведение, потому что он не в команде и не в контексте, или фронтенд разработчик не до конца понял его макет. Может понадобиться несколько итераций только из-за того, что есть проблема с понимаем дизайна фронтенд-разработчиком.
Плюс есть еще одна проблема. Сейчас набирают популярность дизайн-системы. Они на хайпе, но выгода от них не совсем очевидна.
Я сталкиваюсь с мнением, что дизайн-системы, с одной стороны, упрощают разработку, с другой стороны — накладывают очень много ограничений на интерфейс.
В итоге мы делаем не такую фичу, которую клиент хочет получить, а такую, какая удобна нам, потому что у нас уже есть определенные кубики, из которых мы можем ее сделать.
Мне кажется, на эту тему стоит обратить внимание и задуматься, действительно ли в попытке упростить работу над дизайном мы решаем клиентскую боль.
— Получается удивительно много тем, связанных Quality Assurance. В России есть конференция, на которой все их можно обсудить?
Анастасия: Есть самая старая конференция по тестированию, которая в этом году пройдет 25-й раз и так и называется — Конференция по обеспечению качества SQA Days. В основном на ней обсуждаются инструменты и конкретные подходы тестирования для функциональных тестировщиков. Как правило, в докладах на SQA Days глубоко рассматриваются конкретные области в зоне ответственности самих тестировщиков, но не комплексные мероприятия.
Это здорово помогает разобраться в различных инструментариях и подходах, как тестировать базы данных, API и т.д. Но при этом, с одной стороны, не мотивирует вовлекать в создание более качественного продукта не только тестирование. А с другой — тестировщики не становятся более вовлечены в процесс, чтобы думать о глобальной цели продукта и его бизнес-составляющей.
Я руковожу большим отделом, провожу много собеседований, которые на самом деле позволяют представить состояние отрасли в целом. Как правило, наши ребята работают в enterprise, и у них четкая зона ответственности. Коллеги, которые работают в зарубежных проектах, используют разные виды тестирования: сами могут делать нагрузочное тестирование, тестирование производительности, и даже иногда тестирование безопасности (security testing), потому что они действительно помогают команде обеспечивать продукт качеством.
Мне бы хотелось, чтобы у нас в России ребята тоже начали задумываться о том, что на функциональном тестировании отрасль не заканчивается.
— Для этого мы и организуем новую конференцию QualityConf, которая посвящена качеству, как целостной дисциплине. Расскажи про задумку подробнее, в чем основная цель конференции?
Анастасия: Мы хотим создать сообщество людей, заинтересованных делать качественные продукты. Предложить площадку, куда они смогут прийти, послушать доклады и выйти после конференции с конкретным пониманием, что нужно поменять у себя для улучшения качества.
Часто сейчас слышу запрос от консалтинга, что делать, когда есть проблемы с тестированием, с качеством. Когда начинаешь общаться с командами, видишь, что проблема не в самих тестировщиках, а в том, как выстроен процесс. Например, когда разработчики считают, что они ответственны только за написание кода, их ответственность заканчивается ровно в тот момент, когда они передали задачу в тестирование.
Не все задумываются о том, что плохо написанный некачественный код с плохой архитектурой грозит большими проблемами для проекта. Не задумываются о стоимости ошибок, о том, что баги, попавшие в продакшен, могут вылиться в большие издержки для компании и команды. Нет культуры думать об этом. Хочу, чтобы на конференции мы начали её распространять.
Я понимаю, что это не инновация.Эдвард Деминг, автор 14 постулатов качества, писал про стоимость ошибки еще в прошлом веке. На этой книге базируется Quality Assurance, как дисциплина, но, к сожалению, современная разработка, забывает про это.
— А темы непосредственно про тестирование и инструменты планируете затронуть?
Анастасия: Допускаю, что будут доклады про инструменты. Есть достаточно универсальные инструменты, с помощью которых компании и команды могут повлиять на продукт.
Все доклады глобально будут объединены одной общей миссией: донести до аудитории, что с помощью этого подхода, инструмента, метода, процесса, вида тестирования мы повлияли на качество продукта и улучшили жизнь клиента.
У нас точно не будет докладов про инструмент ради инструмента. Все доклады, которые попадут в программу, будут объединены общей целью.
— Кому будет интересно то, о чем ты говоришь, кого видишь в качестве гостей конференции?
Анастасия: У нас будут доклады для разработчиков, которым небезразлична судьба своего проекта, продукта, системы. Аналогично будет интересно тестировщикам и, как мне кажется, особенно менеджерам. Под менеджерами я имею в виду людей, которые принимают решение и могут влиять на судьбу и развитие продукта, системы, команды в том числе.
Это люди, которые задаются вопросом — как повысить качество продукта, системы. На нашей конференции они узнают про различные комплексы мероприятий и смогут понять, что у них сейчас не так, что нужно поменять.
Думаю, главный критерий — понимать, что с качеством что-то не так, и хотеть на это повлиять. Наверное, с первого раза достучаться до людей, которые считают, что и так сойдет, нам не удастся.
— Как ты думаешь, индустрия в целом созрела для того, чтобы поговорить не просто о тестировании, а о культуре качества?
Анастасия: Я считаю, что созрела. Сейчас многие компании отходят от традиционного Waterfall-подхода в сторону Agile. Идет ориентация на клиента, люди в командах действительно начинают задумываться о том, как создать качественный продукт. Даже в enterprise-компаниях происходит переориентация на повышение качества.
Судя по количеству запросов, которые возникают в сообществе, я считаю, что уже пора. Не уверена конечно, что это будет масштабная революция, но мне бы хотелось, чтобы этот переворот в сознании случился.
— Договорились! Будем прививать культуру и переворачивать сознание.
Конференция про качественную разработку IT-продуктов QualityConf состоится в Москве 7 июня. Знаете, из каких этапов складывается качественный продукт, в запасе есть кейсы успешной борьбы с багами на проде, на своей практике проверили популярные методики — нам нужен ваш опыт. Присылайте свои заявки до 1 мая, а Программный комитет поможет сфокусировать тему для общей целостности конференции.
Подключайтесь к чату , в котором обсуждаем вопросы качества и конференцию, подписывайтесь на Telegram-канал , чтобы быть в курсе новостей программы.
Обеспечение качества ПО и тестирование: что в них общего и различного?
4850
Введение
Статья приводит примеры и доводы, которые способны развеять некоторые распространенные заблуждения, касающиеся роли тестирования и обеспечения качества ПО (SQA), а также выработать рекомендации для успеха SQA-команд.
Условия тестирования и обеспечения качества ПО (QA) часто используются в IT-индустрии профессионалами тестирования (часто классифицируемыми как профессионалы по обеспечению качества).
Несмотря на то, что оба понятия видят общей целью качество продукта, принципиальное различие между ними состоит в том, что тестирование проводится после того, как продукт был создан или в случае статических испытаний после того, как документ был написан. В отличие от этого контроль качества подразумевает деятельность, которая обеспечивает качество продукта на всех этапах его создания.
Чтобы оценить различия между тестированием и QA, важно сначала понять тесно связанные с ними понятия — контроль качества (QС) и обеспечение качества (QA).
Контроль Качества (QС)
ISO9000 определяет Контроль Качества (QС) как часть менеджмента самого качества, сосредоточенную на выполнении требований по отношению к оценке количества багов (при их наличии) в продукте. Контроль качества представляет собой набор процессов/действий, направленных на оценку разработанного продукта (проекта документа, системы развития и т. д.) и показатель соответствия требованиям заказчика. Это гарантирует проверку поставляемой продукции на качество и определяет, насколько хорошо она продумана и создана. Его цель заключается в поисках дефектов и обеспечении их исправления. Таким образом, тестирование является неотъемлемой частью контроля качества.
Обеспечение качества (QA)
ISO9000 определяет обеспечение качества ПО как часть менеджмента качества, ориентированную на создание уверенности в том, что требования к устранению багов будут выполнены. Целью QA является обеспечение гарантии того, что продукт будет соответствовать ожиданиям качества заказчика. Она состоит из процессов/действий, направленных на обеспечение качества разработки продукта на каждом из его этапов. Эти действия, как правило, предшествуют развитию продукта и продолжаются, пока процесс пребывает в состоянии развития. На самом QA лежит ответственность за разработку и внедрение процессов и стандартов для улучшения жизненного цикла разработки, и обеспечение уверенности в том, что эти процессы выполняются. Фокусом QA является предотвращение дефектов на всех этапах его реализации и постоянное его совершенствование. В то время, как QA является активной деятельностью, QC – наоборот, пассивной. Примеры деятельности по обеспечению качества включают установление стандартов и процессов, проверки качества и выбор инструментов.
Отличия между обязанностями QA команд и тестировщиков:
Тестировщики выполняют планирование тестирования, анализ результатов испытаний, проверку тестов, проверки и тестирования отчетности через различные уровни испытаний.
Тема связана со специальностями:
В отличие от этого, QA-команды выполняют следующие функции:
- Реализация организационной политики касаемо качества, стандартов и процессов;
- Оказание помощи с подготовкой в области обеспечения качества и планов обеспечения качества проекта;
- Проверка соответствия процессов проекта планам качества;
- Проведение регулярных проверок проектных продуктов и процессов, а также представление регулярных оценок для высшего руководства;
- Эскалация ситуации, когда есть отклонения от руководящих принципов или стандартов.
Ведут контроль за:
- Выполнением независимых обзоров;
- Наличием процедур управления изменениями проектов;
- Наличием процедур управления конфигурациями проектов;
- Наличием ретроспективы того, что процессы планируются и воплощаются;
- Обеспечением уверенности в качестве путем развития системы жизненного цикла;
- Проведением непрерывных улучшений в процессе контроля качества и воплощением рекомендаций, основанных на усвоенных ранее уроках.
Эти атрибуты определяются как QA-обязанности команды, но следует отметить, что это не означает их развитие командой QA, а, скорее, обеспечение их реализации в манере, которая является "пригодной для целей".
В рамках своей роли по контролю качества тестировщики могут выдвигать требования по проверке образцов документов проекта, деятельности по управлению конфигурациями программного обеспечения, дизайна, кода и т.д.
Отличия между планированием испытаний и документацией в тестировании и QA:
Тестировщики подготавливают тестовые стратегии и планы, основанные на базовых тест-документах, таких как бизнес-требования и проектные решения. Эти документы планирования тестирования являются основой испытания процессов на различных запланированных испытательных уровнях. Эти уровни и есть тест приемки, вход и критерии выходов между уровнями, подробные графики испытаний, экологические требования, управление дефектами, управление тестированием и ведение отчетности.
В отличии от этого, обеспечение качества программного продукта или планы качества включают более широкий набор действий на протяжении всех этапов разработки. Это играет свою роль в разработке методологий управления проектами, например Prince2, которая поощряет использование планов по качеству проекта и журналов качества, которые были разработаны в начале жизненного цикла, при инициировании проекта.
Типичный проект плана качества включает в себя ожидания клиентов, критерии приемки, плановый контроль качества и аудита процессов, планы управления конфигурациями и процедуры управления изменениями. Планы по качеству для проектов используют политику самой организации в этой сфере, стандарты или руководящие принципы, являющие собой основы обеспечения качества.
Мониторинг плана обеспечения качества проекта в ходе создания проекта осуществляется беспрерывно и обновляет результаты планируемого качества деятельности в журнале.
Существуют различные точки пересечения между управлением рисками и качеством, и поэтому реестр рисков может сделать весомый взнос в подготовку планов по качеству.
Кто выполняет функцию обеспечения качества в организации
Потребность в команде по обеспечению качества программного обеспечения растет с размером организации и уровнем ее политики в области качества. Там, где требуется такая команда, очень важно, чтобы функция QA оставалась независимой от проекта и оперативных групп. Их линия связи, однако, должна предоставлять им мощную поддержку именно в том виде, в каком это требуется.
Видео курсы по схожей тематике:
Основы тестирования ПО
Тестирование безопасности веб-приложений
Unit тестирование в C#
Некоторые организации имеют функцию QA, встроенную в их предприятия отдельным звеном — Офисом управления проектами. Это отвечает критериям независимости, однако, организации, что следуют этой модели, необходимо убедиться, что эта команда состоит из обученных и/или специализированных аналитиков по обеспечению качества.
Наблюдения и рекомендации для успешных QA-команд
В то время как Вы берете на себя ответственность за обеспечение качества программного обеспечения, Вы можете испытать целый ряд проблем. Некоторые из этих проблем очерчены ниже.
- Независимость
Чтобы быть успешными, QA-команды должны быть независимыми от проекта и оперативных групп. Это обеспечивает команде возможность проведения объективной оценки проектов.
Возникает вопрос: следует ли функциям тестирования и QA находиться в одной команде? Это может хорошо работать в небольших организациях, однако появляется недостаток в виде создания возможного конфликта интересов при мониторинге деятельности тестирования. Это и подчеркивает заблуждение в том, что тестирование и QA являются синонимическими понятиями.
Решение проблемы: в зависимости от политики самой организации в сфере качества, она может иметь отдельную команду отчетности для старшего менеджера, отвечающего за функции.
- Отношения внутри команды
Если аналитики обеспечения качества слишком процессно-ориентированные и настаивают на процессах или документации, которые могут не иметь особого значения, это может ухудшать отношения с руководителями проекта.
QA-команде будет намного легче работать с проектными группами, если они держат в уме "пригодный для целей" принцип. Предоставление помощи и содействия проектных команд формирует основу для поддержания хороших отношений, что является важным аспектом успешного тестирования.
- Завлечение нужных людей
Еще один ингредиент для успешной деятельности QA-команд – качественная кадровая политика. Люди с опытом в области разработки жизненного цикла системы или программного обеспечения, будут хорошими кандидатами для роли в QA. Некоторые знания в рамках ISO и принципов CMMI дополнили бы знания того, кто уже имеет опыт в развитии процесса и неподдельный интерес к качеству.
- Контрольные списки
Стандартные контрольные списки являются полезным механизмом для проведения аудита проектов, особенно если они разработаны в соответствии с фазами жизненного цикла разработки. Например, на этапе проектирования в перечень вопросов может быть снесено: "Есть ли прослеживаемость между дизайном и требованиями элементов?"
Чтобы избежать разочарования менеджеров проекта, важно обеспечение участия в проекте заинтересованных сторон, чтобы получить от них обратную связь, когда будут предложения по внесению в перечни изменений.
- Связь и отчетность
Хотя регулярная отчетность для высшего руководства очень важна, разработка правильных шаблонов и показателей, обеспечение топ-менеджеров требуемой информацией гарантирует, что этим отчетам уделяется должное внимание. Это лучше всего достигается путем проведения встреч с соответствующими представителями высшего руководства, предоставления им отчетов и получения от них отзывов и комментариев.
Командам QA необходимо постоянно получать одобрение внесения изменений в процессы контроля качества и стандартов и обеспечивать эффективное взаимодействие с заинтересованными сторонами.
- Постоянное совершенствование
Уроки, извлеченные из проектов, обеспечивают QA-команду основой для оценки процессов и рекомендациями по обеспечению качества, включая постоянные улучшения. Это включает разработку перечней, гибкость, поддерживаемость хороших отношений с заинтересованными сторонами и внесения улучшений в управленческую отчетность.
Так, непрерывные усовершенствования могут также потребовать внесения изменений в методологии разработки системы, потому QA-командам рекомендуется сохранять методологию разработки ИТ-отдела.
Преимущества
Успешная QA-команда может добавить значительную ценность для организации. Некоторые из этих преимуществ включают в себя:
Бесплатные вебинары по схожей тематике:
Как правильно составить резюме для поиска работы в международной IT-компании
Чек-лист успешной адаптации или как пройти испытательный срок в компании?
Кто есть кто в IT компании. Структуры и роли
- Повышение качества производимой продукции
- Последовательность в процесах, используемых для доставки
- Продолжение совершенствования организации процессов
- Снижение общих расходов на доставку
- Увеличение приложений для документаци по поддержке продукта
Недостатки
- Первоначальные затраты в штатном расписании аналитиков обеспечения качества ПО
- Усложнение процессов, которые могут генерировать разочарование в некоторых сотрудниках
Выводы
Сопоставление различий в деятельности и ответственности между контролем качества и обеспечением качества дает им хорошую оценку в различных условиях. QC подтверждает, что конкретные результат отвечают стандартам и спецификациям. В отличие от этого, QA является более широкой функцией, что охватывает планирование и контроль на протяжении всего жизненного цикла разработки. Тестирование, с другой стороны, является неотъемлемой частью контроля качества. Для того, чтобы организация эффективно осуществляла процессы управления качеством, эти потоки должны работать в тандеме.