Контроль качества IT-продукта: как разработчики это делают
Мониторинг качества IT-продукта – процесс перманентный, многоэтапный и достаточно сложный. Он проводится на протяжении всего жизненного цикла решения – через все версии и обновления. Вполне естественно, что процесс не ограничивается исключительно тестированием – есть определенные действия и до, и после непосредственно тестирования.
Кто все эти люди?
Отдел контроля качества в нашей компании представляет небольшую команду. В нее в первую очередь входит тестировщик, занимающийся unit-тестами (это тестирование отдельных фрагментов кода) и проверкой уже отработанного функционала. Также членом этой команды является тестировщик, работающий с только что выпущенным функционалом продукта. Среди его задач и проверка функциональности на соответствие техническому заданию, и проведение первичных физических тестов по подготовленным согласно техническому заданию сценариям.
Кроме того, к работе над качеством ИТ-решения подключен технический директор компании: он проводит код-ревью разработчиков – систематическую проверку исходного кода программы с целью обнаружения и исправления ошибок. Код-ревью проводится как в ходе работы над задачей, так и на финальном этапе ее завершения, непосредственно перед передачей в тестирование. Технический директор также на протяжении всей работы над задачей контролирует ход написания кода программистами и соответствие кода требованиям и принципам, принятым в компании в отношении разработки.
Схема проста: когда разработчик завершает работу над продуктом, он помещает результат в Git репозиторий продукта, а технический директор проводит код-ревью, в случае необходимости возвращая задачу на доработку. Если все отлично, и доработка не требуется, то далее продукт попадает к тому самому тестировщику. Заметим, что его работа начинается не только в этот момент: он заранее должен ознакомиться с предстоящей работой и написать сценарии, по которым будет тестировать тот или иной функционал. При возникновении ошибок или неправильной работе функции на тестах задача возвращается на доработку с описанием тех ошибок, которые были обнаружены. А после их устранения уже будет запущен новый цикл проверки.
Подчеркну, что тестирование – процесс постоянный, который идет параллельно всей текущей работе по заранее подготовленным тестам. Ведь разработка ведется очень динамично и необходимо вести постоянный контроль качества уже имеющихся в продукте функций.
За пределами кода
ИТ-продукт во многом похож на любой другой: он имеет жизненный цикл, на всем протяжении которого создатель должен отслеживать судьбу своего детища. К примеру, производитель шкафов должен знать, как ведет себя фурнитура в процессе эксплуатации, как материал, из которого изготовлено изделие реагирует на время, внешнюю среду и т.д. Это необходимо для того, чтобы как минимум не повторять предыдущих ошибок.
В случае с ИТ-продуктом ситуация аналогична: каждая следующая версия или решение не должны наступать на те же грабли. Поэтому разработчику нужна обратная связь от пользователей. К тому же именно user experience (он же пользовательский опыт) помогает в корректировке и совершенствовании дорожной карты развития продукта. Поэтому мы собираем отзывы пользователей – через техподдержку, взаимодействие менеджеров, встречи, мероприятия и т.д. Далее отзывы анализируются, изучаются сценарии использования решения, их частотность, делаются выводы о необходимости доработок (в некоторых случаях – исправления) функционала.
Нужно понимать, что у компании-разработчика и у пользователя понятие качества ИТ-продукта на этапе его эксплуатации может разниться. Для первого самое главное – это работоспособность запущенного функционала – т.е. корректность отработки решением сценариев, которые были в него заложены. У пользователя ситуация иная: ему кроме прочего важно, чтобы ИТ-продукт соответствовал его ожиданиям. Кстати, это особенно остро проявилось в период активного импортозамещения: привыкшие к одному принципу построения интерфейсов и функционалу пользователи часто были недовольны новым инструментарием именно из-за слома привычных схем. Таким образом, обратную связь мы не только отслеживаем, но и вдумчиво анализируем.
На самом деле есть множество параметров, которые необходимо изучать применительно к обеспечению качества решения. Это и количество пользователей, и нагрузка на серверы, и наиболее частотные интеграционные потребности клиентов, и возникающие в процессе развертывания сложности, и многое другое. Все это сейчас часто называют продуктовой инспекцией – и это тоже часть процесса контроля качества.
ИТ из коробки
Есть, безусловно, и специфика контроля качества коробочного ИТ-продукта (а именно к этому типу относятся наши WMS и TMS). Коробочное решение – это продукт, который позволяет развернуть определенный функционал в инфраструктуре заказчика сразу, без его разработки с нуля под требования бизнес-пользователя.
В этом случае самым действенным инструментом контроля качества по большей части является проведение стандартного сценарного тестирования с заполнением чек-листов. Но поскольку продукт модульный, данные проверки должны проходить постоянно – изменениями в каком-либо из модулей можно затронуть какую-то из основных функций. На практике такое, конечно, не происходит, но лишними проверки никогда не будут.
Опытным путем мы для себя определили, что один из важнейших параметров контроля – это гибкость в применении инструментов. Поэтому мы, во-первых, всегда открыты к использованию новых инструментов и методик. Мы отслеживаем их появление и проводим апробацию. Чаще всего мы берем на вооружение новые сценарии работы или новые функции в уже существующих сценариях. Инструменты тестирования остаются теми же, но постоянно видоизменяются в зависимости от поставленной задачи.
Одно из нововведений в тестировании продукта в нашей компании – это выезд сотрудников внедрения на склад клиента и отработка всех необходимых сценариев на его данных. Это нововведение позволяет нам получать фидбэк от клиента по функционалу, а также расширить круг сценариев тестирования, которые мы, возможно, не проверяли ранее. Ведь на практике нестандартные сценарии работы могут встречаться весьма часто, и их изучение позволяет нам поддерживать не только уровень качества достаточно высоким, но и дает идеи для переработки старых функций на более гибкие сценарии, а также информацию для разработки новых функций.
Во-вторых, мы готовы пересматривать целесообразность применения того, чем уже пользуемся. Например, составление чек-листов при проверке функционала когда-то нам казалось лишним, но опытным путем этот метод доказал свою эффективность. Чек-листы позволяют разработчику предоставить некую навигацию к месту нахождения ошибки. Ведь при исправлении каких-либо ошибок важно точно определить совершенные действия, условия и место ее возникновения – это очень сильно сокращает время ее исправления и, соответственно, ускоряет выход новых функций в продуктив.
И в-третьих, как ИТ-компания мы стремимся к автоматизации процессов, поэтому открыты к применению ИТ-решений и в процессе контроля качества.
А что потом?
А потом – самое главное. Найти проблему, выявить ее причины – это далеко не все, что необходимо. Неотъемлемым элементом является устранение недочетов и причин их возникновения. Устраняются в первую очередь функциональные проблемы по конкретной задаче, т.е. функционал приводится в соответствие с техническим заданием.
Подчеркну: даже один сотрудник в этом случае в поле воин. Если это квалифицированный QA-инженер, за небольшой промежуток времени он подготовит контрольные точки, опишет их. А уже затем, по решению команды можно выделить какой-то промежуток времени, когда все совместными усилиями проверяют какую-либо функцию и процесс, заполняя при этом чек-лист и фиксируя ошибки. По результатам такой проверки и проводятся работы, которые позволяют повысить отказоустойчивость и качество продукта в дальнейшем.
Автор: Иван Денисов, CEO GTLogistics