Что такое стратегия тестирования
Перейти к содержимому

Что такое стратегия тестирования

  • автор:

Что такое стратегия тестирования

Стратегия тестирования представляет собой описание общего подхода к тестированию и целей тестирования. Различают несколько уровней (компонент, интеграция и система в целом) и видов (функции, производительность, нагрузка, отказоустойчивость) тестирования.

В состав стратегии входят:

  • Технологии и инструменты тестирования.
  • Условия завершения и успешного выполнения тестов. Например, можно решить, что после успешного выполнения 95% тестов можно перейти к приемке продукта. Другим примером условия может служить охват кода. Например, в системах безопасности может требоваться стопроцентный охват кода при тестировании.
  • Особые обстоятельства, влияющие на требования к ресурсам и график тестирования, например:
  • тестирование всех интерфейсов ко внешним системам
  • имитация угрозы безопасности или физического повреждения системы

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

Важнейшие обстоятельства для планирования тестирования:

  • Какая итерация выполняется в данный момент и каковы ее цели?
  • Какой уровень тестирования выполняется в данный момент (тестирование компонентов, интеграции или системы в целом)? Иногда все три уровня выполняются в ходе одной итерации.

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

  • типы тестов (функциональные тесты, тесты под нагрузкой, тесты объема, производительности, удобства работы, распределения и т.д.)
  • критерии оценки результатов (охват кода, охват требований, количество обнаруженных ошибок, средняя продолжительность бесперебойной работы и т.п.)
  • применяемые технологии тестирования (автоматического тестирования и тестирования вручную)

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

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

  • План тестирования должен содержать наборы критериев завершения тестирования для тестирования компонентов, интеграции и системы в целом.
  • Для разных итераций могут быть определены разные наборы критериев завершения.

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

В следующих таблицах показаны различные типы тестов и примеры условий завершения тестирования. В первой таблице показан типичный пример проекта по разработке управленческой информационной системы.

Итерация Тест системы Тест интеграции Тест компонента
Итерация 1 Автоматизированное тестирование производительности всех вариантов использования.
· Выполнены все запланированные тесты.
· Устранены все ошибки серьезности 1.
· Все запланированные тесты выполнены повторно и не обнаружено ни одной ошибки серьезности 1.
Нет Неформальное тестирование
Итерация 2 Автоматизированное тестирование производительности и функций всех новых вариантов использования, а также тестирование старых вариантов использования в качестве регрессионного тестирования.
· Выполнены все запланированные тесты.
· Устранены все ошибки серьезностей 1 и 2.
· Все запланированные тесты выполнены повторно и не обнаружено ни одной ошибки серьезности 1 или 2.
Нет Неформальное тестирование
Итерация 3 Автоматическое тестирование функций и негативное тестирование всех новых вариантов использования, а также всех старых вариантов использования в качестве регрессионного тестирования; 95% тестов должны быть выполнены успешно.
· Выполнены все запланированные тесты.
· Выявлены все ошибки серьезностей 1, 2 и 3.
Автоматизированное тестирование, охват 70% кода. Неформальное тестирование
Итерация 4 Автоматическое тестирование функций и негативное тестирование всех вариантов использования, тестирование вручную всех неавтоматизированных частей, а также проведение всех прежних тестов в качестве регрессионного тестирования. Должно быть успешно проведено 100% тестов.
· Выполнены все запланированные тесты.
· Устранены все ошибки серьезностей 1, 2 и 3.
· Все запланированные тесты выполнены повторно и не обнаружено ни одной ошибки серьезности 1 или 2.
Автоматизированное тестирование, охват 80% кода. Неформальное тестирование

Во второй таблице показаны типы тестов и критерии завершения для типичной системы безопасности.

