«Банковские технологии»: Итак, что же такое тестирование программного обеспечения (ПО)?
Павел Эйделанд: Ответов на этот вопрос много. Например, Wikipedia утверждает, что тестирование программного обеспечения -- это процесс исследования программного обеспечения с целью получения информации о качестве продукта. Также можно сказать, что тестирование является неотъемлемой частью процесса обеспечения качества программного обеспечения. Тестирование не ставит своей целью поиск дефектов или написание тестовых сценариев, внедрение системы регистрации и обработки ошибок (bug tracking system). Все перечисленное является всего лишь средствами для достижения глобальной цели -- обеспечения качества конечного продукта для пользователя. А непосредственная задача тестирования -- контроль качества.
«Б. Т.»: Что понимается под словом качество? Можно ли определить формальные критерии качества?
П. Э.: Один из методологов RUP (Rational Unified Process, одна из наиболее распространенных методологий разработки программного обеспечения) Филипп Крухтен так определил качество: «Качество -- это соответствие ожиданиям пользователя». Процесс тестирования как раз пытается формализовать понятие «качество», определить методы, которыми оно будет контролироваться и измеряться, и численно выразить то, насколько конечный пользователь будет удовлетворен в итоге.
Что касается программного обеспечения: если необходимо обеспечить заранее определенный уровень качества, то в компании должен присутствовать процесс тестирования определенного уровня. Когда заказчик наших услуг по тестированию задает вопрос: «Что «Аплана» может предложить в сфере тестирования?», то я всегда ему отвечаю: «Гарантированно высокий уровень внедряемых процессов, что позволяет обеспечить и высокий уровень качества».
«Б. Т.»: Какие виды тестирования существуют? Что может ожидать конечный пользователь от проведенного тестирования?
П. Э.: Применительно к ПО можно выделить несколько основных видов тестирования.
1. Ручное функциональное тестирование. Тестирование на уровне конечного пользователя части или продукта в целом, а также тестирование взаимодействия с другими продуктами. Наиболее востребованная на текущий момент услуга, которую у нас заказывают.
2. Автоматизированное функциональное тестирование. Аналог ручного функционального тестирования с той лишь разницей, что тестирование выполняется программой-роботом, а не человеком. Тестирование выполняется значительно быстрее, но является менее гибким. Также для использования автоматизированного тестирования могут потребоваться достаточно высокие навыки программирования.
3. Нагрузочное тестирование. Определение или сбор показателей производительности программно-технической системы. Выполняется посредством подачи на систему определенной нагрузки, эмулирующей работу множества реальных пользователей одновременно. Также с помощью этого вида тестирования определяется степень соответствия собранных показателей заявленным требованиям к системе. В этом виде тестирования мы очень тесно взаимодействуем с ИТ-специалистами заказчика.
4. Юнит-тестирование. Часть этапа программирования, которая позволяет проверить ожидаемую работоспособность частей кода программы. При использовании этого вида тестирования проверяется логика работы отдельных функций и процедур в коде, в том числе на то, что добавление нового функционала не привело к ошибкам в существующем ПО.
5. Тестирование безопасности приложений. Оценка уязвимости программного обеспечения к различного рода атакам извне и изнутри: взломам пароля, DDoS-атакам, «червям» и проч.
Ручное функциональное тестирование в свою очередь можно разделить на несколько категорий:
1. Тестирование требований к продукту на корректность, обеспечение классического трио для требований: полноты, однозначности и непротиворечивости.
2. Тестирование продукта на соответствие заявленным требованиям. Например, для каждого требования из технического задания тест-аналитики «Апланы» вырабатывают несколько вариантов его проверки, чтобы быть максимально уверенными в том, что даже мелкие детали требования были реализованы корректно.
3. Тестирование продукта на соответствие неформальным требованиям конечного пользователя. Зачастую желания конечного пользователя не находят отражения в формальных требованиях, остаются не выраженными на бумаге. Для раннего устранения таких разночтений мы проводим предварительное интервьюирование пользователей и сравнение их требований с реализацией.
4. Тестирование сопроводительной документации -- руководств пользователя, администратора, прочей документации, поставляемой с продуктом.
5. Кросс-платформенное или кросс-браузерное тестирование. Актуально, если продукт будет использоваться в разных операционных системах или должен корректно отображаться в разных браузерах.
6. Интеграционное тестирование -- тестирование взаимодействий продукта с другими продуктами в едином программно-аппаратном окружении.
7. Тестирование удобства использования продукта (Usability). Всегда можно улучшить расположение элементов управления, удобство отчетов и других мелочей, создающих у пользователя конечное впечатление о продукте.
Аналогично можно классифицировать и остальные типы тестирования.
Тестирование -- это вполне устоявшаяся отрасль ИТ-рынка, которая уже имеет и свою структуру, и своих специалистов, а наша компания занимает здесь одну из лидирующих позиций.
«Б. Т.»: Какое же тестирование вы рекомендуете проводить, если необходимо внедрить новый продукт или выпустить новую версию уже используемого продукта?
П. Э.: Каждый из видов тестирования может использоваться по отдельности или в сочетании друг с другом в зависимости от потребностей. Например, можно проводить тестирование продукта на соответствие заявленным требованиям, но не проводить нагрузочное тестирование, если есть возможность провести только один вид тестирования или имеется уверенность в запасе производительности. Но, как показывает опыт наших проектов, решение о том, какой вид тестирования действительно необходим, следует принимать только после тщательного обследования системы.
«Б. Т.»: И все-таки, зачем нужно организовывать тестирование специально, если конечные пользователи всегда могут сами проверить качество продукта?
П. Э.: Тестирование служит неким барьером, отделяющим пользователей продукта от его разработчиков. Приведу пример: работая на одном из наших проектов, в ходе которого мы тестировали интернет-банк, я заметил, что у пользователей и разработчиков стояли совершенно разные задачи по отношению к внедряемому продукту. Разработчикам нужно было сдать продукт в эксплуатацию во что бы то ни стало, а пользователи готовы были приобрести продукт, но только хорошего качества и в нужный им срок. Так как такой подход диктовался потребностями участников (разработчиков и пользователей), то для предотвращения конфликта интересов на сцену пригласили нас -- команду тестирования. С одной стороны, мы действовали в интересах конечных пользователей, отстаивая качество продукта и его соответствие заявленным требованиям. С другой стороны, помогали и разработчикам, так как наши сотрудники в большинстве своем имеют технический склад ума. Таким образом, коммуникации команды разработки с командой тестирования осуществлялись гораздо легче.
«Б. Т.»: А если проблем в коммуникациях между пользователями и разработчиками нет, то третью сторону можно не вовлекать?
П. Э.: Если тестирование отсутствует, и продукт сразу же отдается конечным пользователям, то качество работы разработчиков напрямую влияет на работу конечных пользователей в начальный отрезок времени после внедрения. В случае наличия ошибок отрицательные моменты накапливаются, складывается негативный имидж поставщика продукта, который очень тяжело исправить. Недостаточное качество поставленного производителем продукта (от чего никто не застрахован) сразу же влечет большие потери для пользователей в случае наличия критических для бизнеса ошибок. Если же конечные пользователи не являются заказчиками продукта, а только его потребителями (например, пользователи интернет-банка или интернет-магазина), то компания, которая внедрила продукт, понесет еще и репутационные потери. Привлекая «Аплану», внедряющая компания получает уверенность, что негативной реакции пользователей не будет.
Кроме того, если нет тестирования, то как узнать перед внедрением, удовлетворяет ли продукт требованиям, которые выдвигались к нему при постановке задачи? Есть всего два пути: довериться разработчику или проверить. Даже отличная репутация поставщика не дает стопроцентную гарантию отсутствия ошибок и точного понимания требований. Кроме того, поставщики практически никогда явно не указывают, какие проверки продукта выполнялись перед передачей пользователю. А когда мы тестируем ПО, наш заказчик всегда знает что и как мы проверяем и какие последствия могут иметь те или иные недостатки систем.
«Б. Т.»: Что же такое правильно построенный процесс тестирования?
П. Э.: О тестировании можно говорить так же, как и о любом другом процессе в организации. Как и у остальных процессов, можно выделить несколько уровней зрелости тестирования. Согласно TMMI (Test Maturity Model Integration, аналог популярной градации зрелости ИТ-процессов CMMI) тестирование можно разделить на пять уровней зрелости с соответствующими этапами: I -- начальный (приемка продукта непосредственно конечными пользователями), II -- управляемый (тестовое окружение, планирование тестирования, проектирование и выполнение тестов, автоматизация тестирования), III -- определенный (подразделение для тестирования, жизненный цикл тестирования, нефункциональное тестирование), IV -- измеряемый (измерение тестирования, оценка качества продукта), V -- непрерывно оптимизируемый (предотвращение дефектов, оптимизация процесса тестирования, контроль качества).
Конечно, идеальным можно назвать только процесс пятого уровня зрелости, но говорить о хорошем уровне тестирования в организации можно уже начиная с четвертого уровня. В нашем проекте «Фабрика тестирования» в Сбербанке России мы смогли наблюдать все преимущества от перехода процессов тестирования на более высокие уровни. Например, мало было иметь подразделение для тестирования (второй уровень), а также зафиксировать и формализовать жизненный цикл тестирования (установленные сроки, ответственные за тестовые среды, отдельный бюджет, план тестирования -- третий уровень). Только на четвертом уровне зрелости процессов тестирования появилось измерение всех процессов и количественные оценки качества поставленного продукта. После чего польза от этих переходов стала очевидна и подкреплена цифрами. Деятельность же отдела тестирования стала более прозрачной и очевидной руководству.
Кроме того, с ростом уровня зрелости меняются и цели самого тестирования. Если на начальном уровне цель тестирования состоит лишь в том, чтобы показать, сможет ли вообще новый продукт работать после внедрения (а возможно, что проверка идет уже во время опытной эксплуатации продукта в промышленной системе), то на пятом уровне зрелости процесс тестирования направлен даже на предотвращение возникновения ошибок при внедрении продукта. Это очень важный момент, например, для тех наших заказчиков, для которых ошибки систем в промышленной эксплуатации приводят к гигантским финансовым потерям.
«Б. Т.»: Как оценить эффективность процесса тестирования?
П. Э.: Наличие правильно организованного процесса тестирования, который мы всегда стараемся наладить у нашего заказчика, увеличивает доступность продуктов и, соответственно, снижает время простоя в работе. Под доступностью понимается процент времени от ожидаемого, в течение которого продукт работает без вынужденного прекращения доступа со стороны конечных пользователей. Например, если система должна работать в режиме 24/7, а в реальности в среднем недоступна два часа в месяц, то ее доступность составляет 99,96%. По оценкам аналитиков ИТ-рынка (Alinean, Gartner) прямые потери data-центров при недоступности их мощностей превышают 1,5 млн руб. в час. Потери же организаций, которые являются конечными пользователями их услуг, могут быть больше в десятки и сотни раз. Повышение доступности критичной бизнес-системы с 99,5% до 99,9% снижает потери компании от недоступности систем, связанных с программными сбоями, в 5 раз.
«Б. Т.»: Расскажите немного об опыте внедрения процессов тестирования и наиболее часто возникающих при этом вопросах.
П. Э.: Внедрение правильного процесса тестирования в первую очередь снижает риски конечных пользователей, а в качестве дополнительного преимущества делает для них процесс разработки более прозрачным и дружелюбным. Пользователи видят, что ИТ-отдел внедряющей компании следит за качеством передаваемых конечным пользователям продуктов, а не просто стремится быстрее внедрить то, что передал разработчик.
И еще один пример из практики: в одном из наших проектов была задача выстроить процесс тестирования у заказчика. Когда мы начали разрабатывать нормативные документы для этих процессов, то вновь убедились, что тезис «Тестирование -- это часть жизненного цикла разработки ПО» верен на 100%. Все регламенты по тестированию у нас неминуемо пересекались с документами по остальным дисциплинам, начиная от заведения требований на разработку и заканчивая регламентами внедрения ПО в промышленную эксплуатацию и обработке поступающих от пользователей замечаний. Таким образом, чтобы выстроить правильный процесс тестирования потребовалось изменить сам процесс разработки, в итоге в выигрыше оказались все участники.
Журнал «Банковские технологии», №8, 2012 г.