Стратегия тестирования Test strategy QA_Bible

Уровень детализации у тест плана как правило выше, он в своем роде уточняет тестовую стратегию, наполняет ее необходимыми деталями. Но граница между этими понятиями – условна и размыта. В тестовой стратегии могут покрываться в деталях некоторые важные моменты, в тест плане могут быть обобщения.

Тестировщики являются равноправными членами процесса. Это важный пункт командной работы. Тестировщик к девелоперу как максимум может ходить для выяснения настроек энвайронмента.

Процесс тестирования был его неотъемлемой частью. Что и продемонстрировано в статье. Наш груминг поверхностный и в нем не тратится время на выяснение ВСЕХ технических деталей.

Увидеть целостную картину работы команды и обозначить роль тестирования в ней. Благодаря четкому выполнению всего вышеописанного в последние день-два нагрузка на отдел тестирования снижается, высвобождая время для анализа проделанной работы. На первый взгляд, простой вопрос. Но ответ на него иногда вскрывает настолько неочевидные связи, что задавать его стоит в протокольном порядке. У нас был случай, когда при добавлении нового типа подписки переставала приходить рассылка, будучи соотнесенной с другими платежными планами.

В Украине границы между должностями и обязанностями QA, QC и Tester бессовестно размыты. Это вносит дополнительный хаос в и без того сложные процессы разработки. Если повезет, я напишу на эту тему отдельную статью.

Меня зовут Артем Безручко, я QA Engineer в Depositphotos. В тестировании уже 5 лет, занимаюсь как автоматизацией, так и ручным тестированием. Мне давно хотелось вынести тему тестовой стратегии на суд широкой публики. Все изложенные ниже методы и активности в большей или меньшей мере используются и выполняются тестировщиками нашей команды. Насколько это результативно, я продемонстрирую в конце статьи.

В модели HTSM дается полезная мнемоника SFDIPOT для того, чтобы структурировать подход к изучению элементов продукта. Просто пройдитесь по расшифровке этой мнемоники – и получите готовые идеи разбиения продукта на части. ‎Границу между этими 4-мя шагами не всегда просто найти. Например, мы не всегда отдаем себе отчет, когда переходим от сбора информации к анализу. Мы не всегда двигаемся последовательно от 1-го шага к 4-му, а, например, часто делаем прямой переход от 1-го сразу к 3-му. Мы также можем возвращаться назад – от принятия решений обратно к сбору информации.

Кто выигрывает от ведения документации

Следующие действия качественно влияют на процесс, поэтому я настоятельно рекомендую именно такой порядок активностей. Документация условно делится на исполнительную и повествующую. Тест-кейсы относятся к первому типу, а создание страниц во внутренней Wiki — ко второму. Это полезная процедура, она помогает закрепить комплексные понятия о разделе, а в случае необходимости провести ликбез или быстро напомнить об упущенных деталях. Поэтому не стоит упускать возможность поработать с внутренней библиотекой. Разработчик проанализирует сотни строк кода, прежде чем написать свои.

Не будем подробно на этом останавливаться, так как далеко не все проекты сталкиваются с этими мероприятиями и проходят через процесс аудита и сертификации. Но если у вас запланировано нечто подобное, будьте готовы представить свою документацию. План тестирования выполняется менеджером по тестированию или ведущим, который описывает, как тестировать, когда тестировать, кто будет тестировать и что тестировать. Стратегия тестирования — это набор руководящих принципов, которые объясняют дизайн теста и определяют, как нужно проводить тестирование. Стратегия тестирования определяется как набор руководящих принципов, которые просвещают дизайн теста и регулируют, как нужно проводить тестирование. У нас были цели и план, которые мы выполнили и достигли.

Разница между стратегией тестирования и планом тестирования

Возможно, кому-то покажется, что эта часть лучше впишется в тест-стратегию. Не стану спорить, оставлю этот вопрос дискуссионным. В зависимости от специфики проекта, список приоритетов и их описание могут быть разными. На test strategy некоторых проектах приоритет выставляет на основе влияния проблемы на бизнес-логику, а влияние на критичность функционала выставляет в поле Severity. Такие процессы очень «любят» и зачастую требуют подобные артефакты.

Разработка сделала приятную схему на API с хорошо конфигурируемыми мок-объектами, что значительно облегчило жизнь тестировщикам. Эта реклама — типичный пример их маркетинговой стратегии. Экономическая стратегия правительства вызвала огромное количество критики. Критические дефекты исправлены в рамках hotfix процесса. Пострелизное тестирование проводится на продакшене по необходимости и под руководством и надзором тестлида.

test strategy