Итерация Тест системы Тест интеграции Тест компонента
Итерация 1 Автоматизированное тестирование производительности всех вариантов использования; охват 100% тестов.
· Выполнены все запланированные тесты.
· Устранены все ошибки серьезности 1.
· Все запланированные тесты выполнены повторно и не обнаружено ни одной новой ошибки.
Нет Нет
Итерация 2 Автоматизированное тестирование производительности и функций, а также негативное тестирование всех вариантов использования; охват 100% тестов.
· Выполнены все запланированные тесты.
· Устранены все ошибки серьезностей 1 и 2.
· Все запланированные тесты выполнены повторно и не обнаружено ни одной новой ошибки.
Автоматизированное тестирование производительности Неформальное тестирование
Итерация 3 Автоматизированное тестирование производительности и функций, а также негативное тестирование и тестирование документации всех вариантов использования; охват 100% тестов.
· Выполнены все запланированные тесты.
· Устранены все ошибки серьезностей 1, 2 и 3.
· Все запланированные тесты выполнены повторно и не обнаружено ни одной новой ошибки.
Автоматическое тестирование производительности и повтор предыдущих тестов в качестве регрессионного тестирования. Автоматизированное тестирование, охват 70% кода
Итерация 4 Автоматизированное тестирование производительности и функций, а также негативное тестирование и тестирование документации всех вариантов использования; охват 100% тестов.
· Выполнены все запланированные тесты.
· Устранены все ошибки серьезностей 1, 2 и 3.
· Все запланированные тесты выполнены повторно и не обнаружено ни одной ошибки.
Автоматическое тестирование производительности и повтор предыдущих тестов в качестве регрессионного тестирования. Автоматизированное тестирование, охват 80% кода.

© Copyright IBM Corp. 1987, 2006. Все права защищены..

Стратегия тестирования в условиях Scrum: зачем она нужна и как построить

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

Материал будет полезен для представителей всех технических направлений, особенно для лидов и тех, кто пока лишь задумывается о том, как построить процесс тестирования в продуктовой компании.

Мы живем в такое время, когда об автоматизации как инструменте упоминается настолько часто, что все остальные темы кажутся недосказанными. Очень много говорится о технологиях и новшествах, но очень мало о том, как их применять, грамотно решая возникающие проблемы.

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

Cтатья основана на моём докладе на online-конференции QA fwdays’20.

Стратегия тестирования: что это и чем она отличается от тест-плана

О тест-плане слышали все, многие даже писали его. Документ отвечает на основные вопросы: что, кто, когда и как тестирует? Он хорош и достаточно практичен, но только для проектов, имеющих конкретные объемы разработки, поскольку количество реализуемого функционала остается более или менее понятным до окончания построения финальной системы.

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

Тестовая стратегия как раз и описывает план подхода к тестированию в цикле разработки ПО. (Медленно и вдумчиво перечитайте предыдущее предложение). Разработка по гибкой методологии Scrum циклична. На основе этого принципа и будет строиться наша стратегия. Если провести аналогии с реальной жизнью, то тест-план — это подробная карта маршрута через территорию, а тестовая стратегия — компас, указывающий направление.

С терминами разобрались. Осталось понять, в чем беда скрама.

Waterfall никто не отменял, или Как мы докатились до Scrum

Все знают: вначале был Waterfall. Громоздкий, неповоротливый, длинный. С кучей документации и огромной инерционностью. И вот на смену ему пришел Scrum — легкий, гибкий и простой — в паре с Agile-манифестом, обещавшим разработке и бизнесу стратегию win-win. Берем спринты, нарезаем фичи и реализуем их за короткий промежуток времени. Потом следуют демо, ретро — и все по новой. На первый взгляд, гениально и просто. Но давайте остановимся на минутку и подумаем.

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

Разберемся в предпосылках появления нового подхода в создании ПО. Agile был сформулирован людьми, которые занимались в основном коммерческой разработкой для компаний, выходящих на рынок, и предлагали свои решения широкому кругу пользователей.

Гибкие методологии были призваны устранить проблемы каскадной модели, такие как неповоротливость и инерционность. Была цель ускорить предоставление готовой продукции конечному потребителю.

Однако задача отказаться от документации и сохранения знаний не стояла. Именно с этой проблемой сталкиваются сейчас в большинстве случаев практически все молодые проекты, использующие гибкие подходы к разработке. Через полгода после запуска там уже черт ногу сломит в логике бизнеса и технической части. А если вдобавок сменится поколение инженеров, то у продукта возникнут дополнительные проблемы, которые новой команде невозможно предвидеть из-за образовавшегося информационного вакуума.

Теперь главный вопрос: как отдел тестирования помогает решать эти проблемы с помощью тестовой стратегии?

Рассмотрим лепестковую диаграмму, которая наглядно иллюстрирует, как наша команда чередует основные активности. Эту диаграмму я называю «шестеренкой тестирования»:

На окружности изображены шесть двухнедельных спринтов (приблизительно 3 месяца), каждый из которых условно разбит на 3 сектора: начало (1S — 1MS), середину (1MS — 1ME) и конец (1ME — 1E). Обозначены также уровни QA, QC, Testing и переходы между ними в разных временных рамках.

Из диаграммы следует, что основные задачи лежат в плоскости тестирования и контроля качества. И только один раз за все время отдел взлетает на уровень обеспечения качества, с вершины анализирует пройденный путь и пытается заглянуть за горизонт событий, в будущее.

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

