Что такое scrum тест
Автоматизация тестирования по методологии Scrum
Все больше и больше набирает обороты использование методологий семейства Agile, так называемых гибких методологий, в сфере IT. К этому семейству, как вы знаете, относятся такие методологии, как Kanban, XP, Scrum и прочие, менее известные методологии.
Напомню в чем смысл каждой из них по версии ISTQB:
Отличительными особенностями Kanban являются:
Отличительными особенностями Scrum являются:
А как построен Scrum у нас?
Команда состоит из PO (Product owner), Scrum Master и Developing Team, которая в свою очередь состоит из 1 QA Automation, 1 Backend developer, 1 Frontend developer, 1 UX и 1 верстальщика. Разработка идет итерационно, спринтами по 2 недели. Во время каждого спринта проводится несколько типов встреч:
Как пример для автоматизатора — внедрение Allure отчетов, для девелопера — оптимизация работы запросов.
Тестирование в Scrum
В начале процесса автоматизации тестирования необходимо настроить CI, чтобы проводить регрессионное тестирования автоматически. Цель — свести ручную работу к минимуму. Потому что времени ни на что нет, нужно работать быстро. После этого стоит заняться репозиторием, настроить запуск сборки по Merge request. Если кто-то из разработчиков отправил что то в основную ветку проекта, запускается сборка и по ее результатам можно понять корректны ли внесенные изменения.
Перед тем как приступить к написанию тестов, необходимо разобраться в основной бизнес-идее проекта, чтобы определить области высокого риска на которые обращается внимание в первую очередь. Все таки будем реалистами, полностью покрыть тестами приложение, пусть оно и маленькое, не получится. Сазерленд писал, что на реализацию всего Бэклога никогда нет времени, поэтому он всегда применял к Backlog принцип Парето. Пишем 20% автотестов, покрывающих 80% возможных дефектов.
При написании тестов нужно добиваться максимальной абстракции. Не стоит писать код функции, которую можно будет использовать только при определенных условиях. Намного лучше реализовать ее так, чтобы максимально переиспользовать код, изменяя входные параметры.
Эффективная работа в Scrum невозможна без тесной работы с разработчиком, потому что времени для самостоятельного изучения кода мало. Быстрее и качественнее получится результат, если получать информацию из первых уст. Как реализован тот или иной функционал, что при этом использовалось. Это важно для понимания внутренней структуры.
Необходимые качества автоматизатора тестирования
Автоматизатор, а в Scrum особенно, должен быть технически подкован, чтобы понимать как работает приложение так сказать “под капотом”. Важно уметь быстро и легко переходить с одной технологии на другую. Например, при изменении базы данных, нужно быть готовым изменить способ подключения к ней. Стек технологий должен быть как можно шире.
Scrum предполагает быструю реакцию на изменения, срочное внесение исправлений. Предположим, что пользователи обнаружили некое несоответствие в работе приложения, команда разработки должна как можно быстрее отреагировать и выпустить патч. Для этого важно уметь очень точно локализовать проблему. В этом очень хорошо помогает автотестирование. Допустим у нас есть трехуровневое web-приложение: есть DB, frontend, backend. Где то в приложении есть баг. При использовании ручного тестирования поиск проблемы может занять не один день, затем проблему нужно будет исправить и вновь протестировать. При автотестировании мы запускаем регрессоное тестирование и в течение пары часов получаем полный отчет, в котором отражено точное местоположение бага.
Scrum-тестирование
Что такое Scrum?
Создание сложных программных приложений является сложной задачей. Методология Scrum является решением для выполнения такой сложной задачи. Это помогает команде разработчиков сосредоточиться на всех аспектах продукта, таких как качество, производительность, удобство использования и так далее.
Что такое Scrum-тестирование?
SCRUM TESTING — это тестирование, выполненное по методологии Scrum, для проверки соответствия программного приложения требованиям. Scrum-тестирование также включает в себя проверку нефункциональных параметров, таких как безопасность, удобство использования, производительность и т. Д. Активная роль Tester в процессе Scrum отсутствует. Обычно тестирование проводится разработчиком с помощью Unit Test. Некоторые проекты Scrum имеют специальные группы тестирования в зависимости от характера и сложности проекта.
В этом уроке вы узнаете
Ключевые особенности методологии Scrum
Ниже приведены ключевые особенности Scrum-
Скрам основан на следующих 3 Столпах-
Давайте посмотрим на один за другим
1. Роли в Scrum
В Scrum Testing есть три главные роли: владелец продукта, Scrum Master и команда разработчиков. Давайте изучим их подробно
2. Скрам Артефакты
Скрам-процесс включает в себя
3. Церемонии (процессы) в Scrum
Роль тестера в схватке
Следующий вопрос: что тестер делает в схватке? Следующее примечание ответит
Тестирование деятельности в Scrum
Тестеры выполняют следующие действия на различных этапах Scrum-
Спринт Планирование
спринт
Спринт Ретроспектива
Отчет об испытаниях
Отчет по метрикам Scrum Test обеспечивает прозрачность и прозрачность для заинтересованных сторон о проекте. Метрики, о которых сообщают, позволяют команде анализировать их прогресс и планировать свою будущую стратегию, чтобы улучшить продукт. Есть две метрики, которые часто используются для отчета.
Диаграмма сгорания: каждый день Scrum Master записывает примерную оставшуюся работу для спринта. Это не что иное, как таблица сгорания. Обновляется ежедневно.
Диаграмма выживаемости дает быстрый обзор хода выполнения проекта, эта диаграмма содержит информацию, такую как общий объем работы в проекте, который должен быть выполнен, объем работ, выполненных во время каждого спринта, и так далее.
График истории скоростей: График истории скоростей предсказывает скорость команды, достигнутую в каждом спринте. Это гистограмма, показывающая, как результат работы команды менялся с течением времени.
Дополнительные метрики, которые могут быть полезны, — это сокращение графика, сокращение бюджета, процент выполнения темы, завершенные истории — оставшиеся истории и так далее.
Есть ли у вас какие-либо советы или опыт для Scrum-тестирования? Оставьте комментарий ниже
Тестирование в рамках SCRUM. Тернии, грабли и успехи
SCRUM — фреймворк управления проектами, в который наша команда попробовала внедрить этап тестирования. В этой статье мы хотим помочь не совершить наших ошибок тем командам, которые только начинают знакомиться со SCRUM. Участники же опытных SCRUM-команд приглашаются в комментарии, чтобы поделиться замечаниями и успехами. А в качестве иллюстраций — беговые дорожки, марафонцы, препятствия. Они тут неспроста. Да и Олимпиада же, в конце концов.
Начнём с перечисления ключевых особенностей SCRUM для тех, кто с ним не знаком:
Проблемы
Приоритетный вектор компании — разработка мобильных приложений. Это часто создаёт специфические рабочие условия: сроки бывают сжатыми, нормальной документации (как это бывает в случае со стартапами) нет, а требования заказчика меняются часто и резко. Из-за этого в организации тестирования возникает ряд сложностей, основная из которых — время. Если сравнивать большой энтерпрайз-проект и мобильный стартап, то в первом случае к проекту предъявляется море требований, но работать проще — зачастую есть и утверждённая документация, и сроки не такие сжатые. В мобильной разработке проекты не всегда настолько же масштабны, но из-за специфики тестирования мобильных платформ, особых требований к приложениям и частого отсутствия технической документации фронт работ получается сопоставимым, а времени на тестирование выделяется меньше.
Отсюда вытекают следующие проблемы тестирования мобильных приложений:
Опыт внедрения
Основной проблемой реализации тестирования в SCRUM была сложившаяся на тот момент практика тестирования. Она предполагала продолжительные этапы разработки, затем передачу сборки на тесты, приём баг-репортов, правки, опять тестирование, снова правки, и так до тех пор, пока заявленные на этом этапе функции не начинали работать правильно. Смысл же SCRUM — в относительно коротких спринтах, по окончанию которых у вас есть некоторый оформленный и рабочий инкремент продукта. В итоге у нас сложилось две схемы.
Схема 1. Назовем её «Однократное тестирование + проверка фиксов».
Плюсы данного подхода:
Минусы данного подхода:
Порой заказчик сам любил тестировать продукт, а у команды не было жёсткого списка тех задач, которые должны быть выполнены в данный спринт, кроме списка задач на этап. Это оборачивалось следующим:
Итог работы по схеме: получился качественный продукт, но производственный процесс нельзя было полностью назвать SCRUM’ом. Заказчик был часто недоволен тем, что сам находил баги, хотя итоговый результат его вполне устроил.
Дышим ровно, бежим дальше.
Схема 2. Её назовём «Потоковое тестирование».
Плюсы данного подхода:
Минусы данного подхода:
Итог работы по схеме: значительно лучше первой схемы, но не без недостатков. Чтобы сгладить их, мы выделили для себя некоторые дополнительные правила.
Cейчас у вас откроется второе дыхание — мы выходим на финишную прямую.
Работа над ошибками
Эти приёмы в ведении проектов по SCRUM-методологии мы вывели для себя в процессе работы и продолжаем их оттачивать. Надеемся, что они будут полезны и вам:
Решаемые проблемы
В первую очередь SCRUM сглаживает проблему отсутствующей документации и налаживает общение в команде: задачи ставятся постепенно и формулируются понятно, постоянно поддерживается связь с представителем заказчика, и разобраться в проекте гораздо легче. Параллельно с этим можно составлять тестовую документацию.
Тестирование начинается чуть позже разработки, что позволяет быть в контексте проекта с самого его начала и значительно упрощает работу. Все стремительно меняющиеся пожелания заказчиков оперативно обсуждаются с командой и принимаются (или не принимаются) коллегиально, так как ВП находится в тесном контакте с командой и со временем понимает, что реально сделать, а что нет.
Регрессионное тестирование на Scrum-проектах: руководство по проведению
Согласно отчету The State of Agile Report («О развитии методологии Agile»), 95% опрошенных компаний разрабатывают программное обеспечение по Agile.
Во-первых, гибкая методология позволяет выпускать качественный продукт быстрее конкурентов за счет тестирования в каждом спринте. Во-вторых, с ее помощью можно легко внести изменения в ПО благодаря тесной коммуникации между заказчиком и участниками проекта.
При этом тесты регрессии остаются одними из наиболее частых проверок перед релизом новой функциональности. Как выполнять их эффективно, особенно если время на тестирование ограничено всего одним спринтом, зачастую составляющим 2 недели? Что делать, если нужно внести изменения в функциональность продукта на поздней стадии спринта?
В этой статье мы ответим на эти вопросы, а также расскажем о том, как проводить регрессионное тестирование на Scrum-проектах и уверенно преодолевать возникающие сложности.
Регрессионное тестирование в Scrum-среде
Регрессионные проверки играют одну из ключевых ролей в тестировании полного цикла и помогают добиваться следующих целей:
повышать общее качество и стабильность ПО благодаря снижению вероятности критических ошибок при его использовании и многократному уменьшению числа дефектов к моменту релиза;
ускорять доставку решения на рынок, уменьшая время прогона тестов за счет автоматизации;
сокращать расходы на подготовку продукта к релизу с помощью раннего обнаружения дефектов и применения автоматизации.
На Scrum-проектах регрессионные проверки особенно важны, поскольку помогают командам сконцентрироваться на новой функциональности, обеспечив при этом корректную и непрерывную работу ПО с каждым новым инкрементом продукта.
Таким образом, QA-специалисты могут быть уверены в том, что доработки никак не повлияли на уже существующую функциональность.
Топ-5 распространенных проблем и способы их преоделения
При проведении регрессионного тестирования на Scrum-проектах важно сфокусироваться на двух аспектах.
Первый ― определить функциональность, затронутую изменениями в коде. Если это неочевидно, необходимо проверять всю функциональность и соответственно раньше начинать тестирование в спринте, чтобы уложиться в сроки. Однако если можно безошибочно установить затронутые изменениями модули, работа станет более таргетированной, что сократит время на QA.
Второй ― выбрать проверки, которые можно автоматизировать. Важно помнить, что использовать автоматизацию уместно не во всех случаях. Особенно это касается GUI-проверок, где малейшие правки в дизайне приложения приводит к пересмотру тест-кейса с нуля.
Автоматизированные проверки подойдут для более стабильной функциональности, которая изменяется редко. А при нехватке времени поможет проактивный подход. Например, разработчики, инженеры по автоматизированному и функциональному тестированию работают над новой функциональностью в параллели и покрывают всё автоматизированными тестами в ходе одного спринта.
Но даже при должном понимании влияния изменившихся функций на приложение в целом и объема автоматизации, Scrum-команды могут столкнуться с рядом сложностей. Давайте перечислим их и рассмотрим, как можно решить.
Возрастающий объем регрессии
На крупных проектах с каждым новым спринтом объем регрессионного тестирования может увеличиваться. Чтобы эффективно им управлять, важно пересматривать тест-кейсы и удалять устаревшие. Делать это стоит по возможности и в зависимости от частоты вмешательства в релизы. Кроме того, это первый звонок, что уже можно и нужно внедрять автоматизацию.
Недостаточная коммуникация между участниками проекта
Специалистам по тестированию, бизнес-аналитикам, разработчикам и руководителям проекта стоит непрерывно взаимодействовать друг с другом. Так они смогут лучше понять объем работ и обеспечить эффективность процесса, начиная с подготовки тестовой документации и заканчивая пониманием того, какая функциональность больше не нуждается в регрессионном тестировании.
Поддержка тестовых сценариев
С увеличением числа тест-кейсов, будь то автоматизированные или функциональные, их поддержка усложняется. Чтобы минимизировать их обслуживание, важно больше коммуницировать с бизнес-аналитиками, которые знают взаимосвязи в бизнес-логике продукта и могут выявить несоответствия в тест-кейсах в случае внесения изменений.
Частые доработки функциональности
Смоделируем ситуацию: на проекте возникли непредвиденные и объемные изменения в требованиях к функциональности продукта. Еще и в конце спринта. Что делать? Да, сроки имеют значение, но важно позаботиться о качестве и оценить, сколько времени займет перезапуск тестов с учетом входной информации, чтобы расширить спринт и перенести дату релиза.
Ложноположительные результаты тестов
Причина может заключаться в некорректной разработке автоматизированного тест-кейса. Исключить подобную вероятность поможет валидация инженером по функциональному тестированию, который проходит тест-кейс по шагам и проверяет соответствие ожидаемому результату. Кроме того, в спринтах стоит закладывать время на интуитивное (ad hoc) и исследовательское (exploratory) тестирование, чтобы максимально расширить тестовое покрытие.
Тестируем регрессию на Scrum-проекте: о чем важно помнить
Для эффективного проведения регрессионного тестирования на гибких проектах важно приступать к созданию тестовой документации еще в самом начале разработки и в дальнейшем непрерывно обновлять ее в зависимости от входящих требований.
Что еще нужно учитывать? Предлагаем рассмотреть 5 шагов, от которых напрямую зависит результативность регрессионного тестирования.
1. Подготовить план тестирования
Этот этап включает в себя подбор необходимых тест-кейсов, их дальнейшее улучшение и доработку, оценку времени создания и выполнения регрессионных тестов, валидации дефектов и разработки финального отчета. Важно также определить тест-кейсы, которые в дальнейшем можно будет автоматизировать. Кроме того, на начальном этапе работ при взаимодействии с разработчиками проводится анализ того, какие модули могут быть затронуты изменениями, чтобы уделить этим областям больше внимания при тестировании.
2. Создать доску регрессии
Все задачи, над которыми работают QA-инженеры Scrum-команды, располагаются на доске в порядке сверху вниз по приоритетности в зависимости от возможных рисков, важности для клиента и ряда других факторов. Переставляя элементы на доске, команда всегда будет понимать актуальность задач и сможет планировать свое время так, чтобы укладываться в сроки.
3. Анализировать отчеты о дефектах
Так QA-команда сможет получить подробную информацию о проведении регрессионных тестов: причины их невыполнения, шаги тест-кейса, на которых произошла ошибка, снимки экрана. Все это поможет быстрее выявить проблему и устранить ее.
4. Добавить исследовательское тестирование
С его помощью инженеры по тестированию по-новому взглянут на проект, расширят тестовое покрытие и обнаружат дефекты, которые могли бы оказать сильное влияние на конечного пользователя разрабатываемого продукта.
5. Настроить модель коммуникации на проекте
Например, непрерывное взаимодействие специалистов по тестированию с владельцами продуктов способствует своевременному отслеживанию изменений в требованиях. В то время как коммуникация QA-инженеров с разработчиками ― получению информации о внесенных в ходе итерации изменениях.
Заключение
Регрессионное тестирование позволяет минимизировать риски сбоев в работе программного продукта после внесения изменений.
В ходе регрессионного тестирования на Scrum-проектах команды сталкиваются с рядом сложностей, которые можно решить благодаря:
обеспечению непрерывной коммуникации между участниками проекта;
поддержке документации в актуальном состоянии;
расширению спринта в случае внесения изменений в функциональность перед релизом;
валидации автоматизированных тест-кейсов.
Чтобы эффективно организовать процесс тестирования, важно:
создать план выполнения регрессии;
использовать доску регрессии;
тщательнее работать над ошибками;
не забывать о преимуществах исследовательского тестирования;
обеспечить открытое взаимодействие между участниками проекта на всех уровнях.
Подобный подход поможет гарантировать качество и стабильность ПО, несмотря на непрерывные доработки, и обеспечить слаженную работу Scrum-команд.
Стратегия тестирования в условиях Scrum: зачем она нужна и как построить
Артем Безручко — QA Engineer в Depositphotos. В тестировании он уже 5 лет, занимается как автоматизацией, так и ручным тестированием. Как Артем пишет в своей статье на DOU.UA, ему давно хотелось вынести тему тестовой стратегии на суд широкой публики. В основу его текста легли методы и активности, используемые тестировщиками его команды. Материал будет полезен для представителей всех технических направлений, особенно для лидов и тех, кто пока лишь задумывается о том, как построить процесс тестирования в продуктовой компании.
Мы живем в такое время, когда об автоматизации как инструменте упоминается настолько часто, что все остальные темы кажутся недосказанными. Очень много говорится о технологиях и новшествах, но очень мало о том, как их применять, грамотно решая возникающие проблемы.
Мне очень нравится подход Майкла Болтона. Он утверждает, что есть проверки, а есть тестирование. Автоматизация выполняет проверки и получает бинарный результат, а тестирование — это процесс, позволяющий получить развёрнутую информацию о продукте. Многие инженеры пытаются завести у себя на проектах автотесты, не совсем понимая, зачем они им. Большинство тестировщиков стремятся уйти в автоматизацию не из-за пользы для текущего проекта, а просто потому, что модно. И это проблема. Рассмотрим же, что такое тестовая стратегия и как такой подход поможет проекту.
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. Что будет реализовано в тикете?
Описание в таск-трекере могло остаться неизменным, но вектор задачи при этом мог измениться из-за нового видения ситуации или пожеланий бизнеса. Этот пункт позволяет нащупать единую точку отсчета и понимания — как для отдела разработки, так и для тестирования.
2. Зачем это делается? Какова бизнес-цель?
На характер и специфику дальнейшего тестирования очень сильно влияет истинная цель, ради которой и реализуется задача. Важно отметить, кто будет потребителем этой фичи: все пользователи, определенные группы пользователей, внутренние отделы компании, третий сервис или что-то другое.
3. Что будет задето этой задачей?
На первый взгляд, простой вопрос. Но ответ на него иногда вскрывает настолько неочевидные связи, что задавать его стоит в протокольном порядке. У нас был случай, когда при добавлении нового типа подписки переставала приходить рассылка, будучи соотнесенной с другими платежными планами. А в случае с баннером (см. пункт 1) была нарушена логика трекинга поведения пользователя.
Именно стандартизированный подход к подготовке тестирования помог обнаружить критическую проблему.
4. С какими сложностями есть вероятность столкнуться при тестировании и эмуляции?
Разработчик проанализирует сотни строк кода, прежде чем написать свои. А если он хороший инженер, то задумается еще и над тем, чтобы его творение было пригодно для тестирования. Задав подобный вопрос, вы сможете избавить себя от часов бессмысленных исследований.
Пример. Когда мы внедряли оплаты и подписки для мобильных приложений через Apple, было достаточно сложно тестировать граничные значения и интеграцию с основным проектом. Разработка сделала приятную схему на API с хорошо конфигурируемыми мок-объектами, что значительно облегчило жизнь тестировщикам.
5. Согласовать критерий качества приемки задачи
Один из удивительных законов Мерфи применительно к разработке ПО формулируется так: «Все, что может быть понято двояко, будет понято двояко». Именно поэтому у нас инженеры проговаривают основные пункты приемки фичи, чтобы исключить возможные разночтения. Очень важно, чтобы сотрудники находились в одном контексте и имели единую систему координат и точку отсчета при работе над задачей.
6. Есть ли у разработчика пожелания и советы по тестированию задачи?
Провокационный вопрос, призванный поднять в памяти коллеги весь проговоренный материал, чтобы случайно ничего не упустить.
7. Подготовить альфа-версию чек-листа.
Очень полезная активность. Все скрытые нюансы, граничные значения и сущности после основательной беседы с разработчиком находятся в оперативной памяти нашего мозга. Самое время освободить ее и запечатлеть в виде первой версии чек-листа. В нем необходимо отметить основные модули, связи и специфические условия — одним словом, все, что поможет любому инженеру моментально найти точки входа для быстрого развертывания процесса тестирования.
8. Проверить описание задачи в Jira и исправить или дополнить на основе полученной информации в вышеперечисленных пунктах
Задачи в таск-трекерах сделали людям огромное одолжение, освободив их от бумажной работы. Запомните: таск в Jira — это документ, значит, он должен быть полным и оформлен согласно стандартам. Никогда не пропускайте этот пункт и обновляйте описание тикетов, как только получаете новую информацию.
Закрыть долги
Если удастся полностью выполнить предыдущий пункт и еще остается свободное время, то мы переключаемся на документальные и организационные задачи.
1. Кейсы, не записанные в TestLink или другой тест-трекер
Всегда найдется сьют, который следовало бы проапдейтить, или функционал, для которого не созданы тест-кейсы.
2. Несозданные тикеты на автотесты
Мы пишем автотесты вдогонку выпускаемому функционалу. И если уж выдалась свободная минута, выгодно потратить ее на ревью кейсов, которые будут автоматизироваться, а также на анализ выпущенных фичей. Возможно, были пропущены важные сценарии или давно напрашивается рефакторинг.
3. Пропущенные статьи в Wiki
Документация условно делится на исполнительную и повествующую. Тест-кейсы относятся к первому типу, а создание страниц во внутренней Wiki — ко второму. Это полезная процедура, она помогает закрепить комплексные понятия о разделе, а в случае необходимости провести ликбез или быстро напомнить об упущенных деталях. Поэтому не стоит упускать возможность поработать с внутренней библиотекой.
Новые инструменты появляются постоянно, и сообщество предлагает большой выбор методов и подходов к работе. Где, как не в боевом окружении, их тестировать?
Середина спринта (тикеты непосредственно берутся в тестирование)
Рабочие дни идут, и вот таски планомерно заполняют столбик «Тестирование». Следующие действия качественно влияют на процесс, поэтому я настоятельно рекомендую именно такой порядок активностей.
Перед началом любых действий по задаче, которая требует тестирования, нужно перечитать описание и повторно переговорить с разработчиком (кратко). Цель — уточнить, одинаково ли все участники понимают задачу, а также убедиться, что ничего не изменилось, не встретились «подводные камни», которые внесли поправки.
Затем следует провести тест-дизайн, углубив анализ задачи на основе альфа-версии чек-листа, написанного ранее.
Бросаться на задачу с шашкой наголо и кромсать ее исследовательским тестированием — это похвально, но только после детальной проработки общего плана работ. Основные его пункты:
Только получив сформированный обозримый объем для тестирования, можно приступать к работе. Если есть сомнения, попросите коллег по цеху сделать ревью чек-листа.
Любая деятельность ценна тем, что она что-то производит. Продукт тестирования => обратная связь по тикету. И чем быстрее она возвращается к разработчику, тем лучше. Но не стоит жертвовать полнотой информации, необходимо соблюдать баланс.
На техниках и подходах к ручному тестированию я останавливаться не буду. Надеюсь, все читатели прекрасно ими владеют.
Заведение отчетов об ошибках
Хочу обозначить два полезных момента:
Наконец все найденные баги исправлены и запланированные проверки пройдены. Тикет получил резолюцию тест-инженера. Но на этом процесс тестирования не заканчивается. Дальше идут рутинные, но очень полезные активности.
По завершении тестирования тикета остается выделить кейсы для автотестов, оформить кейсы в TestLink и завести статью в Wiki.
Конец спринта
Благодаря четкому выполнению всего вышеописанного в последние день-два нагрузка на отдел тестирования снижается, высвобождая время для анализа проделанной работы.
Назначенный человек оценивает работу в спринте по следующим пунктам:
Активности над спринтами
В описанном выше режиме проходит неделя (спринт, месяц — подставим сюда любой временной отрезок). Гладкая и выверенная схема начинает сбоить. И это нормально, ибо нет ничего вечного. Самое время примерить роль QA в широком смысле этого слова.
На следующем планировании один человек из отдела тестирования берет на себя задачу под названием «Пересмотр тестовой стратегии».
Таск включает следующие разделы:
1. Анализ проделанной работы за квартал/полгода
Просматриваются задачи, анализируются их характер, специфика и направление. Какие фичи релизились, какие заморозились, какие проблемы были наиболее распространены? Что автоматизировано, какую документацию создавали, какая не пригодилась? Также уточняется вектор будущего развития продукта, возможно, перечень технологий, которые планируется внедрить. Основные цели:
2. А не глупости ли мы делаем?
Этот вопрос я задаю себе каждый раз, когда тестирую новый подход, инструмент или технику в работе и организации команды. Но на этот раз вопрос стоит глобально. Цель — найти активности, на которые тратится больше времени, чем они принесут пользы. У нас такими оказались тест-отчеты. Мы составляли их еженедельно, тезисно описывая неочевидные связи и возникшие проблемы. Времярасходовалось, а польза стремилась к нулю.
3. Сбор метрик по команде и проблемам
В этом пункте источником информации выступает таск-трекер. Собираем численные показатели:
4. Укрепление положительных активностей
Этот пункт призван укоренить действия, которые нетипичны для специалистов нашей области, но оказались нам по силам и принесли ощутимый результат.
В нашем случае экстраполезной активностью оказалось ревью тикетов и баг-репортов. Было время, когда у нас менялись участники команды, и в конце концов оказалось, что у каждого свое понимание предметной области. Из-за этого возникало недопонимание и множество конфликтов. Наконец было принято решение проводить ревью задач и отчетов об ошибках сразу после их создания. За несколько недель это привело всю команду к единому стилю технического описания и единой базе дефиниций.
Вторая такая активность — создание расширения для Google Chrome, которое в пару кликов приводит тестового пользователя в состояние готовности к тестированию.
Обычно для создания предусловий требуется от 1 до 5 минут, а благодаря приложению это делается в 3-4 клика за 10 секунд. Вроде не так уж и много, но в течение дня это экономит от 30 минут до часа. При масштабировании на всех тестировщиков профит заметно ощутим.
5. Анализ сохраненных знаний, систематизация
Проводится вычитка созданных статей и тест-сьютов. Цель — выбросить ненужное и устаревшее, организовать полезное, создать задачи на документирование и исправление нужного.
6. Чего не хватает отделу тестирования в целом?
Этот пункт требует анализа грубых ошибок, допущенных сотрудниками. Зачастую они связаны с незнанием предметной области или неумением пользоваться выделенными инструментами.
Пример. Depositphotos использует много платежных систем для удобства пользователей по всему миру. Естественно, для Бразилии нужны одни провайдеры платежей, а для Канады — совсем другие. Налоги, которые платят пользователи в той или иной стране, записываются в отдельный налоговый сервис, а уже по нему компания предоставляет отчеты в соответствующие органы.
Так вот, при добавлении нового провайдера в Канаду после введения специального налога в провинции Квебек транзакции перестали попадать в сервис. Итог — приличный штраф для компании.
А оказалось, что тестировщик, проверявший эту функциональность, банально не знал нюансов налогообложения. Небольшого ликбеза было достаточно для предотвращения подобных ошибок в будущем.
7. Пересмотр тестовой стратегии
На основе полученных данных необходимо внести коррективы в изначальный процесс тестирования.
8. Проверка знаний команды, выделение личных векторов развития
Это небольшой опрос, который проводится среди сотрудников по основным технологиям и навыкам, необходимым для выполнения задач. Благодаря такой проверке легко понять уровень команды, а также определить, по каким ключевым параметрам в случае необходимости подбирать новый персонал или на какие курсы (воркшопы) направить действующих участников.
Результат применения тестовой стратегии
Что решает такой подход?
Хочу привести графики, на которых показан период в один год. Все это время мы следовали описанной стратегии. Графики, быть может, не суперпрорывные и выглядят не слишком впечатляюще, но каждая цифра в них реальная.
Каждый 13-й баг находит пользователь (показатель >10 — хороший). Количество оформленных багов показывает тенденцию к уменьшению, а количество проблем пользователей стабильно. На основе этого можно предположить, что кастомеры находят проблемы спустя длительное время после релиза фичи. Уменьшение количества найденных багов говорит о том, что больше проблем выявляется на этапе анализа требований и более плотного взаимодействия разработки с тестированием. Ну, или это признак ухудшения работы команды тестирования.
Задачи, выполненные инженерами тестирования и назначенные на отдел
Тестировщики на одну задачу для себя дополнительно ставят еще две. Наблюдается тенденция к увеличению количества задач, выполняемых непосредственно инженерами. На основе этого предполагаю, что процесс тестирования эволюционирует, поскольку механизмы и решения создаются «под проект».
Все проблемы пользователей и баги, пропущенные в области ответственности команды
Каждый восьмой кастомер-баг относится к нашей команде. Общее число кастомер-проблем демонстрирует тенденцию к уменьшению, а проблемы, решение которых поручено команде, имеют постоянную характеристику. Это подтверждает, что кастомеры находят баги спустя длительный промежуток времени (ориентировочно полгода-год).
Выводы
Тестовая стратегия помогает в том случае, если вы имеете конкретную цель. В нашем кейсе целью было успешное закрытие спринтов, уменьшение количества багов, с которыми сталкиваются пользователи в продакшене, эффективное накопление и расшаривание знаний среди сотрудников. По каждому из этих пунктов мы достигли хороших результатов. Поэтому считаю, что затраты сил на разработку и внедрение стратегии того стоили.
Хочу дать несколько небольших советов тем, кто решит делать что-то подобное в своей команде.
Будьте последовательными
Каждую активность проверяйте, анализируйте и аргументируйте. Не нужно бездумно копировать сторонние подходы. Вы не знаете и никогда не узнаете всех нюансов, которые привели другие команды к их результатам.
Будьте системными
Системный подход — это отличная страховка в очень переменчивом мире. И когда совсем непонятно, что делать, следование изначальному плану помогает сориентироваться и выработать необходимое решение.
Будьте профессиональными
Все хотят работать с людьми, у которых есть чему поучиться, и очень ценят коллег, четко выполняющих свои обязанности. Зарабатывайте авторитет, и тогда вам будет легче вносить изменения в устоявшиеся процессы в своем окружении.