Мир разработки ПО изменился. Современные гибкие методы разработки не только позволяют сократить время выпуска программных продуктов, но и значительно улучшить их качество. Многое написано о замечательных фреймворках для контроля качества и производительности внутри процесса разработки.
Клиенты заказной разработки
Однако многие организации в сегменте российского крупного бизнеса, в том числе и те, которые традиционно считаются высокотехнологичными — банки, телеком, ритейл – похоже, остаются в стороне от этого тренда. Как мне кажется, для этого есть две основные причины: большая доля заказной разработки и специфика тендерных процедур.
Если банк или государственная организация покупают заказную разработку критичного для бизнеса программного обеспечения, то у них очень мало возможностей повлиять на процесс разработки. Применение современных подходов к контролю качества остается полностью на совести исполнителя. А в тендерах часто побеждает компания, которая дала меньшую цену. Победившая компания больше всего заботится о минимизации собственных затрат, поэтому сложные фреймворки, непрерывная интеграция, юнит-тесты и многое другое – иногда просто отсутствуют в повестке дня.
Важность независимого тестирования при заказной разработке
Наша компания Перфоманс Лаб, как вы должно быть знаете, оказывает услуги по независимому тестированию программного обеспечения. И у нас был случай, когда очередной релиз фронт-офисной банковской системы наша команда протестировала 16 раз, прежде чем разработчик устранил все найденные дефекты высокого приоритета. Конечно, это сильно отбросило банк назад в конкурентной гонке и заставило задуматься о том, что мы делаем не так?
Есть один анекдот, про то как американского астронавта Уолтера Ширру спросили журналисты о чем он думает, сидя в кресле пилота перед стартом. Он ответил: «Я смотрю на все эти ряды индикаторов, рычажков, кнопок и думаю: А ведь эту штуку изготовил тот, кто на правительственном тендере дал меньшую цену!».
Тенденции на рынке заказной разработки
Не думаю, что ситуация на российском рынке существенно изменится в ближайшие годы. Банки, ритейлеры и, особенно, госсектор не откажутся от заказной разработки в пользу собственной. И вряд ли сильно изменятся тендерные процедуры. Что же делать? Я позволю себе дать три простых совета, которые помогут заказчикам уменьшить риски, связанные с низким качеством заказной разработки.
- Подходите ответственно к согласованию программы методики испытаний (ПМИ).Желательно, чтобы в согласовании с вашей стороны принимал участие тест-аналитик с сертификатом ISTQB, для которого выражение «тестовое покрытие» это измеримая величина. Хорошо, если в методику включены санити-тесты и тесты производительности.
- Заставьте разработчика применять статический анализ кода. Да, вы не можете контролировать работу программистов в реальном времени, но вы вполне можете включить в договор условие приемки – отсутствие критических замечаний при проверке кода в FXCop(или в другом подходящем инструменте).
- Сделайте обязательным написание и применение юнит-тестов. Опять же, вы можете включить в договор требование к минимальному покрытию кода юнит-тестами, в процентах, которое будете проверять при помощи подходящего инструментария Code Coverage и проводить code review на своей стороне.
Если терминология обеспечения качества вам не близка, и такие выражения, как тестовое покрытие, юнит-тесты и статический анализ кода– непонятны, то вы всегда можете обратиться за бесплатной консультацией в Перфоманс Лаб.
Напоследок расскажу, как мой совет №2 помог одному из наших клиентов в разы ускорить выпуск продукта. В ходе исполнения регулярного сервиса по тестированию было замечено, что исправленные дефекты часто появляются вновь, и нам приходится возвращать релиз на доработку. Ведущий инженер по качеству предложил провести статический анализ кода. Статический анализ показал, что код на 60% состоит из дубликатов. Дубликаты – это размноженные одинаковые блоки программного кода. Это значит, что исправленный в одном блоке кода дефект мы, с большой вероятностью, найдем снова. Мы посоветовали нашему клиенту использовать статический анализ кода в процессе приемки и следить за тем, чтобы уровень дубликатов не превышал 3%. Количество ретестов уменьшилось в несколько раз и скорость выпуска продукта значительно выросла.
Об авторе
Юрий Ковалев — ИТ-профессионал со стажем более 15 лет. Юрий является совладельцем и основателем компании Перфоманс Лаб — глобальной компании, специализирующейся на тестировании и обеспечении качества ПО. Основной фокус в бизнесе — стратегическое развитие компании и внедрение инноваций в области QA в сегменте крупного бизнеса.
