Как правило, разработчики не сомневаются, что созданное ими ПО будет обладать отличным качеством. Однако чтобы это действительно было так, важно до начала проекта составить план обеспечения качества и договориться о том, что считать хорошим качеством ПО. Рекомендуем данный материал менеджерам проектов и всем, ответственным за реализацию ИТ-проектов.
Начнем с азов
Планируя любое начинание, важно учесть все нюансы, не оставляя ничего на волю случая. Это касается не только проектов по разработке программного обеспечения. Будь то свадьба, ремонт или отпуск, один неучтенный момент – и вся затея может обернуться провалом.
Что принимается во внимание при планировании ИТ-проекта? Требования заказчика, объем работ, бюджет, сроки. Важно также подобрать наиболее эффективные инструменты и специалистов с необходимыми навыками.
Ничего не забыли? Качество. Да, его тоже нужно планировать. Поверьте на слово: качество не менее важно, чем сроки, бюджет, человеческие ресурсы и технологии. И если вы его не запланируете, вы рискуете столкнуться с проблемами на поздних этапах проекта, устранение которых может принести много головной боли.
План обеспечения качества: что в него включать?
У каждого проекта есть план действий. Помимо этого, у каждого проекта обязательно должен быть план обеспечения качества (SQA-план). К сожалению, немногие знают, как этот план выглядит и что в него нужно вписать.
Часто SQA-планом считают план тестирования. Спешим вас заверить: это две разные вещи, хотя и тесно переплетающиеся. План тестирования описывает стратегию активностей по тестированию, а план качества должен включать в себя ожидания клиентов, критерии приемки, работы по плановому контролю качества и аудиту процессов, процедуры управления изменениями.
Для того чтобы проект соответствовал целям, ради которых он был предпринят, убедитесь в том, что у вас разработан план качества, который одобрен и заказчиком, и командой по тестированию.
Для разработки такого плана необходимо выполнить три шага.
Определите критерии хорошего качества
Наиболее простой способ определить, что такое хорошо и что такое плохо – проанализировать свой предыдущий опыт. Вспомните, что вызывало недовольство клиента, на что жаловались пользователи на форумах и в сторах. Может, ваш продукт был слишком медленным? Или в нем было слишком много дефектов? Или платежи в нем были небезопасны? Ответьте на эти вопросы и составьте перечень всех критических аспектов (производительность, удобство пользования, безопасность).
Поставьте измеримые цели по качеству
Звучно странно? Действительно, бюджет измеряется в денежном выражении, сроки — в конкретных датах. Как же измерить качество? Сейчас расскажем.
После того как вы составили список всех критических аспектов качества вашего продукта, подумайте, как измерить каждый из них.
Например:
- Если вам важно количество дефектов, вы можете воспользоваться термином «плотность дефектов» (defect density). Плотность дефектов – количество дефектов в компоненте или системе, разделенное на размер компонента или системы (выраженный в конкретных единицах измерения, например строках кода).
- Если важна производительность, целесообразно говорить о времени отклика ПО (выражается в секундах), скорости передачи информации (байты в секунду) или выдерживаемой нагрузке (количество пользователей, которые могут одновременно эффективно пользоваться системой).
Определив существенные для вас метрики качества, поставьте реальные, достижимые цели, которые и станут вашим ориентиром при работе над проектом.
У вас есть опыт постановки целей по качеству? Можете смело на него опираться. Однако часто, планируя очередной проект, менеджеры хотят улучшить ранее достигнутые показатели. Если это ваш случай, то измерьте метрики прошлого проекта и поставьте новые цели с положительными изменениями.
Запланируйте работы по качеству
Определение требований к качеству – это еще не конец истории. Достижение заданных целей требует действий.
Существует три вида активностей по достижению заданного качества продукта: обнаружение дефектов, исправление дефектов и предотвращение их появления.
Активности по обнаружению дефектов направлены на поиск и изоляцию багов в написанном коде. У вас есть команда по тестированию, которая проверяет ПО, сообщает о найденных дефектах и проверяет их исправление? Отлично! Но не слишком ли поздно включается тестирование?
Попробуйте снизить затраты на тестирование через следующие механизмы:
- Анализ дизайна (design review) и анализ написанного кода (code review). Анализ кода особенно важен для критических мест в приложении (механизмы аутентификации, обработка финансовых операций и т.д.). Очевидные преимущества данной практики: улучшается общее качество кода, код приходит к единому стилю, обнаруживаются глупые ошибки и опечатки.
- Test-Driven Development (Разработка через тестирование). При данном подходе написанию определенного функционала предшествует разработка набора приемочных тестов. Данный подход разработки позволяет выпускать высококачественный код, а также устранить многие проблемы, возникающие при сопровождении такого кода.
За исправление дефекта несет ответственность разработчик, написавший код. После отчета об исправлении дефекта специалисты по тестированию проводят регрессионное тестирование, чтобы убедиться в том, что исправлением не были задеты другие области продукта.
И последняя (по порядку, но не по значимости) активность – это предотвращение появления дефектов. Помните высказывание, предписываемое Бенджамину Франклину? Легче болезнь предупредить, чем потом её лечить.
Проактивное управление качеством проекта давно доказало свою эффективность не только в теории, но и на практике. Что помогает предусмотреть возможные дефекты? Тщательный анализ требований к ПО, анализ потенциальных рисков, выбор наиболее эффективной методологии разработки, набора средств, документирование требований заказчика и ожиданий пользователя.
Конечно, за грамотным анализом рисков на стадии проектирования приложения лучше обратиться к специалистам. Бизнес-аналитики и консультанты по качеству окажут надежную поддержку до написания кода и помогут избежать затрат на переделки.
Заключение
Подведем итог. Сегодня вы узнали о том, как важно планировать качество продукта. Надеемся, что мы смогли вас убедить в важности планирования качества. Вы также узнали о том, как пошагово разработать эффективный и реализуемый план по качеству вашего ПО.
Остались вопросы?
Свяжитесь с нами через форму обратной связи.