У большинства команд бывают критические периоды, когда проблемы начинают сыпаться со всех сторон: баги пролазят на прод, тестовые окружения перестают быть стабильными и консистентными, количество flaky-тестов растет, спринты не закрываются. И ты вроде делаешь все, что надо, но результата не видно. В таком случае приходится принимать решение, как быть дальше: поменять компанию или проявить характер и вырваться из порочного круга. Мы остановились на последнем варианте. Наша команда на тот момент состояла из 11 человек: 2 Node.js разработчика, 1 Front-end, 5 PHP Back-end и 3 тестировщика.

Рассмотрим подробно, что именно мы делали для повышения вероятности успешного закрытия спринта и решения проблем.

Начало спринта

Типичная ситуация: после планирования разработчики перегружены задачами, а у тестировщиков, наоборот, дефицит работы. Самое время заложить фундамент качественного и эффективного тестирования на весь спринт. Вариантов несколько.

Пойти в разведку

Выбрать средние и большие задачи. Нацелиться на их анализ и тестирование требований. Что это значит? Для начала основательно вчитаться в описание. Сформировать личные тезисы и мнение по тикету. После этого пойти к разработчикам, которые реализуют задачи, (или написать им) и получить от них ответы на следующие вопросы:

1. Что будет реализовано в тикете?

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

Пример: «Добавить на главную страницу новый баннер с недорогим платежным планом за $X,XX» — изначально поставленная задача. Но с момента ее создания изменилось видение, и Product Owner написал разработчику — в обход таск-трекера и всей команды, — что баннер нужно отображать только для Украины. Для девелопера это мелочь, всего одна строка в конфиге, а для остальной команды — неочевидные требования.

2. Зачем это делается? Какова бизнес-цель?

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

3. Что будет задето этой задачей?

На первый взгляд, простой вопрос. Но ответ на него иногда вскрывает настолько неочевидные связи, что задавать его стоит в протокольном порядке. У нас был случай, когда при добавлении нового типа подписки переставала приходить рассылка, будучи соотнесенной с другими платежными планами. А в случае с баннером (см. пункт 1) была нарушена логика трекинга поведения пользователя.

Именно стандартизированный подход к подготовке тестирования помог обнаружить критическую проблему.

4. С какими сложностями есть вероятность столкнуться при тестировании и эмуляции?

Разработчик проанализирует сотни строк кода, прежде чем написать свои. А если он хороший инженер, то задумается еще и над тем, чтобы его творение было пригодно для тестирования. Задав подобный вопрос, вы сможете избавить себя от часов бессмысленных исследований.

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

5. Согласовать критерий качества приемки задачи

Один из удивительных законов Мерфи применительно к разработке ПО формулируется так: «Все, что может быть понято двояко, будет понято двояко». Именно поэтому у нас инженеры проговаривают основные пункты приемки фичи, чтобы исключить возможные разночтения. Очень важно, чтобы сотрудники находились в одном контексте и имели единую систему координат и точку отсчета при работе над задачей.

6. Есть ли у разработчика пожелания и советы по тестированию задачи?

Провокационный вопрос, призванный поднять в памяти коллеги весь проговоренный материал, чтобы случайно ничего не упустить.

7. Подготовить альфа-версию чек-листа.

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

8. Проверить описание задачи в Jira и исправить или дополнить на основе полученной информации в вышеперечисленных пунктах

Задачи в таск-трекерах сделали людям огромное одолжение, освободив их от бумажной работы. Запомните: таск в Jira — это документ, значит, он должен быть полным и оформлен согласно стандартам. Никогда не пропускайте этот пункт и обновляйте описание тикетов, как только получаете новую информацию.

Закрыть долги

Если удастся полностью выполнить предыдущий пункт и еще остается свободное время, то мы переключаемся на документальные и организационные задачи.

1. Кейсы, не записанные в TestLink или другой тест-трекер

Всегда найдется сьют, который следовало бы проапдейтить, или функционал, для которого не созданы тест-кейсы.

2. Несозданные тикеты на автотесты

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

3. Пропущенные статьи в Wiki

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

4. R&D

Новые инструменты появляются постоянно, и сообщество предлагает большой выбор методов и подходов к работе. Где, как не в боевом окружении, их тестировать?

Середина спринта (тикеты непосредственно берутся в тестирование)

Рабочие дни идут, и вот таски планомерно заполняют столбик «Тестирование». Следующие действия качественно влияют на процесс, поэтому я настоятельно рекомендую именно такой порядок активностей.

