На что влияет уровень риска тестирование
Риски и метрики в автоматизации тестирования
Добрый день!
Бизнес любит измерять, менеджмент любит прозрачность, а сотрудники не любят всю эту бумажную работу, в особенности если от них хотят неизвестно что… Процессы автоматизации тестирования не исключение. Я приведу 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 могут быстро принести хорошие результаты. Эффективность тестирования на основе рисков и развертывания будет определяться рядом важных факторов: строгим и хорошо структурированным анализом, планом тестирования и его выполнением, а также надлежащим обменом информацией со всеми заинтересованными сторонами проекта.
Тестирование, основанное на рисках
Для обеспечения качества информационного продукта в медицине, страховании, банкинге и других отраслях, наряду с другими методами тестирования, важно использовать тестирование, основанное на рисках. Для проверки выбирают самые рискованные области создаваемого программного обеспечения. Это позволяет предусмотреть негативные сценарии и успешно реализовать бизнес-цели заказчика.
В статье расскажем, как мы в компании SimbirSoft работали с рисками (на примере системы интернет-эквайринга и других проектов) и какие методики оценки и управления рисками мы используем в проектах заказчиков.
Риски на старте проекта
Для начала приведем пример из нашей практики в разработке для банковского сектора.
Предложение заказчика: сделать акцент на веб-версии банка для физических лиц.
Выявленный нами риск: возможная потеря аудитории из-за низкого спроса веб-версии у физических лиц, в отличие от мобильного клиент-банка.
Наши аргументы: статистика предпочтений пользователей на основе отзывов и распределения аудитории по мобильной и веб-версии.
Выводы: физическим лицам более удобна мобильная версия, так как телефон всегда под рукой. Операции совершаются быстро, система авторизации позволяет получить доступ ко всем удобным услугам. В этом случае важен быстрый доступ к ограниченному набору самых популярных функций.
Юридическим лицам важна полнота предоставляемых функций, возможность выгрузки, распечатки и работа с большим объемом информации. Для этого более удобна веб-версия.
Наше решение: сделать акцент на мобильном клиент-банке для физических лиц.
В начале работы с проектом важно правильно выбрать стратегию тестирования. Рассмотрим на примерах, почему она важна и как ее выбирать.
Стратегия тестирования должна отвечать бизнес-целям
Рано или поздно все компании сталкиваются с необходимостью организовать процесс тестирования и приходят к пониманию, что выстраивание его стратегии — важный этап разработки ПО. Порой — через собственный горький опыт. Особенно опасно недооценивать роль тестирования и подбора стратегии при разработке масштабных проектов. Процесс тестирования должен подбираться под бизнес-цели и специфику проекта, иначе не приведет к положительным результатам ни через месяц, ни через год.
Например, рассмотрим тестирование мобильного и веб-приложения для банка. На старте проекта мы подобрали стратегию, основанную на требованиях с невысоким уровнем детализации. Мы использовали чек-листы, чтобы сократить время на тестирование и поддержку тестового базиса. По мере роста функциональности, добавления эквайринга, sms-авторизации и оповещения, более сложных систем чек-листы уже не справлялись со своей задачей. Со временем в команду подключалось все больше QA-специалистов, нужно было передавать информацию и координировать их действия. С усложнением продукта любое изменение могло повлиять на смежные функции, то есть возрастал риск регрессии. Назревала необходимость автоматизации регрессионных тестов, поэтому мы переключились на тест-кейсы.
Вывод: в зависимости от проекта, его специфики или этапа разработки стратегия тестирования меняется.
Стратегию нужно подбирать под цели проекта, чтобы наилучшим способом обеспечить качество выпускаемого продукта. Она отвечает на вопросы «что», «где» и «когда» будет тестироваться. В любой момент времени вы знаете, в какой точке находитесь и куда придете в дальнейшем — согласно стратегии.
Бизнес-целью может быть обеспечение безопасности данных заказчика, а также самого ПО на этапе продакшена. Безопасность начинается с процесса разработки и продолжается на этапе тестирования.
Например, на одном из проектов мы создали безопасную среду для разработки и тестирования, разворачивали инфраструктуру, которая соответствовала всем требованиям и помогала защитить данные. Запрашивали сертифицированные токены и именные флешки для каждого QA-специалиста для доступа к тестовой инфраструктуре. Так мы обеспечивали бизнес-цель проекта в безопасности ПО и сохраняли конфиденциальность данных клиента и пользователя.
За счет стратегии тестирования можно сделать акцент на действительно важных аспектах для конкретного проекта. Логично, что выпуск мобильной игры или сложной банковской CRM-системы требует разных подходов к тестированию.
Стратегия тестирования в банковской сфере
Мы в компании SimbirSoft в своей практике применяли весь спектр методологий разработки, но приоритетными для нас всегда остаются гибкие технологии. И даже там, где по ряду причин нет возможности их использовать, команда берет на вооружение лучшие практики и применяет их в повседневной работе. Тестирование становится органичной частью всего процесса и вливается в общий воркфлоу. В этом случае оно отвечает не только за качество продукта, но даже за качество всего процесса работы.
Какие технологии мы используем:
Также к основным целям тестирования — поиск дефектов и проверка ПО на соответствие требованиям — могут добавляться дополнительные. Например, банкам важно быстро внедрять новые требования Центробанка. Это значит, что к основной цели добавится своевременное выполнение тестирования с требуемым качеством для критичных задач.
Недавно в проекте банковской сферы мы столкнулись с изменением в федеральном законодательстве — повышением ставки НДС с 18% до 20%. Для адаптации под изменение законодательства была проделана предварительная большая работа, так как изменение касалось не только замены форм, интерфейсов, но и переделки логики нескольких формул расчета. Необходимо было обеспечить правильное отображение на многих платформах. Также в функции отложенного платежа нужно было учесть переходный период со ставками 18% и 20%.
Теперь расскажем более подробно о том, как мы выстраиваем стратегию и почему часто выбираем тестирование на основе рисков.
Плюсы тестирования на основе рисков
Существует несколько стратегий тестирования, которые выбираются под определенные цели:
Один из видов стратегии, основанной на требованиях — тестирование на основе рисков. При этом в первую очередь тестируются те части функциональности системы, которые наиболее подвержены рискам. Риск — это возможное негативное последствие неправильной работы системы. Последствие является риском при наличии двух составляющих, таких как возможность и негативность.
Риски бывают двух типов:
Он может быть управляемым и неуправляемым. В примере выше мы столкнулись с управляемым риском: быстрый рост и усложнение функциональности, в связи с чем повышалась вероятность регрессии. Здесь мы решали проблему наличием понятной тестовой базы и последующей автоматизацией. Тот риск, на который мы не можем повлиять — зависимость от внешних систем и их отказ в процессе интеграции. Здесь мы закладываем мероприятия, которые позволят снизить их влияние на нашу систему. Например, использование резервного копирования, обработка исключительных случаев, вывод предупреждений для пользователя.
Например, на проекте мы столкнулись с тем, что заказчик раньше не работал с распределенной командой, в связи с чем используемый воркфлоу не отвечал требованиям и создавал дополнительные коммуникационные проблемы: отсутствие понимания, дублирование задач, выполнение взаимоисключающих задач и так далее. Мы договорились о перестройке и улучшении процесса — переработали воркфлоу, познакомили всех членов команды, провели митинги, презентации и ретроспективы. В итоге работа пошла в нужном русле.
Risk-based подход позволяет составить некое количество рисков, за короткий срок протестировать риски с высоким приоритетом и дальше предоставлять заказчику метрики, насколько качественно их протестировали, показывая количество запланированных и пройденных кейсов и количество дефектов.
Имплементация risk-based подхода на проекте проходит в четыре этапа:
Risk Identification — на этом этапе нужно проидентифицировать риски и получить их список.
Risk Assessment — здесь мы анализируем список и классифицируем его по приоритетности.
Risk Mitigation — на этом этапе определяем, как глубоко будем тестировать риски.
Risk Management — здесь решаем, как дальше будем работать с ними и проходить их, идентифицировать новые риски.
Риски выявляются и оцениваются группой заинтересованных сторон в ходе сессий мозговых штурмов. В команду должны входить бизнес-аналитики или носители знаний о системе от заказчика, разработчики, менеджер или руководитель проекта, архитекторы, QA-специалисты. К выявлению и оценке рисков мы привлекаем в том числе специалистов по информационной безопасности, сотрудников, которые непосредственно работают с текущей системой, бизнес-аналитика, который погружен в процессы.
Рассмотрим risk-based подход на примере тестирования системы интернет-эквайринга.
Работа с рисками (на примере системы интернет-эквайринга)
Выделим следующие требования:
D1.Обеспечение 1000 одновременных подключений к системе в секунду.
D2. Безопасность совершения транзакций.
D3. Доступ к транзакции должен быть только у лица, совершающего транзакции.
D4. Обеспечение и поддержка стандарта SET (Secure Electronic Transaction).
В качестве риска продукта мы можем выделить:
RP1. Падение системы при одновременных подключениях.
RP2. Использование SQL инъекций в процессе совершения транзакции.
RP3. Доступ к чужой транзакции при смене параметров в URL.
RP4. Потеря данных при обрыве связи с банком в момент совершения транзакции.
RP5. Использование недействующих сертификатов при обеспечении системы SET (Secure Electronic Transaction).
В качестве организационных рисков:
RO1. Падение разрабатываемой системы из-за недоступности внешних систем.
RO2. Наличие трудно воспроизводимых кейсов, которые не могут быть обнаружены в тестовой среде.
Таким образом, каждый риск логически вытекает из требований, которые есть в системе, но не ограничивается ими. Риски дополняют требования и выявляют дополнительные кейсы, которые могут возникнуть при работе с системой.
Риски могут быть снижены или компенсированы в зависимости от целей проекта и требований к системе. Принимается условие, чтобы риск был покрыт тест-кейсом хотя бы один раз:
1. На каждый продуктовый риск подготавливается набор тест-кейсов RP1-RP4 с условием, что каждое требование и каждый риск должен быть покрыт хотя бы одним тест-кейсом. В зависимости от целей тестирования происходит расширение набора тест-кейсов до определенного уровня детализации.
2. На каждый организационный риск подготавливается список мероприятий, которые могут снизить влияние риска на разрабатываемый продукт.
Методики оценки и управления рисками
Существует несколько методик оценки и управления рисками: легковесные методы (PRAM, PRISMA) и более формальные (FMEA, FTA).
При модели FMEA команда проекта выявляет все процессы, компоненты, модули системы, в которых может произойти отказ системы или ошибка, способные привести к ухудшению качества продукта. В ходе брейншторма определяются риски системы по трем показателям: серьезность, приоритетность, вероятность. Затем просчитывается Risk Priority Number для каждого риска и в зависимости от показателей закладывается глубина тестирования.
При модели FTA поэтапно определяются все причины, которые могут привести к дефектам в бизнес-процессах системы. Анализ проходит от самого высокого до самого низкого уровня. Разница между FMEA и FTA в том, что первый подход сосредоточен на функциональности системы, а второй — на бизнес-процессах.
Помимо этих формальных и тяжеловесных подходов существуют более гибкие и неформальные. Например, методы PRAM (Прагматический анализ и управление рисками) и PRISMA (Управление рисками продукта). Они успешно и легко комбинируют стратегии, основанные на риске и требованиях. В основном в этих подходах используют спецификации требований в качестве входных данных, но в процессе могут участвовать и заинтересованные стороны.
Легковесные методы анализа рисков очень похожи на формальные. Они делают упор на технические или коммерческие риски, взвешивая вероятность возникновения риска и факторы, влияющие на эту вероятность.
Однако, единственные два фактора, используемые этими методами — это вероятность риска и его влияние. Кроме того, в этих подходах применяют упрощенные качественные суждения и шкалы для принятия решения.
Наши команды используют гибкие легковесные методы и адаптируют подходы PRAM и PRISMA под свои цели.
Как мы работаем с тестированием на основе рисков
Например, на одном из проектов мы определяем проектные и продуктовые риски, которые могут сработать. Для этого в анализе участвуют аналитики, разработчики и QA — по одному представителю от команды.
Формируется таблица рисков с продуктами. По ним определяется оценка вероятности срабатывания риска и его возможного влияния на систему по пятибалльной шкале. В таблице 1 — самое сильное влияние, 5 — самое слабое. Также и для вероятности 1 — большая вероятность, 5 — небольшая вероятность.
Как мы дальше работаем с рисками продукта
Далее по каждому из них происходит трассировка покрытия риска продукта тест-кейсами.
Выбираем следующие проверки:
TC1. Проверка нагрузки при наличии более 1000 подключений к системе
ТС2. Проверка нагрузки при 1000 подключений к системе
ТС3. Ввод SQL-инъекции во время совершения транзакции
ТС4. Ввод SQL-инъекции на странице успешной транзакции, путем подстановки других данных
ТС5. Ввод XSS (Cross-Site Scripting) скриптов в доступные поля для ввода при совершении транзакции
ТС6. Имитация разрыва связи с интернетом в процессе транзакции
ТС7. Выход из сеанса транзакции на этапе подтверждения
ТС8. Проверка просроченных сертификатов при совершении транзакции
Таким образом, приоритетные проверки — это TC2, ТС4, ТС5.
ТС6 и ТС8 имеют высокое влияние, но меньшую вероятность, поэтому приоритет проверки по ним ниже, но проверки тоже обязательны.
ТС7 не относится ни к одному из требований, но расширяет проверку на негативный сценарий, который возможен при стабильной работе системы.
Как мы дальше работаем с рисками проекта
Также определяем действия для проектных рисков, по которым назначаем дополнительные мероприятия и решения.
По риску «RO2. Наличие трудновоспроизводимых кейсов, которые не могут быть обнаружены в тестовой среде» можно предпринять следующее:
Запасной план
Важно иметь план действий на тот случай, если один из продуктовых или проектных рисков сработает. Иногда может спасти настройка системы резервного копирования проекта. Не всегда можно снизить риск до минимального уровня, но должна быть возможность уменьшить хотя бы его последствия. На эту тему был наш пост «Рождественская история»: как может сработать риск, вероятность которого стремится к нулю.
Например, мы должны полностью исключить потерю данных во время транзакции, но учесть все случаи слишком трудозатратно. Поэтому нужно иметь способы обработки таких случаев. Один из вариантов подстраховки — разработка более подробного логирования. Это обеспечит постоянную точку отката к предыдущему действию, если в процессе совершения транзакции что-то пошло не так.