Включает перечень всех типов тестирования, которые команда планирует проводить на проекте, а также их цели, особенности процесса по каждому из типов и критерии окончания . Например, для Smoke Testing целью будет убедиться, что основные фичи не имеют критических дефектов, и определить, что приложение готово для последующих фаз тестирования. План тестирования — это документ, в котором описываются объем, цель и вес задачи тестирования программного обеспечения, тогда как стратегия тестирования описывает, как необходимо проводить тестирование.

• Наконец было принято решение проводить ревью задач и отчетов об ошибках сразу после их создания.
• Тестовая стратегия описывает план подхода к тестированию в цикле разработки ПО.
• Но на этом процесс тестирования не заканчивается.
• Формирование тестовой стратегии – интересный процесс, который часто выполняется нами на уровне интуиции, когда мы сами не до конца осознаем, почему мы решили делать так или иначе.
• Он тестирует видение девелопера со всеми ошибками и допущениями.

В нашем случае экстраполезной активностью оказалось ревью тикетов и баг-репортов. Было время, когда у нас менялись участники команды, и в конце концов оказалось, что у каждого свое понимание предметной области. Из-за этого возникало недопонимание и множество конфликтов. Наконец было принято решение проводить ревью задач и отчетов об ошибках сразу после их создания. За несколько недель это привело всю команду к единому стилю технического описания и единой базе дефиниций. Разберемся в предпосылках появления нового подхода в создании ПО.

Смотреть что такое “test strategy” в других словарях:

Выбрать средние и большие задачи. Нацелиться на иханализ и тестирование требований. Подкоманда тестирования не чувствует своей ответственности за результат этого процесса, скажется когда придет время выполнения. Тестировщики на одну задачу для себя дополнительно ставят еще две. Наблюдается тенденция к увеличению количества задач, выполняемых непосредственно инженерами. На основе этого предполагаю, что процесс тестирования эволюционирует, поскольку механизмы и решения создаются «под проект».

Наконец все найденные баги исправлены и запланированные проверки пройдены. Тикет получил резолюцию тест-инженера. Но на этом процесс тестирования не заканчивается. Дальше идут рутинные, но очень полезные активности.

План тестирования V / s Стратегия тестирования

Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать Ваш тест план более полным и качественным. После завершения фазы разработки новой функциональности, начинается фаза стабилизации, когда разработчики занимаются только исправлением дефектов. В какой-то момент, когда скорость исправления начинает превосходить скорость открытия новых, может наступить момент, когда у вас будет 0 открытых/активных дефектов (ZB – Zero Bugs).

Каждый восьмой кастомер-баг относится к нашей команде. Общее число кастомер-проблем демонстрирует тенденцию к уменьшению, а проблемы, решение которых поручено команде, имеют постоянную характеристику. Это подтверждает, что кастомеры находят баги спустя длительный промежуток времени (ориентировочно полгода-год). На основе полученных данных необходимо внести коррективы в изначальный процесс тестирования.

Это небольшой опрос, который проводится среди сотрудников по основным технологиям и навыкам, необходимым для выполнения задач. Проводится вычитка созданных статей и тест-сьютов. Цель — выбросить ненужное и устаревшее, организовать полезное, создать задачи на документирование и исправление нужного. Обычно для создания предусловий требуется от 1 до 5 минут, а благодаря приложению это делается в3-4 клика за 10 секунд. Вроде не так уж и много, но в течение дня это экономит от 30 минут до часа.

Из диаграммы следует, что основные задачи лежат в плоскости тестирования и контроля качества. И только один раз за все время отдел взлетает на уровень обеспечения качества, с вершины анализирует пройденный путь и пытается заглянуть https://deveducation.com/ за горизонт событий, в будущее. Материал будет полезен для представителей всех технических направлений, особенно для лидов и тех, кто пока лишь задумывается о том, как построить процесс тестирования в продуктовой компании.

Набор этих решений и будет составлять основу тестовой стратегии. Когда стало понятно, что пользу от тест-плана и тест-стратегии вынесет вся команда, настало время поговорить о содержании этих документов. Содержание этих документов от проекта к проекту может отличаться, а сами документы могут существовать как по отдельности, ссылаясь друг на друга, так и тест-стратегия может быть частью тест-плана. Поскольку тест-план обновляется довольно часто, а тест-стратегия остается, как правильно, неизменной, я предпочитаю их разделять на два документа. Опыт показывает, что предназначение тест-плана и тест-стратегии знает каждый трейни, поэтому я не буду останавливаться на этом. Подробнее каждый документ мы обсудим чуть позже, а для начала давайте разберемся, какую пользу можно извлечь из этих двух документов и как они могут облегчить жизнь при разработке продукта.