Перед началом любых действий по задаче, которая требует тестирования, нужно перечитать описание и повторно переговорить с разработчиком (кратко). Цель — уточнить, одинаково ли все участники понимают задачу, а также убедиться, что ничего не изменилось, не встретились «подводные камни», которые внесли поправки.

Затем следует провести тест-дизайн, углубив анализ задачи на основе альфа-версии чек-листа, написанного ранее.

Бросаться на задачу с шашкой наголо и кромсать ее исследовательским тестированием — это похвально, но только после детальной проработки общего плана работ. Основные его пункты:

  • разбить объект на модули и логические составляющие;
  • обозначить связи с другими модулями системы;
  • выделить smoke-набор для TestLink/Wiki.

Только получив сформированный обозримый объем для тестирования, можно приступать к работе. Если есть сомнения, попросите коллег по цеху сделать ревью чек-листа.

Любая деятельность ценна тем, что она что-то производит. Продукт тестирования => обратная связь по тикету. И чем быстрее она возвращается к разработчику, тем лучше. Но не стоит жертвовать полнотой информации, необходимо соблюдать баланс.

На техниках и подходах к ручному тестированию я останавливаться не буду. Надеюсь, все читатели прекрасно ими владеют.

Заведение отчетов об ошибках

Хочу обозначить два полезных момента:

  1. Пред заведением бага стоит проверить его наличие в трекере, чтобы не плодить дублей.
  2. После оформления саба надо сообщить разработчику. Не стоит рассчитывать, что он читает почту или правильно настроил нотификации.

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

По завершении тестирования тикета остается выделить кейсы для автотестов, оформить кейсы в TestLink и завести статью в Wiki.

Конец спринта

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

Назначенный человек оценивает работу в спринте по следующим пунктам:

  1. С какими проблемами столкнулись, как их решали?
  2. Что нового узнали о работе системы? Нужно ли это документировать?
  3. Какие новые фичи зарелизены? Нужно ли закрывать их автотестами?
  4. Формирование задач для отдела тестирования на основе предыдущих пунктов.

Активности над спринтами

В описанном выше режиме проходит неделя (спринт, месяц — подставим сюда любой временной отрезок). Гладкая и выверенная схема начинает сбоить. И это нормально, ибо нет ничего вечного. Самое время примерить роль QA в широком смысле этого слова.

На следующем планировании один человек из отдела тестирования берет на себя задачу под названием «Пересмотр тестовой стратегии».

Таск включает следующие разделы:

1. Анализ проделанной работы за квартал/полгода

Просматриваются задачи, анализируются их характер, специфика и направление. Какие фичи релизились, какие заморозились, какие проблемы были наиболее распространены? Что автоматизировано, какую документацию создавали, какая не пригодилась? Также уточняется вектор будущего развития продукта, возможно, перечень технологий, которые планируется внедрить. Основные цели:

  1. Увидеть целостную картину работы команды и обозначить роль тестирования в ней.
  2. Быть готовым к преобразованию проектов и команды, а также к другим изменениям.
2. А не глупости ли мы делаем?

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

3. Сбор метрик по команде и проблемам

В этом пункте источником информации выступает таск-трекер. Собираем численные показатели:

  1. Баги от пользователей, относящиеся к нашей команде.
  2. Баги от пользователей, относящиеся ко всей компании.
  3. Баги, найденные тестировщиками нашей команды.
  4. Задачи, назначенные на отдел тестирования.
  5. Задачи, выполненные отделом тестирования.
4. Укрепление положительных активностей

Этот пункт призван укоренить действия, которые нетипичны для специалистов нашей области, но оказались нам по силам и принесли ощутимый результат.

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

Вторая такая активность — создание расширения для Google Chrome, которое в пару кликов приводит тестового пользователя в состояние готовности к тестированию.

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

5. Анализ сохраненных знаний, систематизация

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

6. Чего не хватает отделу тестирования в целом?

Этот пункт требует анализа грубых ошибок, допущенных сотрудниками. Зачастую они связаны с незнанием предметной области или неумением пользоваться выделенными инструментами.

Пример. Depositphotos использует много платежных систем для удобства пользователей по всему миру. Естественно, для Бразилии нужны одни провайдеры платежей, а для Канады — совсем другие. Налоги, которые платят пользователи в той или иной стране, записываются в отдельный налоговый сервис, а уже по нему компания предоставляет отчеты в соответствующие органы.

Так вот, при добавлении нового провайдера в Канаду после введения специального налога в провинции Квебек транзакции перестали попадать в сервис. Итог — приличный штраф для компании.

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

