Рано или поздно многие организации, использующие то или иное программное обеспечение приходят к необходимости организовывать процесс тестирования. Причин обычно несколько, либо это стартап, который сразу требует тестирования своего ПО, либо руководство начинает понимать, что помимо тестирования бизнесом, сопровождением, разработкой да всеми кого только можно привлечь в компании все таки требуются профессиональные специалисты по тестированию, которые разгрузят всех других людей, не имеющих никакого нормального представления о тестировании, И вот именно с этого момента зачастую начинается традиционное для нашей работы назначение одного из текущих сотрудников на должность руководителя отдела тестирования. Мол, вот тебе поле, засеивай… А как, что ты будешь делать не важно, но отдел должен быть и должен приносить результаты. Конечно, не всегда бывает все так плохо, кто-то все таки ищет на эту должность грамотных специалистов по тестированию, но тем не менее процесса тестирования на этом этапе все равно нет и его нужно создавать.
Моделирование бизнес-процесса тестирования ПО в ELMA
И очень часто многие руководители начинают создавать процесс тестирования не системно, а выборочно. Но при этом, если организовывать процесс тестирования, выдирая просто лучшие практики, не имея при этом системного подхода, то такой процесс не принесет положительных результатов ни через месяц, ни через год.
Я думаю многие знают, что если процесс тестирования с самого начала организовать не правильно, то потом изменить его будет уже крайне сложно. Поэтому нужно определить, как же правильно организовать процесс тестирования?
С чего же начинать организацию процесса тестирования?
Я выделяю 11 основных критериев в организации процесса тестирования:
- Цели и область тестирования
- Команда
- Управление
- Коммуникация и взаимодействие
- Методология тестирования
- Документированность процесса
- Управление рисками
- Измерение процесса
- Инструменты
- Тестовые среды
- Совершенствование процесса
Именно выполнение всех этих критериев позволяет равномерно развивать процесс тестирования, что в короткие сроки позволяет достигать того уровня, когда процесс тестирования будет приносить положительные результаты.
Поэтому, любой руководитель, перед которым стоит задача организации процесса тестирования, должен задать следующие вопросы:
- Зачем нам нужно тестирование?
- Что мы имеем, чтобы сделать тестирование?
- Какие процессы нужно формализовать или создать?
- Как и что мы должны тестировать?
Только после того, как мы получим ответы на эти вопросы, можно начинать переходить к стандартам.
Я выделяю следующие стандарты, которые действительно нужно изучить перед тем, как начинать строить процесс:
- ISO 29119
- IEEE 8291008
- TPI Nexthttps://www.performance-lab.ru/blog/osnovnye-printsipy-organizatsii-protsessa-testirovaniya» target=»_blank»]www.performance-lab.ru[/mask_link]
Денис Кудряшов. Тестирование бизнес-логики на примере Camunda BPM
Тестирование приложения и среды Azure
Тестирование является фундаментальным компонентом DevOps и гибкой разработки в целом. Если автоматизация дает DevOps необходимую скорость и гибкость для быстрого развертывания программного обеспечения, то только обширное тестирование этих развертываний обеспечивает необходимую надежность, необходимую клиентам.
Main принципом надежности системы является принцип «сдвиг влево». Если разработка и развертывание приложения — это процесс, показанный в виде последовательности шагов, идущих слева направо, тестирование не должно ограничиваться самым завершением процесса. Он должен быть смещен как можно больше в начало, то есть влево, насколько это возможно. Чем раньше обнаружена ошибка, тем дешевле и проще ее устранить. На более поздних этапах жизненного цикла приложения это может быть дорого и даже невозможно.
Тестирование должно выполняться во всем коде, включая код приложения, шаблоны инфраструктуры и скрипты конфигурации. Как описано в разделе Повторяемая инфраструктура, среда, в которой выполняются приложения, должна управляться версиями и развертываться с помощью тех же механизмов, что и код приложения. Затем среду можно протестировать и проверить с помощью тех же парадигм тестирования, которые команды уже используют для кода приложения.
Для автоматизации и оптимизации различных видов тестирования доступен ряд средств тестирования. К этим средствам относятся нагрузочное тестирование Azure, Azure Pipelines для автоматического тестирования и Azure Test Plans для ручного тестирования.
Существует несколько этапов, на которых можно выполнять тесты в жизненном цикле кода, и каждый из них имеет особенности, которые важно понимать. В этом руководстве приводятся общие сведения по различным тестам, которые следует рассматривать при разработке и развертывании приложений.
Автоматическое тестирование
Автоматизация тестов — лучший способ убедиться, что они используются согласованно. В зависимости от частоты выполнения тестов они обычно ограничены по длительности и область, как показано ниже.
Модульное тестирование
Модульные тесты — это тесты, которые обычно выполняются в рамках процедуры непрерывной интеграции. Модульные тесты должны быть обширными и быстрыми, в идеале охватывающими 100 % кода и выполняющимися в течение 30 секунд.
Модульное тестирование может убедиться, что синтаксис и функции отдельных модулей кода работают так, как они должны, например, создавать определенные выходные данные для известных входных данных. Модульные тесты также можно использовать для проверки допустимости ресурсов кода инфраструктуры как кода.
Модульные тесты должны применяться ко всем ресурсам кода, включая шаблоны и скрипты.
Тестирование состояния
Тесты состояния проверяют, что рабочая нагрузка может быть создана в тестовой среде и выполняется должным образом. Тесты дыма не идут в степень интеграционных тестов, так как тесты состояния не проверяют совместимость различных компонентов.
Вместо этого они проверяют, работает ли методология развертывания как для инфраструктуры, так и для приложения, и что система реагирует должным образом после завершения процесса.
Тестирование интеграции
Убедившись, что различные компоненты приложения работают по отдельности, интеграционное тестирование определяет, могут ли они взаимодействовать друг с другом должным образом.
Запуск большого набора тестов интеграции может занять значительное время, поэтому тесты должны выполняться как можно раньше (принцип сдвига влево) в жизненном цикле разработки программного обеспечения. Интеграционные тесты следует зарезервировать для сценариев, которые нельзя тестировать с помощью тестового или модульного теста.
При необходимости длительные тестовые процессы могут выполняться с регулярным интервалом. Регулярный интервал обеспечивает хорошую компрометацию, обнаруживая проблемы взаимодействия между компонентами приложения не позднее чем через день после их внедрения.
Тестирование вручную
Ручное тестирование обходится дороже, чем автоматическое тестирование, поэтому обычно оно выполняется реже. Ручное тестирование имеет основополагающее значение для правильной работы цикла обратной связи DevOps. Он исправляет ошибки до того, как они станут слишком дорогими для ремонта или вызывают недовольство клиентов.
Приемочное тестирование
В зависимости от контекста приемочное тестирование иногда выполняется вручную. Она может быть частично или полностью автоматизирована. Его цель — определить, соответствует ли система программного обеспечения спецификациям.
Main цель этого теста — оценить соответствие системы бизнес-требованиям и проверить, соответствует ли она необходимым критериям для доставки конечным пользователям.
Средства, включающие анализ использования с помощью Application Insights , помогут вам определить, как пользователи используют ваше приложение. Эти средства позволяют решить, улучшила ли новая функция ваши приложения, не вызывая непреднамеренных неблагоприятных последствий.
В следующем разделе этой статьи рассматриваются методы тестирования в рабочей среде, которые можно использовать для проверки соответствия функций бизнес-целям с реальным поведением пользователей.
Тестирование и экспериментирование в рабочей среде
В зависимости от выбранной стратегии развертывания функции платформы Azure могут помочь в проведении экспериментов в рабочей среде.
Служба приложений Azure, например, поставляется с функциями слотов для настройки промежуточных сред , которые позволяют одновременно работать с двумя разными версиями одного приложения. Слоты позволяют использовать A/B-тестирование, направляя часть пользовательского трафика в одну версию приложения, а остальную часть трафика — в другую.
Существует несколько популярных подходов к экспериментам в рабочей среде:
- Синие и зеленые развертывания: При развертывании новой версии приложения ее можно развернуть параллельно с существующей. Параллельное развертывание позволяет начать перенаправление клиентов на новую версию. Если все пойдет хорошо, вы можете списыть старую версию. При возникновении проблем с новым развертыванием можно перенаправить пользователей обратно в развертывание с предыдущей версией.
- Canary выпуски: Вы можете предоставить новые функциональные возможности приложения ошеломленным способом для выбора групп пользователей. Вы можете расширить функциональные возможности для более крупной группы пользователей, если:
- Пользователи удовлетворены новыми функциями.
- Функциональность работает должным образом с группой элементов управления.
нагрузочное тестирование
Как описано в других разделах по этой платформе, учет масштабируемости при проектировании кода приложения и инфраструктуры имеет первостепенную важность. Стресс-тесты помогают регулярно проверять, адаптируется ли приложение и среда к изменяющимся условиям нагрузки.
Во время этих нагрузочных тестов крайне важно отслеживать все компоненты системы, чтобы выявить потенциальные узкие места и установить четкие базовые показатели для тестирования.
Каждый компонент системы, который не может масштабироваться, может стать ограничением масштабирования, например активными или пассивными сетевыми компонентами или базами данных. Важно знать ограничения компонентов, чтобы можно было уменьшить их влияние при масштабировании приложений.
Другой важной частью нагрузочных тестов является проверка того, что инфраструктура вернется к нормальному состоянию, чтобы держать затраты под контролем.
Тестирование непрерывности бизнес-процессов
Тестирование непрерывности бизнес-процессов предоставляет возможности для улучшения методов предотвращения и восстановления крупномасштабных инцидентов. Это также повышает устойчивость к повседневным инцидентам, таким как изолированный сбой оборудования или повреждение данных.
Отработка аварийного восстановления
Отработка аварийного восстановления важна для проверки того, что существующая стратегия резервного копирования дополняется рабочей процедурой восстановления. Эти учения следует проводить регулярно.
Такие средства, как Azure Site Recovery позволяют запустить изолированную копию основного расположения рабочей нагрузки в дополнительной среде, чтобы убедиться, что рабочая нагрузка восстановлена должным образом в аварийной ситуации.
В случае возникновения проблемы во время отработки можно оптимизировать процедуру аварийного восстановления и безопасно удалить инфраструктуру в дополнительной среде.
Произвольное тестирование
Во время исследовательского тестирования эксперты полностью изучают приложение, пытаясь найти ошибки или неоптимальные реализации функциональных возможностей. Этими экспертами могут быть разработчики, специалисты по пользовательскому опыту, владельцы продуктов, реальные пользователи и другие.
Структурированные планы тестирования обычно не используются, так как тестирование предоставляется отдельным тестировщиком.
Внедрение ошибок
Проверка внедрения ошибок, если приложение устойчиво к сбоям инфраструктуры. Метод вызывает ошибки в базовой инфраструктуре и наблюдает за поведением приложения.
Тестирование внедрения ошибок является фундаментальным для укрепления доверия к механизмам избыточности. Завершение работы компонентов инфраструктуры, намеренное снижение производительности или внедрение ошибок — это способ убедиться, что приложение будет реагировать ожидаемым образом при возникновении таких ситуаций.
Такие продукты, как Azure Chaos Studio , призваны упростить процесс тестирования внедрения ошибок. Многие крупные организации создали собственные механизмы хаоса, которые используют средства автоматического тестирования для внедрения ошибок.
Сводка
Чтобы можно было быстро и надежно развертывать программное обеспечение, необходимо выполнять тестирование при разработке и развертывании. Важно убедиться, что приложение будет работать должным образом в любой ситуации. Поэтому нам нужно не только тестировать код приложения, но и все аспекты нашей рабочей нагрузки.
Источник: learn.microsoft.com
Home
В поисках формата для рассказа о практиках тестирования я обратилась к гуглу с запросами “с чего начинать тестирование ПО” и “как подготовиться к тестированию ПО”. И нашла статьи о том, что нужно уточнять требования, применять техники и т. д. Хм… А что, если “составляющими контроля качества ПО” и даже в своем роде глоссариями в том самом поиске и стали стандарты и производные об этапах STLS? Да, все это необходимо – но недостаточно, подумала я.
И если вы, при наличии всех процессов тестирования,
- выводили в PROD не то, что протестировали;
- тестируете не то, что нужно;
- находите баги в PROD, которых точно нет в тесте;
- вынуждены много раз тестировать одно и то же из-за процессных сбоев
– знайте, эта статья для вас.
Велосипед не едет, если у тестирования нет основы. В статье я хочу рассказать, что мы предварительно настраиваем, чтобы тесты были достоверными, эффективными и предсказуемыми.
DISCLAIMER
1. Перечисленное ниже является структурой “предподготовки”, а не готовым шаблоном. Инструменты, подходы, процессы представлены на правах примеров. По уму они должны выбираться исходя из особенностей проекта и продукта. Эти кейсы подходят большой линейке, но не всей (особенно боюсь поднять халивар на тему GIT flow). В любом случае, буду рада обсудить другие кейсы и особенности проектов в комментариях.
2. Наличие “предподготовки” позволяет обеспечить тестирование высокого уровня, но не гарантирует его. Однако при наличии базовых настроек гораздо проще отследить, где проседает тестирование, и принять меры.
3. Я намеренно опустила некоторые преднастройки, которые сильно зависят от принятого на проекте тестирования. Например, если в компании Х принято тестировать продукт серым ящиком, то очевидно, что в качестве преднастройки должен быть организован доступ к тестовым средам. Постаралась выделить самые главные, которые подходят большинству.
Коммуникации
Хорошо выстроенные коммуникации позволяют превратить формальные проверки в клиентоориентированное тестирование.
Роли в проекте
