Что определяет уровень риска в тестировании
Тестирование на основе рисков: особенности подхода и его преимущества.
Конкуренция в сфере разработки программного обеспечения очень высокая. Чтобы добиться успеха, компании стремятся с минимально возможными затратами создавать продукты максимально высокого качества. И справиться с этой задачей без эффективно настроенного QA-процесса практически невозможно.
Но проблема заключается в том, что дедлайны и бюджет редко позволяют специалистам по обеспечению качества одинаково тщательно тестировать все функции приложения. Им приходится решать, на выполнение каких задач стоит потратить больше усилий и времени, а какие не требуют столь пристального внимания. Как же они принимают такие важные решения? Полагаться на субъективное мнение членов команды — не самый оптимальный вариант. Правильно определять цели и рационально расставлять приоритеты позволяет тестирование на основе рисков.
Если вы ещё не знакомы с этим подходом, оставайтесь с нами. В этой статье мы поговорим о том, что такое тестирование на основе рисков, каковы его преимущества и что представляет собой процесс управления рисками при тестировании программного обеспечения.
Что такое тестирование на основе рисков?
Для начала давайте вспомним, что такое риск. Под риском мы подразумеваем возможность возникновения какого-либо события, которое может оказать неблагоприятное влияние на проект. Уровень риска определяется двумя факторами: вероятность наступления события и величина ущерба, который оно может нанести.
И именно уровень риска может служить надёжным параметром для расстановки приоритетов в тестировании программного обеспечения. Очевидно, что при неограниченном количестве возможных тестовых сценариев и ограниченных ресурсах имеет смысл приложить максимум усилий на тестирование функций, которые используются чаще всего и некорректная работа которых может нанести наибольший ущерб.
То есть, QA команда должна ответить на два вопроса о каждой функции:
Представим, что специалисты по обеспечению качества работают над тестированием банковского приложения. Перед ними стоит задача проверить работу двух функций:
Очевидно, что QA команде нужно будет приложить значительно больше усилий для тестирования первой функции. Конечно, это очень упрощенный пример. (В реальности приложения намного сложнее и специалисты должны проверять работу сотен элементов.) Но он наглядно показывает, в чём суть тестирования на основе рисков.
Такой подход позволяет оптимизировать ресурсы и получить максимальную пользу от тестов. Расставляя приоритеты задачам, специалисты по обеспечению качества ориентируются на результаты предварительной оценки рисков.
Теперь давайте подробнее рассмотрим, что такое процесс управления рисками при тестировании программного обеспечения.
Процесс управления рисками при тестировании программного обеспечения.
Процесс управления рисками может варьироваться в зависимости от компании и сложности разрабатываемого продукта. Но, как правило, он включает следующие этапы:
Теперь, когда вы лучше понимаете процесс управления рисками при тестировании, давайте остановимся подробнее на матрице для определения приоритетов и оценки рисков.
Матрица рисков.
Для анализа рисков команды QA часто используют матрицу, где на одной стороне располагается уровень вероятности возникновения события, а на другой — степень потенциального воздействия на проект. Это позволяет разделить все риски на группы:
Конечно, в зависимости от проекта такая матрица может быть более подробной. Тогда возможным рискам будет присваиваться больше уровней вероятности. Например, частые, возможные, случайные, редкие, крайне редкие. Что касается степени потенциального воздействия, она может делиться на катастрофическую, критическую, серьёзную, приемлемую, незначительную.
Преимущества тестирования на основе рисков.
Как видите, тестирование на основе рисков позволяет компаниям эффективно управлять ограниченными ресурсами. Такой подход помогает QA командам оптимизировать свою работу, правильно расставлять приоритеты, находить самые критические ошибки раньше, а также видеть степень тестового покрытия на каждом этапе жизненного цикла разработки программного обеспечения. Таким образом, главные преимущества тестирования на основе рисков — это снижение затрат на разработку, сокращение времени выхода на рынок и повышение качества приложений.
Типы тестирования
Люди довольно часто обсуждают типы тестирования. К примеру, функциональное, регрессионное, тестирование производительности, юзабилити, доступности, безопасности, интеграции, и так далее, и тому подобное.
Все эти типы тестирования описывают тестирование по отношению к определенным интересующим нас областям. Но если задуматься, то эти типы просто описывают тестирование, особо концентрирующееся на тест-типах продуктовых рисков.
Функциональное тестирование – это тестирование, сконцентрированное на функциональных рисках. Регрессионное тестирование – это тестирование, сконцентрированное на рисках, относящихся к регрессу ПО после внесения изменений. Интеграционное тестирование – это тестирование, сконцентрированное на интеграционных рисках по отношению к фиче, компоненту или какой-то части ПО и их работе совместно с другими фичами, компонентами, или связанными с ними частями.
«Исследовательское тестирование» и «Скриптовое тестирование» – это подходы к тестированию, а «черноящичное» или «белоящичное» – техники тестирования, поэтому их я сюда не включаю.
Типы рисков
Представьте, что вы что-то тестируете. Подумайте о единице тестирования – тест-идее, которая у вас, вероятно, есть. Что движет этой идеей?
Тестируя ПО, мы связываем наши тесты с каким-то типом продуктового риска.
Под продуктовым риском я имею в виду риски, которые напрямую относятся к продукту – в отличие от бизнес-рисков, человеческих рисков, проектных рисков или прочих категорий риска, лежащих за пределами продукта.
Неважно, связан ли ваш тест с заранее созданным сценарием проверки ожиданий, или же это часть вашего исследовательского тестирования определенной идеи – этот тест вызван к жизни каким-то типом продуктового риска. Мы вводим сложные данные в поле, чтобы протестировать риск, что эти сложные данные неправильно обрабатываются. Мы симулируем десять тысяч человек, пользующихся фичей одновременно, чтобы протестировать риски, связанные с пользовательской нагрузкой. Мы используем инструменты и сравниваем ПО со стандартами доступности, чтобы протестировать риск того, что ПО не соответствует стандартам. Тест всегда относится к какому-то риску, который мы тестируем.
«XYZ-тестирование» – это тестирование, сконцентрированное на рисках XYZ. Как я уже говорил выше, рассказывая о типах тестирования, тип тестирования – это тестирование, сконцентрированное на определенном типе риска.
Но вот в чем подвох…
Знаете ли вы, что существует более сотни различных типов продуктовых рисков? Некоторые из них мы и не подумаем называть «типами тестирования».
Если бы я попросил вас назвать максимальное количество типов тестирования, вы бы отлично справились, назвав 15-20. Я пробовал просить об этом команды в разных компаниях и внутри тест-сообщества, и обычно люди сходу называют около 15. Однако если бы я попросил вас назвать различные типы продуктовых рисков, то точно знаю, что вы назвали бы больше. Спрашивая о типах продуктовых рисков те же самые группы людей, вспомнивших о 15 типах тестирования, я получал около 50-60 ответов, прежде чем заканчивалось отведенное время. Они бы и больше назвали.
Почему нужно говорить о типах рисков, а не о типах тестирования
Вы немедленно увидите ряд преимуществ, если переключите свои рассуждения с типов тестирования на типы рисков:
Осторожно, ловушки!
У этого подхода есть ряд ловушек, о которых нужно знать.
В следующей части этого цикла статей я объясню, как использовать исследовательский подход для выявления рисков, и поделюсь моделью и примерами, визуально описывающими мой ход мыслей.
Риски и метрики в автоматизации тестирования
Добрый день!
Бизнес любит измерять, менеджмент любит прозрачность, а сотрудники не любят всю эту бумажную работу, в особенности если от них хотят неизвестно что… Процессы автоматизации тестирования не исключение. Я приведу 5 рисков, которые чаще всего встречаются, которые стреляют, которые нельзя недооценивать, которые могут привести к провалу всего тестирования и проектов в целом. Также я приведу примеры метрик, добросовестное использование которых поможет успокоиться вам, вашему начальству, бизнесу.
Помимо этих рисков существуют глобальные: неверный выбор стратегии тестирования, отсутствие ООП в создании фрэймворка и тестов… Но они, в отличие от первых, приводят лишь к увеличению стоимости тестирования, а не к провалу тестирования как такового, как процесса, как идеологии, как инструмента обеспечения качества продукта, а в конечном счёте лояльности клиентов, которые приносят вам доходы. Если вы, как специалист, можете объяснить это руководству, добиться от разработчиков уважения (его надо заслужить 🙂 ), убедить всех в правильности выбранных подходов и стратегий, вы на верном пути.
Риски:
1. Если будем организовывать автоматизацию тестирования там, где она не нужна, мы выкинем кучу денег
Это первый и главный риск любого процесса. Руководители, особенно в странах постсоветского пространства, редко отличаются гибкостью. Если в голове есть представление, что автоматизация тестирования есть благо, то его будут пихать всюду где нужно и не нужно. Совсем забывается, что реальный возврат инвестиций в автоматизации тестирования возникает в лучшем случае со второго релиза. Нужно научиться объяснять бизнесу, что не всякая автоматизация даст качественное покрытие и что это будут просто выброшенные мотивация, время и деньги.
2. Если мы напишем десятки тысяч тестов, которые буду гоняться на CI в облаках, то мы обманем себя в вопросах качества
Это чаще всего встречающийся анти-паттерн. На нём остановлюсь подробнее — об остальных паттернах и анти-паттернах можно почитать здесь — синяя секция будет наиболее интересна всем, кто пишут unit-тесты. Это давно сформулированные анти-паттерны, которые уже можно отнести к аксиомам.
Без шуток — если мы допускаем тяжеловесные тесты, тесты-лжецы и так далее, мы обрекаем себя на провал проекта. Не раз, принимая участие в аудировании процессов тестирования в различных компаниях, я сталкивался с этим явлением, отговаривал автоматизаторов и руководство от написания тестов ради тестов. Некоторые слушали — и выгребали много всего плохого до внедрений, некоторые не слушали — 3 проекта рухнули в один день, хотя тестов зелёных было порядка 8000 тысяч на каждый.
CI в облаках — да, люблю эту тему. Зачем гонять функциональные тесты на сервере непрерывной интеграции, если тесты все гоняются 10 минут? Зачем CI, если релизы выкатываются раз в месяц, а не раз в день. Как и любой специалист в автоматизации тестирования, я овладел навыками создания скриптов для запуска всего этого чуда на TeamCity, но факт в том, что ни разу, в какой бы команде я ни работал, не приходилось использовать CI иначе как для сборки и прогона unit-тестов. Все функциональные тесты должны гоняться до коммита, а не после него. Я в этом убеждён… При таком подходе есть проблемы при кросскомандной работе. Но и они решаемы грамотной организацией процесса.
3. Если мы будем использовать изолированные входные данные для тестов, то пропустим Critical баги в production
В предыдущей моей статье предлагали разделить unit-тесты и функциональные авто-тесты. Я бы всё-таки старался этого не делать, и считаю, что в большинстве случаев данные не должны быть изолированными. Если мы можем внести случайность во входное поведение для теста, её обязательно надо включить. Пользователи (взывающие стороны методов, если речь идёт о unit-тестировании) всегда в среднем производят действие с данными в определённом диапазоне. Можно сделать провайдера входных данных, который опирался бы на это распределение и приблизить тем самым всё к реальности.
Например, недавно столкнулся с «фичей», которая ярким образом проявлялась у нас. Система ложилась на колени, если в ответ на запрос об оплате от банка приходил номер карточки длиной больше 16 знаков. Да, конечно, это нереально в нашем мире 16тизначных карточек, но, простите, а когда станет реально… когда клиентам банков перевыпустят карточки, и они начнут постепенно уходить из постоянных клиентов сервиса к конкурентам, а бизнес будет терять деньги, не понимая даже, что не так.
Rem: для Java любителей, — понятно, что используя reflection, можно написать инициализатор любого объекта любого класса, так как в конечном счёте это всего лишь дерево примитивов. Мало кто знает, но уже давно всё реализовано в чудесной библиотеке podam. Вот пример использования:
Также можно аннотациями задавать диапазоны значений и создавать собственные стратегии генерации. В общем — всё, что душе угодно. Намного удобней, чем вызывать setter-ы по всему дереву и, используя, Random и RandomUtils заполнять объект данными. Использование Podam либы вместе с Mockito даёт поразительные результаты с точки зрения лаконичности инициализации возвращаемых заглушкой объектов.
5. Если разработчики не понимают, зачем нужна автоматизации тестирования, не сотрудничают в этих вопросах и воспринимают всё, как обязаловку, то автоматизация тестирования будет неэффективна
При аудите я всегда начинаю с беседы с разработчиками. Оказывается, что 3 из 5 разработчиков абсолютно уверены, что эти вот тестировщики (тут уж неважно мануальные или автоматизаторы) просто проедают зарплату. На вопрос «почему вы так считаете?», ответы всегда разные, но суть одна — «нам это не нужно, потому что мы итак прекрасны». Один разработчик из 5, считает, что автоматизация тестирования нужна, что он уже сто раз ставил эти вопросы в компании, но не находил поддержки у коллег. Ещё 1 всех давно уже послал и сам пишет тесты, потому что считает это необходимым, навязывать никому ничего не хочет. Так он обеспечивает качество своей работы. В такой обстановке нужно начинать с переделывания отношения у самоуверенных разработчиков к тестированию. Иначе можно даже не пробовать ставить процессы автоматизации тестирования, потому что тесты гоняться не будут, а даже если и будут, то на результаты никто не будет обращать внимания.
Метрики
Понеслась. Умножение на 100% буду опускать — не злитесь.
1. Процент автоматизируемых тестов.
Да… Увы, не всё нужно автоматизировать и не всё возможно автоматизировать. Если у вас есть список тестов, которые хотелось бы автоматизировать, то было бы логично измерить
PA(%) = количество тестов, которые могут быть автоматизированы / количество всего тестов.
2. Процент продвижения автоматизации
AP(%) = количество автоматизированных тестов / количество тестов, которые могут быть автоматизированы.
Эта метрика очень полезна при рассмотрении во времени процесса автоматизации. Если с каждым новым спринтом этот процент падает, стоит задумать о том, почему такое происходит — пересмотреть взгляды, архитектуру, добавить при необходимости людей в команду и т.д. Конечно, стремимся тут к 100%
3. Продвижение тестирования
TP = количество написанных тестов / промежуток во времени
Полезная метрика, как для определения изменения производительности, так и для оценок сроков покрытия плана. Если производительность колеблется в диапазоне — это нормально. Если она вдруг резко падает или резко взлетает, стоит задаться вопросами. В первом случае — возможно у специалиста упала мотивация или происходят систематические ошибки с оценкой сложности работ. Во втором — возможно, создаётся видимость работы в результате сильного дробления проверок, что тоже не есть хорошо.
4. Процент покрытия
TC(%)= количество написанных тестов / количество требований
Мутная, но полезная метрика, когда речь идёт об оценке глубины покрытия. Лучше даже, наверное, брать обратную пропорцию в качестве процента… Если грамотно её использовать, например, фича-тесты в Agile, то можно не только прикинуть сколько будет тестов через несколько месяцев, но и понять, что пришло время оптимизировать что-то, чтобы сократить время прогона этих самых тестов.
5. Плотность дефектов
TC(%)= количество открытых дефектов / общий размер продукта
Крайне важная метрика, которой пренебрегают ввиду отсутствия разумной возможности оценить, что такое размер продукта. Есть классическое представление о том, что в среднем на 3 строчки кода приходится по одному дефекту. По мне так это бред, а если это так, то, простите, тестирование уже не поможет 🙂 В общем, для Scrum процесса можно в качестве этого самого размера продукта просуммировать story points, — если найденных дефектов мало, нормируйте формулу. В любом случае, это очень полезная метрика как внутри команды, так и снаружи, — особенно когда продукт готовится к выходу в свет. Вообще agile автоматизация тестирования — это отдельная песня. Желающие могут почитать про неё здесь
6. Эффективность устранения дефектов
DRE(%)= дефекты, найденные во время тестирования / (дефекты, найденные во время тестирования + дефекты, найденные пользователями в production)
Крайне важная метрика, без которой никуда. Если по результатам прогона автотестов мы имеем, допустим, 15 дефектов, исправляем их, а после выкатывания на пользователей мы замечаем ещё 15 новых и коварных, то печаль — значит не следили за метриками выше… Получив этот процент, надо как можно скорее поднять его в 100%. Так что эту метрику нужно рассматривать во времени после деплоймента. Тесты на вновь возникшие дефекты должны быть написаны немедленно и должны падать, а не проходить 🙂
Заключение:
Старайтесь придумывать метрики не для руководителей, а для себя. Старайтесь уметь объяснять не только себе, но и другим, как происходит улучшение процессов автоматизации. Показывайте, что дают те или иные технологии, по сравнению с другими, формулируя это в цифрах, понятных тем, кто ничего не смыслит в автоматизации тестирования.
6 февраля 2013 года я опубликовал статью в Journal of Mathematical Sciences (New York), 2013, 188:6, 758–760. Abstract и начало можно посмотреть здесь.
О чём там подробно рассказывать не буду, но как следствие одной из теорем, приведу пример, который так часто проявляется в провальных проектах — если каждый новый максимум количества открытых дефектов при условии, что прошлый максимум количества открытых дефектов = x, достигает значения порядка x^2, то проект оказывается в условиях равномерного распределения количества дефектов. То есть, увидев такую тенденцию, будьте готовы к тому, что перестанет работать весь функционал — причём очень быстро. Эта закономерность подтверждалась много раз на практике, да и не только с максимумами дефектов…
Скажу честно, я знаю компании, у которых, чем хуже качество, тем лучше, потому что они живут договорами на тех-поддержку и гребут большие деньги на том, что у заказчика нет никаких других альтернатив. Таким компаниям не нужна автоматизация тестирования, не нужны метрики и не нужно качество. Эта статья обращена ко всем другим компаниям, которые в конкурентной борьбе пытаются заслужить право на лояльность и деньги пользователей.
Что такое риск-тестирование?
Цель тестирования на основе рисков — сфокусироваться на ключевых функциях и уделить им больше времени.
Риск — это непредвиденное событие, которое может отрицательно повлиять на измеряемые критерии успеха проекта. Так, непредвиденные события могут повлиять на стоимость всего проекта, коммерческие, технические и качественные цели.
Что такое тестирование на основе рисков?
Тестирование на основе рисков (risk-based testing) — это метод тестирования программного обеспечения, который базируется на вероятности рисков.
Вероятность рисков определяется путем анализа, в котором учитываются сложность программы, критичность функции для бизнеса, частота ее использования и количество возможных дефектов.
При тестировании на основе рисков наибольший приоритет получает проверка самых важных и потенциально имеющих недостатки функций.
В результате, если пользователь даже и обнаружит дефект, это не помешает ему использовать приложение и не окажет существенного влияния на бизнес.
Риски продукта, проекта и процесса
Негативные риски представляют угрозу для успеха проекта, поэтому их необходимо снижать или устранять.
Существует три группы рисков, с которыми команда может столкнуться в процессе разработки программного обеспечения:
Воздействие этих рисков может повлиять как на пользователя, так и на бизнес. Последствия могут быть тяжелыми: финансовые потери из-за недовольства клиентов, штрафы, юридическая ответственность, потеря доли рынка, потеря клиентов и испорченная репутация компании.
Стратегия тестирования на основе рисков
В стратегии risk-based testing риск используется в качестве критерия во всех фазах цикла тестирования, включая планирование, проектирование, реализацию, выполнение и отчетность.
В идеале должно быть создано большое количество различных комбинаций тестовых случаев. Стратегия предполагает выявление наиболее дефектных или рискованных областей, которые могут повлиять на бизнес, и ранжирование тестов на основе серьезности рисков.
Основная цель анализа рисков — разбить по категориям элементы с высоким и низким рейтингом. Компоненты с высоким рейтингом оказываются в фокусе как автоматизированного, так и ручного тестирования. Элементам с более низким рейтингом уделяется меньше внимания.
Анализ рисков — первый шаг перед началом любого тестирования на основе рисков.
Преимущества тестирования на основе рисков
Повышенная ориентация на пользователя. Тестирование на основе рисков фокусируется на тщательной проверке функций, напрямую влияющих на пользователей, а также функций, больше всего подверженных рискам. Это повышает эффективность бизнеса и уменьшает влияние каждого выявленного риска.
Улучшение качества. В risk-based testing приоритет отдается областям, наиболее подверженным рискам. Из них в первую очередь проверяются наиболее важные функции. В результате программа может быть выпущена с гарантией того, что ее основные и важные для клиентов функциональные возможности находятся на должном уровне.
Лучшее покрытие тестированием. Когда риски обнаружены, а их потенциальное влияние оценено, становится легче решить, что тестировать, с чего начать и когда прекратить тестирование. Другими словами, становится легко определить объем тестирования, а также приоритет выполнения тестов в ограниченные сроки. Это дает каждому проекту разработки структуру, необходимую для организации сотен тестов. Эта структура может использоваться при автоматизации регрессионного тестирования.
Когда использовать тестирование на основе рисков
Риски могут возрасти из-за целого ряда факторов. В частности, из-за неудачного проектирования, плохого тайм-менеджмента и неадекватных ресурсов. Это именно те ситуации, когда следует использовать risk-based testing.
Тестирование на основе рисков в Agile
Тестирование на основе рисков имеет большие преимущества в Agile, когда для поддержания качества ПО необходимо выполнять тесты в рамках отдельных спринтов. Оно помогает создать структуру, позволяющую тестировщикам, разработчикам и другим заинтересованным сторонам четко обсуждать имеющиеся риски. При таком подходе риски разделяются, и тогда их можно идентифицировать и устранить.
В risk-based testing при определении рисков учитываются потребности потребителей и разработчиков и выделяются наиболее важные для клиентов функции. При этом создается иерархия критериев тестирования для управления бюджетами, согласования сроков и предотвращения задержек.
Выбор объектов тестирования
Итак, кто должен оценивать риски и как проходит этот процесс? Лучшие кандидаты в оценщики — те, кто хорошо осведомлен о проблемах приложения в целом.
Владельцы продуктов и архитекторы решений обычно умеют распознавать риски доставки. Те, кто разбирается в предметной области или понимают технические аспекты, могут обнаружить опасности, связанные с недостатками решения.
Тестировщики, в свою очередь, должны тщательно подбирать методы тестирования для предлагаемого решения. При неэффективной стратегии тестирования вероятность серьезного сбоя программного обеспечения при запуске в производство возрастает.
Тестирование на основе рисков включает в себя планирование, разработку и выполнение операций тестирования на основе приоритета модулей. В приоритете должны быть:
Распространенные ошибки при тестировании на основе рисков
Критически важно начать анализ рисков еще на стадиях планирования и разработки. Это позволяет должным образом проанализировать приложение и разработать эффективный подход к тестированию.
Заключение
При эффективном выполнении оценка рисков и risk-based testing могут быстро принести хорошие результаты. Эффективность тестирования на основе рисков и развертывания будет определяться рядом важных факторов: строгим и хорошо структурированным анализом, планом тестирования и его выполнением, а также надлежащим обменом информацией со всеми заинтересованными сторонами проекта.