7. Пересмотр тестовой стратегии

На основе полученных данных необходимо внести коррективы в изначальный процесс тестирования.

8. Проверка знаний команды, выделение личных векторов развития

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

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

Что решает такой подход?

  1. Теряется минимум знаний о работе системы.
  2. Формализуются процессы и подходы. Снижается шанс любого сотрудника допустить ошибку.
  3. Понижается порог входа для нового сотрудника.
  4. Уменьшается bus-фактор.

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

Баги: тестировщики против пользователей

Каждый баг находит пользователь (показатель >10 — хороший). Количество оформленных багов показывает тенденцию к уменьшению, а количество проблем пользователей стабильно. На основе этого можно предположить, что кастомеры находят проблемы спустя длительное время после релиза фичи. Уменьшение количества найденных багов говорит о том, что больше проблем выявляется на этапе анализа требований и более плотного взаимодействия разработки с тестированием. Ну, или это признак ухудшения работы команды тестирования.

Задачи, выполненные инженерами тестирования и назначенные на отдел

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

Все проблемы пользователей и баги, пропущенные в области ответственности команды

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

Выводы

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

Хочу дать несколько небольших советов тем, кто решит делать что-то подобное в своей команде.

Будьте последовательными

Каждую активность проверяйте, анализируйте и аргументируйте. Не нужно бездумно копировать сторонние подходы. Вы не знаете и никогда не узнаете всех нюансов, которые привели другие команды к их результатам.

Будьте системными

Системный подход — это отличная страховка в очень переменчивом мире. И когда совсем непонятно, что делать, следование изначальному плану помогает сориентироваться и выработать необходимое решение.

Будьте профессиональными

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

Это все, о чем я хотел рассказать. Спасибо, что прочитали! Если появятся вопросы, я с удовольствием отвечу на них в комментариях.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

�� Подобається Сподобалось 11

До обраного В обраному 15

Home

Автор: Вячеслав Панкратов

Руководителям групп тестирования и ведущим тестировщикам часто приходится разрабатывать кроме необходимой рабочей документации и артефактов, документы более высокого уровня, описывающие общие подходы к тестированию системы и развитие процесса тестирования в проекте. Об одном из таких документов-артефактов и пойдёт речь ниже.

Многие из нас сталкивались с разработкой стратегии тестирования, особенно часто подобные артефакты интересуют заказчиков крупных проектов, срок разработки которых превышает год. Попробуем внести ясность в понятие Стратегии Тестирования и ответить на ряд вопросов разобрав несколько примеров на практике.

Терминология

СТРАТЕГИЯ — искусство руководства; общий план ведения этой работы, исходя из сложившейся действительности на данном этапе развития.

Есть другой вариант, с военным уклоном:

Наука о ведении войны, искусство ведения войны. Общий план ведения войны, боевых операций.

Я привожу оба определения, хотя первое достаточно точно описывает с чём, собственно, мы имеем дело. И хотя наши будни можно рассматривать как ведение войны за качество продукта, как мы увидим ниже ничего «военного» в стратегии тестирования как раз и нет.

Определение

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

Получается немного страшновато? Попробуем разбить на более детальные части используя, к примеру, разбивку по вопросам, на которые отвечает стратегия тестирования.

Стратегия отвечает на вопросы:

  • Как, каким образом тестирование даст ответ, что данный функционал работает?
  • Что нужно сделать и чем пользоваться из инструментальных средств, для достижения целей тестирования?
  • Когда определённый функционал будет тестироваться и соответственно когда ожидать получения результатов?

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

Как видим, Стратегия тестирования, как артефакт, органично вписывается в План Тестирования. Шаблоны планов тестирования, предлагаемые различными методологиями, зачастую прямо включают одним из разделов описание стратегии тестировании или же включают описание стратегии в пункты плана отвечающие за тестирование конкретных частей функционала. К примеру, шаблон Rational Unified Process определяет стратегию тестирования как самый большой раздел плана тестирования.

Что идеологически более правильно: выделять стратегию для всего проекта, или разрабатывать конкретные подходы для каждой области тестирования, зависит от конкретного проекта. В современных распределённых системах, с несколькими типами рабочих мест и системными агентами, которые также выступают пользователями системы, логичнее выделять стратегию для каждого набора тестируемого функционала: модуля или подсистемы. Для более простых приложений можно предлагать тестирование всего приложение в рамках одной Стратегии.

