Содержание
В нем необходимо отметить основные модули, связи и специфические условия — одним словом, все, что поможет любому инженеру моментально найти точки входа для быстрого развертывания процесса тестирования. Из диаграммы следует, что основные задачи лежат в плоскости тестирования и контроля качества. И только один раз за все время отдел взлетает на уровень обеспечения качества, с вершины анализирует пройденный путь и пытается заглянуть за горизонт событий, в будущее. Материал будет полезен для представителей всех технических направлений, особенно для лидов и тех, кто пока лишь задумывается о том, как построить процесс тестирования в продуктовой компании. План тестирования выполняется менеджером тестирования, а стратегия тестирования — менеджером проекта.
Эта секция тест-плана состоит из подсекций в виде командных ролей, софта для тестирования и списка окружений. Давайте разберем каждую из них чуть более детально. Критерии спринта и релиза у каждого проекта разные в зависимости от его специфики, процесса разработки и других факторов. Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать Ваш тест план более полным и качественным. Вероятно я недостаточно акцентировал на некоторых процессуальных моментах внимание, выставив на передний план самые больные проблемы и подход к их решению. Есть подкоманда девелоперов и подкоманда тестировщиков.
Например, для Smoke Testing целью будет убедиться, что основные фичи не имеют критических дефектов, и определить, что приложение готово для последующих фаз тестирования. После того, как у нас есть база знаний о продукте и его контексте – мы готовы к формированию стратегии. На данном этапе происходит ее рождение. Мы принимаем решения относительно того, как мы будем тестировать продукт. Набор этих решений и будет составлять основу тестовой стратегии.
Что такое тестовая стратегия?
Все тикеты релизного бэклога заимплеменчены, задеплоены, протестированы согласно acceptance criteria и описания тикета. Меня зовут Дмитрий Штапаук, я Business Process Architect в Techstack. Примерно 10 лет моей карьеры мне доводилось занимать роли, так или иначе связанные с тестированием . Эта реклама — типичный пример их маркетинговой стратегии.
Тестировщики не являются равноправными участниками процесса. Помимо уже описанного это еще и просто демотивирующий фактор. Все хотят работать с людьми, у которых есть чему поучиться, и очень ценят коллег, четко выполняющих свои обязанности.
- Все изложенные ниже методы и активности в большей или меньшей мере используются и выполняются тестировщиками нашей команды.
- High — тестирование должно быть проведено в полном объеме.
- Не стану спорить, оставлю этот вопрос дискуссионным.
- Полный сет ручных и автоматизированных тестов пройден после код-фриза.
- Но процесс тестирования и тестовая стратегия — это как бы несколько разные вещи.
- Это почти всегда дает не слишком высокие результаты по качеству.
Это сэкономит много времени потом и повысит качество. Для того, чтобы это утверждать надо сравнивать не количество, а «вес» severity. Если пользователи находят 1 критический дефект, а команда тестирования 13 миноров это вряд ли можно назвать хорошим результатом.
Коммуникации в жизни QA: как понимать людей и поддерживать хорошие отношения со всеми
Когда стало понятно, что пользу от тест-плана и тест-стратегии вынесет вся команда, настало время поговорить о содержании этих документов. Содержание этих документов от проекта к проекту может отличаться, а сами документы могут существовать как по отдельности, ссылаясь друг на друга, так и тест-стратегия может быть частью тест-плана. Поскольку тест-план обновляется довольно часто, а тест-стратегия остается, как правильно, неизменной, я предпочитаю их разделять на два документа.
В модели перечисляются как основные и общеизвестные критерии , так и менее ожидаемые (лично для меня), такие как Charisma. Внутри этих крупных критериев качества вы найдете более мелкие критерии, которые тоже являются своеобразными идеями того, что продукт может уметь в принципе. Границу между этими 4-мя шагами не всегда просто найти. Например, мы не всегда отдаем себе отчет, когда переходим от сбора информации к анализу. Мы не всегда двигаемся последовательно от 1-го шага к 4-му, а, например, часто делаем прямой переход от 1-го сразу к 3-му.
Также высокоуровневая документация помогает быстрее ввести в курс дела новичков и синхронизировать распределенную команду. Опыт показывает, что предназначение тест-плана и тест-стратегии знает каждый трейни, поэтому я не буду останавливаться на этом. Подробнее каждый документ мы обсудим чуть позже, а для начала давайте разберемся, какую пользу можно извлечь из этих двух документов и как они могут облегчить жизнь при разработке продукта. А потом перейдем к тому, как составить каждый из них так, чтобы они приносили пользу даже небольшой команде. Однако задача отказаться от документации и сохранения знаний не стояла.
Например, работая по скраму, можно выделить Release quality acceptance criteria и Sprint quality acceptance criteria. Формирование тестовой стратегии – интересный процесс, который часто выполняется нами на уровне интуиции, когда мы сами не до конца осознаем, почему мы решили делать так или иначе. Часто после своего https://deveducation.com/ формирования где-то на уровне интуиции стратегия так и продолжает жить там, в области неосознанного. Давайте попробуем достать её оттуда. На следующем планировании один человек из отдела тестирования берет на себя задачу под названием «Пересмотр тестовой стратегии». Для удобства разобьем ее на подсекции.
Стратегия тестирования (Test strategy)
Большинство тестировщиков стремятся уйти в автоматизацию не из-за пользы для текущего проекта, а просто потому, что модно. Рассмотрим же, что такое тестовая стратегия и как такой подход поможет проекту. Включает перечень всех типов тестирования, которые команда планирует проводить на проекте, а также их цели, особенности процесса по каждому из типов и критерии окончания .
Документация условно делится на исполнительную и повествующую. Тест-кейсы относятся к первому типу, а создание страниц во внутренней Wiki — ко второму. Это полезная процедура, она помогает закрепить комплексные понятия о разделе, а в случае необходимости провести ликбез или быстро напомнить об упущенных деталях. Поэтому не стоит упускать возможность поработать с внутренней библиотекой. Разберемся в предпосылках появления нового подхода в создании ПО. Agile был сформулирован людьми, которые занимались в основном коммерческой разработкой для компаний, выходящих на рынок, и предлагали свои решения широкому кругу пользователей.
Что и продемонстрировано в статье. Наш груминг поверхностный и в нем не тратится время на выяснение ВСЕХ технических деталей. Главная цель — понимать вектор работы. Основное исследование проводится инженером непосредственно в спринте. Оттуда и происходит такая активность.
Середина спринта (тикеты непосредственно берутся в тестирование)
По завершении тестирования тикета остается выделить кейсы для автотестов, оформить кейсы в TestLink и завести статью в Wiki. На техниках и подходах к ручному тестированию я останавливаться не буду. Надеюсь, все читатели прекрасно ими владеют. Только получив сформированный обозримый объем для тестирования, можно приступать к работе.
Преимущества ведения тестовой документации
Я хочу обсудить преимущества ведения тест-плана и тест-стратегии, а также рассказать об элементах каждого документа, которые превращают их в рабочий инструмент, полезный для всей команды. У test strategy нас практикуется изменение требований задачи непосредственно в спринте. Это требует адекватной реакции со стороны команды. Озвученные вопросы призваны страховать всех участников разработки.
Подкоманда тестирования не чувствует своей ответственности за результат этого процесса, скажется когда придет время выполнения. Тестовая стратегия помогает в том случае, если вы имеете конкретную цель. В нашем кейсе целью было успешное закрытие спринтов, уменьшение количества багов, с которыми сталкиваются пользователи в продакшене, эффективное накопление и расшаривание знаний среди сотрудников.
Результат применения тестовой стратегии
Многие из них запрашивают документацию, которая полностью регламентирует разработку продукта (управление рисками, business continuity plan, product development roadmap и т. п.). Помимо всей этой документации обычно запрашиваются документы, которые дают ответы на вопрос о комплексе мер, направленных на получение прогнозируемого качества продукта. Практически во всех случаях хорошо составленные тест-план и тест-стратегия полностью покрывают этот запрос (т. е. при условии наличия в них секций, покрывающих интересующие аспекты тестирования). Нередко тестировщики становятся козлами отпущения, виновниками всех бед и сбоев. В зависимости от процесса разработки, тестирование может проводиться на разных фазах. Например, при работе по скраму, фазы тестирования могут быть разбиты на те, которые происходят до спринта, во время спринта, приемочного тестирования и после релиза на продакшен.
Что такое план тестирования?
Была цель ускорить предоставление готовой продукции конечному потребителю. Это была последняя секция, о которой я хотел рассказать, но далеко не последняя, которая может быть в документации. В зависимости от специфики работы документация может включать еще много специфических подразделов и секций. Проводится только смоук-тестирование без создания/обновления или удаления каких-либо данных.
Анализ работы ответственного предоставляется всей команде и подразумевает живое общение. Тестировщики являются равноправными членами процесса. https://deveducation.com/ Это важный пункт командной работы. Тестировщик к девелоперу как максимум может ходить для выяснения настроек энвайронмента.
Именно стандартизированный подход к подготовке тестирования помог обнаружить критическую проблему. В Украине границы между должностями и обязанностями QA, QC и Tester бессовестно размыты. Это вносит дополнительный хаос в и без того сложные процессы разработки. Если повезет, я напишу на эту тему отдельную статью. Гибкие методологии были призваны устранить проблемы каскадной модели, такие как неповоротливость и инерционность.
Автор: Булат Яббаров