Ваше ПО — работает, но этого недостаточно. В наше время качество приложений имеет гораздо большее значение, чем многие думают. Опрошенные порталом InformationWeek эксперты объясняют, с чем это связано.
Качество приложений — это уже не только функциональное соответствие требованиям. С годами приложения и производственные среды становятся все более сложными, а ожидания пользователей повышаются. Значение качества ПО сегодня значительно выросло и определяется такими критериями, которые многие команды применяют частично или вообще не применяют. Большинство организаций работают на высококонкурентном рынке, что требует от них повышенного внимания к качеству приложений, но немало работает и на внутреннем рынке (скажем, вы единственная традиционная энергетическая компания, работающая в определенном регионе), где отсутствует конкурентная среда. У последних может отсутствовать мотивация к повышению репутации, потому что у людей нет иного выбора, кроме, скажем, установки солнечных батарей.
Легкомысленное отношение к приложению означает, что предприятие видит лишь часть картины и не до конца понимает, помогает ли его ПО продвигаться к бизнес-целям. «Исторически мы думали о внешней стене. Мы пишем требования, проектируем, пишем код, тестируем его и отправляем в производственную среду. Теперь все вокруг меняется. Я работаю в облаке, вызываю сторонние API. Я живу в очень динамичном мире, где так много составляющих и переменных, — сказал старший аналитик Gartner Томас Мерфи. — Мне нужно удостовериться в удобстве применения, проверить производительность, мне нужно понять, как работает программа. Есть ли функции, которые никто не использует, потому что они не очень удобны? Может мы что-то пропустили? Если отсутствующая функция важна для нас с точки зрения бизнеса — нам нужно исправить это».
Комплексный взгляд на качество
По словам Нэнси Касл, исполнительного директора по тестированию сервисов агентства цифровой трансформации SPR, практика тестирования ПО в основном сосредоточена на правильности, включая соблюдение функциональных требований, точность вычислений, правильность навигации, производительность и масштабируемость, но упускает из вида другие атрибуты качества. «Соответствующие атрибуты качества должны изначально включаться в требования к ПО. Это должно происходить во время проектирования архитектуры продукта и кодирования. Они должны проходить независимые проверки при помощи различных методов», — сказала она.
По ее мнению, основные аспекты качества должны включать следующее:
- безопасность. Предотвращение злонамеренных/случайных действий, потенциальной кражи или потери информации, а также защиту конфиденциальности данных;
- совместимость. Обмен данными или сервисами с другими приложениями, работающими на других операционных платформах, базах данных или протоколах;
- эксплуатационная выносливость. Способность ПО поддерживать изменения;
- надежность. Способность ПО работать в различных условиях и стабильно обеспечивать правильные результаты;
- многократное применение. Применение программного компонента в другом приложении с небольшими изменениями или без изменений;
- обеспечение поддержки. Предоставление полезной информации для выявления и решения проблем;
- тестируемость. Проведение тестов ПО по заранее определенным критериям и поиск дефектов;
- удобство применения. Проведение тестов, чтобы определить насколько приложение удобно для пользователя, насколько оно легкое в освоении, обладает ли интуитивно понятным пользовательским интерфейсом и простой навигацией по меню.
Как наладить работу по оценке качества ПО
Одним из сдерживающих компании факторов по-прежнему является тестирование. Многие из них продолжают придерживаться устаревшего образа мышления, тогда как практика тестирования качества приложений резко изменились. Достаточно заметить, что некоторые консультанты могут быстро оценить его состояние на предприятии из разговора с людьми. Например, тестирование ПО проводится редко или постоянно? Понимают ли ваши разработчики приложений или ИТ-руководство, что такое качество кода и как его достичь? Проводите ли вы тестирование на выявление уязвимостей и моделирование угроз на поздних этапах или на протяжении всего жизненного цикла разработки приложений?
Препятствием для прогресса могут быть инструменты. Например, за последние несколько лет инструменты для тестирования пользовательского интерфейса значительно улучшились, но улучшились ли инструменты для тестирования инфраструктуры? Могут ли DevOps-инженеры и платформенные разработчики должным образом протестировать создаваемую ими инфраструктуру или нет?
По словам Мерфи, самой сложной задачей является выявление первопричины проблем с качеством. «Я хочу понять, когда и почему у меня появляются ошибки. Я задаю себе вопрос, когда я их исправлю, — говорит он. — Если я замечаю, что мы создаем множество ошибок определенного типа, меня в первую очередь волнует предмет их происхождения. Они появились из-за недостаточной квалификации разработчиков? Виноваты стиль или практика? Ответы на эти вопросы помогают мне понять, на чем сосредоточить внимание».
Установить уровень зрелости по обеспечению качества софта конкретной организации слишком сложно — это связано с неопределенностью самой модели зрелости, к тому же для каждой компании она может быть разной. Как вариант, организация может обратиться за помощью к услугам консультантов. Они помогут составить общую картину того, на каком уровне обеспечения уровня качества находится команда или организация по сравнению с конкурентами, преобразуют бизнес-цели в императивы качества, составят дорожную карту для улучшения качества приложений, которая позволит с течением времени улучшить его.