Заказчик, зачастую, хочет контролировать процесс тестирования и видеть понимание задачи тестирования исполнителями по проекту. Для него стратегия тестирования это менее детальный документ-видение (vision) того, как будет тестироваться система в процессе разработки.

Практика

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

Разбираемые ниже примеры используют упрощённую модель приложений в разрезе взаимодействия компонентов приложения и системы, а также внутренней логики самого приложения.

В качестве простого десктоп-приложения возьмём, к примеру, новый инженерный калькулятор.

Инженерный калькулятор

Весь набор функций этого приложения можно разделить на две логические группы: логика инженерных операций и взаимодействие с операционной системой (выделение и освобождение ресурсов, использование системных компонент, взаимодействие с буфером обмена системы и т.п.).

Из требований к приложению выделим поддержку 5-ти операционных систем с 4 основными языками локализации и выполнение, скажем, 50 инженерных функций, каждая из которых однозначно покрывается одним тестом. Тесты, безусловно, включают проверку на контрольных примерах, проверку на граничные значения и т.п. Кроме того, приложение позволяет выполнять, к примеру, 5 функций по взаимодействию с системой (запуск приложения, выход из приложения, сохранение результатов в файл, работа с буфером и т.п.).

Полное покрытие требований задаёт набор из 5*4*(50+5)=1100 тестовых прогонов. Так как нужно выполнить все доступные операции приложения под всеми поддерживаемыми операционными системами и языковыми локализациями.

Пример, как вы понимаете, подобран не случайно. Попробуем наглядно показать стратегию тестирования в действии.

Вернёмся к разбивке функциональности приложения по логическим группам. Есть набор инженерной функциональности и есть системное взаимодействие.

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

Таким образом, гарантировать работоспособность инженерных операций калькулятора можно прогоном 50 тестов под одним окружением.

Взаимодействие с системой, запуск, остановку приложения, работу с буфером, запись результатов в файл, в нашем примере обеспечивает 5 тестов. Имеем 5 версий операционной системы и 4 локализации, что даёт 20 комбинаций и 20*5=100 тестовых прогонов.

Таким образом, для данного примера, полный охват функциональности определяется 50+100=150 тестовых прогонов, из которых 50 тестов инженерных функций выполняются под одной конфигурацией и 5 тестов системных функций под 20 тестовыми окружениями.

Стратегия тестирования в действии

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

Полное покрытие требований определяет 1100 тестовых прогонов. Разбор функциональности и определение необходимого набора тестирования даёт на выходе из разработки стратегии тестирования 150 тестовых прогонов.

Для данного конкретного примера, разработка стратегии тестирования даёт прямой выигрыш в затратах на тестирование в 1100/150=7,(3) раза. Как видим, имеет смысл. Попробуем рассмотреть шаги разработки стратегии тестирования для более сложного приложения — распределённой клиент-сервер системы.

Распределённая система

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

Вернёмся к стратегии тестирования сложной распределённой системы. Проведём ориентировочную разбивку функциональности на тестовые области, с тем, чтобы понять как спланировать тестирование и минимизировать затраты.

Пусть система имеет «толстого» клиента, сервер приложения и сервер базы данных, которые могут функционировать на разных физических платформах. Основная логика ввода/вывода, валидации значений и построения печатных форм сосредоточена на клиенте, сервер приложений обеспечивает презентационный уровень и необходимую сервисную логику (автоматическая архивация данных, оповещение пользователей о внештатных ситуациях и т.д.), а база данных обеспечивает кроме непосредственного хранения данных определённую часть обработки данных реализуемую, к примеру, в виде пакетов функций. Ничего особенно сложного выбрано не было и пусть описание не пугает определённой утрированностью — мы всего лишь обрисовали задачу для тестирования.

Для того, чтобы чрезмерно не усложнять задачу, сузим область тестовых окружений за счёт фиксированных конфигураций для сервера БД (зачастую в промышленной эксплуатации используется выделенный сервер или кластерное решение для работы баз данных) и сервера приложений. Клиентское приложение обеспечивает работу под 2-мя операционными системами и жестко фиксированной конфигурацией компонентов ОС (к примеру, на все пользовательские машины регулярно устанавливаются все обновления и service packs + набор ПО на клиентских машинах строго регламентирован внутренней IT политикой).

Объём задач

Попробуем описать задачу на языке тестовых сценариев, то есть будем применять для оценки трудоёмкости задачи или её части количество тестов, необходимых для проверки работоспособности функционала.

Клиент: 50 тестов на работу с данными (ввод форм, расчёт данных на основе данных хранимых в словарях, поиск данных, редактирование словарей и т.п.), 10 тестов на работу с печатными формами (формирование периодов выборок, выбор типов отчётов, печать или экспорт в предопределенный список форматов и т.д.). Пусть для тестирования работы с системой требуется, как и в предыдущем случае, ещё 5 тестов. По аналогии с предыдущим примером можем получить следующую картинку: имея 2 окружения получаем (5+10)*2=30 тестовых прогонов для проверки функциональности связанной с самой операционной системой (включая функционал печати и экспорта во время которого создаются новые файлы в рамках файловой системы). Будем считать, что 50 тестовых прогонов реализующих проверку логики работы с данными, можно выполнять под одним окружением. Итог — 80 тестовых прогонов для тестирования клиента системы.

Объединим в рамках рассматриваемого примера тестирование функциональности сервера приложений и базы данных. Пусть сервер приложения реализует 20 команд по обработке данных и пользовательских сессий (без учёта работы с системными пулами соединений, функций сжатия передаваемого по сети трафика и т.п.). Сервер баз данных реализует 10 системных операций по архивации данных, построению статистики использования отчётов и ещё несколько подобных операций. Общий смысл заключается в том, что мы имеем конечный набор тестируемых операций, и так как конфигурации определены заранее, можем говорить о конечном наборе тестов, которые необходимо выполнить, что бы проверить работоспособность серверного функционала системы. Итог — 30 тестов на серверной стороне. Заметим, что в данном примере мы не затрагиваем нагрузочную составляющую тестирования: речь идёт только о функциональном тестировании.

Зависимости от артефактов проекта

Более интересным с точки зрение разработки стратегии тестирования в данном примере, будет фактор развития системы в целом: создание новых модулей в клиентском приложении или ввод в систему новых серверных агентов.

Что следует учитывать разрабатывая стратегию тестирования для сложных распределённых или клиент-серверных систем. Одним из основных факторов, влияющих на стратегию тестирования (после выделения тестовых областей и понимания тестовых задач в каждой из областей), является анализ план-графика появления новой функциональности в системе, а зачастую и плана разработки дизайнов и спецификаций к модулям и компонентам системы (от этого зависит выполнение задачи дизайна тестов). Чёткий план проекта, разбитый по задачам планирования, проектирования, дизайна и имплементации даёт менеджеру тестирования фундамент, необходимый для решения задачи, которую ставит вопрос «когда», то есть вопрос связанный с планированием тестирования. Хотя временные оценки и оценка трудоёмкости задачи логически выходят за рамки определения стратегии и относятся к непосредственному планированию тестирования, именно понимание приложения/системы в разрезе его развития с течением проекта, является стратегической составляющей плана тестирования.

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

Выводы

Что в общем случае даёт разработка стратегии тестирования? Разбор задачи тестирования на составляющие, выделение тестовых областей и в конечном итоге более полное понимание задачи тестирования в конкретном проекте. Как мы видели на примере тестирования инженерного калькулятора, понимание задачи позволяет разделять функциональность тестируемого приложения или системы на области, которые могут тестироваться автономно, что позволяет снизить (и порой достаточно существенно!) затраты на тестирование.

Вёрнёмся к определению понятия Стратегия: «общий план ведения работы, исходя из сложившейся действительности на данном этапе развития» — применимо к тестированию, стратегия есть понимание «что», «где» (на каком окружении) и «когда» будет тестироваться. Ответ на вопрос «как» нам может дать анализ требований к системе и дизайн тестов. Согласитесь, имея перед собой план развития системы и функционала, можно достаточно уверенно планировать задачи по тестированию, готовить необходимые данные и тестовые окружения. В любой момент времени, руководитель, полагаясь на стратегию, знает где он находится и куда двигается дальше. Планируя тестирование, руководитель отдела или ведущий тестировщик не начинает разбираться с системой, а занимается непосредственно планированием, выделением ресурсов и сроков на конкретные задачи.

Тестовая документация

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Хороший тест план должен описывать следующее:

  1. Что надо тестировать? Описание объекта тестирования: системы, приложения, оборудования.
  2. Что будете тестировать? Список функций и описание тестируемой системы и её компонент в отдельности.
  3. Как будете тестировать? Стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования.
  4. Когда будете тестировать? Последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки.

Критерии начала тестирования:

  • готовность тестовой платформы (тестового стенда);
  • законченность разработки требуемого функционала;
  • наличие всей необходимой документации.

Критерии окончания тестирования — результаты тестирования удовлетворяют критериям качества продукта:

  • требования к количеству открытых багов выполнены;
  • выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF);
  • выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB).

Преимущества тест плана:

  1. Возможность приоритезации задач по тестированию.
  2. Построение стратегии тестирования, согласованной со всей командой.
  3. Возможность вести учет всех требуемых ресурсов (как технических, так и человеческих).
  4. Планирование использования ресурсов на тестирование.
  5. Просчет рисков, возможных при проведении тестирования.

Составляющей частью планирования тестирования (как отдельного документа или же процесса планирования в целом) является стратегия тестирования. Стратегия может быть:

  1. Частью общего тест-плана.
  2. Отдельным документом.

Тестовая стратегия определяет то, как мы тестируем продукт. Это набор мыслей и идей, которые направляют процесс тестирования.

В стратегии тестирования описывают:

  1. Тестовую среду.
  2. Анализ рисков проекта.
  3. Инструменты, которые будут использовать, чтобы провести автоматизированное тестирование и для других целей.
  4. План действий при непредвиденных обстоятельствах.

Стратегия может быть представлена как в виде традиционно расписанного документа, так и в более наглядном формате, например, используя таблицу:

В общем, план тестирования устанавливает цели процесса тестирования, он определяет, что будет проверяться, а стратегия тестирования описывает, как достичь целей, поставленных в плане тестирования.

Пользовательские истории

Пользовательские истории (User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований.

User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.

Примеры:

  • Залогиниться в мой портал мониторинга энергопотребления.
  • Посмотреть ежедневный уровень потребления.
  • Проверить мой текущий тариф.

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

  • Они не являются детальным описанием требований (то-есть того, что система должна бы делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого).
  • Они являются короткими и легко читаемыми, понятными разработчикам, стейкхолдерам и пользователям.
  • Они представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках нескольких дней или недель.
  • Они относительно легко поддаются эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены.
  • Они не занимают огромных, громоздких документов, а скорее организованы в списки, которые легче упорядочить и переупорядочить по ходу поступления новой информации.
  • Они не детализированы в самом начале проекта, а уже более детально разрабатываются «точно в срок», избегая таким образом слишком ранней определенности, задержек в разработке, нагромождения требований и чрезмерно ограниченной формулировки решения.
  • Они требуют минимум или вовсе не требуют сопровождения и могут быть безопасно отменены после имплементации.

Структура юзер стори

Текст самой юзер стори должен объяснять роль/действия юзера в системе, его потребность и профит, который юзер получит после того как история случится.

Правила на написание User Story

  1. Есть один actor.
  2. Есть одно действие.
  3. Есть одна ценность / value / impact.

Actor

Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла — значит эта часть бесполезна.

Джеф Паттон предлагает следующее:

  1. Разделите всех актеров на группы. Целевая группа, важная группа, менее важная группа и тп.
  2. Дайте уникальные названия актерам в этих группах. Даже если в системе у них будет одинаковые роли «Пользователя системы».
  3. Пишите истории с точки зрения этих актеров указывая их уникальные названия.
  4. В результате вы сможете визуально увидеть какие истории необходимы для актеров целевой группы, какие — для каждой группы и тп. Вы не просто можете использовать это при разборе истории и выстраивания анализа вокруг указанного актера. Вы сможете более правильно выстроить приоритет, так как истории актеров целевой группы для нас более важны.

Действие

Это суть истории, «что нужно сделать». Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать» авторизуется и выполняется поиск» или «указывает параметры поиска и выполняет поиск». Укажите то действие, что вам действительно нужно.

Важно описывать историю на уровне «ЧТО?» делает, а не «КАК?». Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное «КАК» — решение.

Ценность

Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите «чтобы . «.

Уберите эту часть из истории. Если ничего не потеряли — значит формализация ценности в истории была бесполезна. Что же можно сделать?

Отказаться от формулировки «чтобы». Для каких-то историй можно указать ценность истории в таком формате, но не для большинства.

Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.

Представим что вы создали историю — «Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение».

У меня Аcceptance Сriteria — это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена?

Переделаем историю на влияние — «Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ». То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.

Практические советы по написанию пользовательских историй

  • Лучше написать много историй поменьше, чем несколько громоздких.
  • Каждая история в идеале должна быть написана избегая технического жаргона — чтобы клиент мог приоритезировать истории и включать их в итерации.
  • Истории должны быть написаны таким образом, чтобы их можно было протестировать
  • Тесты должны быть написаны до кода.
  • Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
  • Каждая история должна содержать оценку.
  • История должна иметь концовку — т.е. приводить к конкретному результату.
  • История должна вмещаться в итерацию.

Пример юзер стори:продолжение:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *