что такое agile тестирование
Повышение качества с помощью agile-методик тестирования
Необходимость в ручном тестировании по-прежнему существует — но не в том виде, как все привыкли
Просмотр тем
Когда для управления проектом используется каскадная модель, разработка и тестирование осуществляются на двух разных этапах: разработчики создают функцию, а затем передают ее команде по контролю качества для тестирования, самоустраняясь от участия в дальнейшем процессе. Команда по контролю качества составляет и реализует подробные планы тестирования. Она также документирует все дефекты, обнаруженные в ходе тщательной проверки на предмет ухудшений, которые новая работа могла вызвать в существующей функциональности.
Многие команды, применяющие каскадную или другие традиционные модели тестирования, сталкиваются с тем, что по мере развития продукта объем тестирования многократно увеличивается, и отдел по контролю качества вынужден стараться изо всех сил, чтобы не отстать. Владельцы проекта встают перед тяжелым выбором: перенести релиз на более позднюю дату или сэкономить на тестировании (попробуйте угадать с первого раза, какой из этих вариантов выбирают в 99 % случаев). А тем временем разработчики начинают заниматься другими делами. При этом не только растет технический долг, но и для устранения каждого дефекта требуется дорогостоящее переключение контекста между двумя фрагментами базы кода. Положение усугубляется.
Как на беду, заработная плата команды по контролю качества обычно зависит от количества обнаруженных ошибок, из-за чего разработчики вынуждены занимать оборонительную позицию. Неужели нельзя найти для разработчиков и отдела по контролю качества способ уменьшить количество ошибок в коде и одновременно избавить владельцев проекта от мучительного выбора? Не позволит ли это создавать более качественное во всех отношениях ПО?
Отказ от традиционных способов тестирования в пользу agile
Команды Agile и DevOps стремятся наладить стабильную поставку новых функций высокого качества. Однако традиционные методики тестирования попросту не вписываются в принципы Agile или DevOps. Высокие темпы разработки требуют нового подхода к обеспечению качества каждой сборки. В компании Atlassian тестирование проводится по принципам Agile. Все тонкости нашего подхода к тестированию раскроет Пенни Уайетт — руководитель команды по контролю качества Jira Software.
Технический долг, как задолженность по кредитной карте, растущая с процентами, поначалу ощущается как небольшая заноза, но затем быстро приобретает пугающие масштабы и сковывает действия команды, не позволяя ей следовать принципам agile. Чтобы справиться с быстрорастущим техническим долгом, мы в компании даем разработчикам возможность быть главными специалистами по качеству (более того, мы ожидаем этого от них). Мы уверены, что разработчики обладают принципиально важными навыками для обеспечения качества продукта.
По нашему мнению, для каждой пользовательской истории в бэклоге нужно писать код дважды: код самой функции и код автоматического теста. В некоторых командах код функции пишут разработчики, а кодом автоматических тестов занимается специальная команда, но мы считаем, что гораздо эффективнее, когда оба вида кода пишет один специалист.
Баги в новых функциях и ухудшения в существующих следует воспринимать по-разному. Если баг обнаруживается во время разработки, выделите время, чтобы понять, в чем проблема, устраните ее и продолжайте работу. Если обнаруживается ухудшение (т. е. проблема возникла в той функциональности, которая раньше работала нормально), то оно, скорее всего, проявится снова. Разработайте автоматический тест, который предотвратил бы это ухудшение в будущем.
Из этого подхода не следует, что разработчики должны работать сами. Важно, чтобы в команде были и специалисты по контролю качества. Они видят разработку функции с другой стороны, и их мнение важно. Хорошие специалисты по контролю качества знают, где обычно скрываются баги, и могут предупредить разработчиков о подводных камнях.
Вмешательство человека через глубокое тестирование
В нашей компании разработчики вместе со специалистами по контролю качества проводят глубокое тестирование — полезную практику, применяемую при разработке, для отсеивания более серьезных багов. Как и при проверке кода, при глубоком тестировании в команде разработчиков происходит обмен знаниями, полученными в ходе него. У разработчиков развиваются навыки тестировщиков, благодаря чему они изначально поставляют код более высокого качества.
Можно подумать, что глубокое тестирование — это ручное тестирование, но на самом деле нет. Во всяком случае, это не то же самое, что ручное регрессионное тестирование. Для глубокого тестирования используется подход, основанный на оценке риска, и критическое мышление. Тестировщик может использовать свое знание рисков, особенностей реализации и потребностей клиентов, и на ранних стадиях тестирования эта возможность позволяет разработчику или специалисту по контролю качества быстро и системно находить проблемы без помощи тестовых сценариев, обстоятельных планов тестирования или требований. Нам этот подход кажется эффективнее традиционного ручного тестирования, поскольку мы применяем выводы, сделанные в ходе сеансов глубокого тестирования, к исходному коду и автоматическим тестам. При глубоком тестировании мы также получаем опыт использования новой функции, который нам не дает тестирование по сценарию.
Для поддержания качества на постоянном уровне нужно сочетать глубокое и автоматическое тестирование. Глубокое тестирование позволяет обеспечить более полное соответствие кода разрабатываемых функций требованиям к качеству, нежели автоматические тесты сами по себе. Если автоматические тесты просто делают разрабатываемую функцию более стабильной, благодаря глубокому тестированию повышаются удобство ее использования и ее практическая ценность в целом, а также улучшается визуальное исполнение.
Изменения могут оказаться непростыми — очень непростыми
В заключение хочу рассказать историю из жизни, которая прекрасно обобщает весь мой опыт agile-тестирования. Когда-то на заре карьеры я руководил командой разработчиков, которые были решительно против написания автоматических тестов, потому что «этим занимается команда по контролю качества». В течение нескольких итераций на выходе мы получали код с кучей багов, и в какой-то момент я понял, что сыт по горло рассказами о негативном влиянии автоматического тестирования на скорость работы команды. Я занял принципиальную позицию: отныне весь новый код должен проверяться с помощью автоматических тестов.
Уже после первой итерации качество кода повысилось. И разработчик, который больше всех противился тестовым сценариям, первым бросился исправлять ошибку, когда та была обнаружена в ходе тестирования! В следующих итерациях были составлены новые автоматические тесты, была расширена поддержка браузеров и улучшилась наша культура разработки. Да, для выпуска функции пришлось потратить больше времени. Но количество ошибок и объем доработок резко снизился, и в результате мы сэкономили уйму времени.
Изменения очень редко происходят легко. Но, как и в случае со многими стоящими вещами, если приложить усилия и начать работать по новой модели, на выходе останется только вопрос: «Почему мы не сделали это раньше?!»
Как повысить качество работы agile-команд с помощью тестирования
Разработка по методологии Agile нацелена на то, чтобы выдавать новые фичи быстро и с нужной периодичностью, обеспечивая постоянный поток изменений. Гибкий подход позволяет команде держать высокий темп, но из-за этого нередко страдает качество кода и стабильность продукта. Как решить эту проблему, не загоняя команду в жесткие рамки и не лишая ее преимуществ agile-методов? Помощь приходит со стороны тестировщиков. Меня зовут Денис Дубовой, я руковожу отделом тестирования в дирекции больших данных X5 Retail Group, и в этом материале я расскажу, как появление тестировщиков помогло повысить качество работы наших разработчиков.
Выработка правил через тестирование
Команды, работающие по agile-методологии, часто пренебрегают качеством. Отчасти это происходит из-за того, что традиционные методологии тестирования не вписываются в «гибкий» контекст, отчасти из-за приоритетов скорости над качеством. Первоочередная задача agile-команды — оперативно реализовывать функции, которые нужны бизнес-заказчику. Это особенно актуально на стадии становления продукта, когда его функционал определяется буквально путем проб и ошибок, и разработчикам нужно быстро перестраивать продукт под текущие запросы. В такой ситуации команда часто решает так: позовем тестировщика потом, когда сделаем MVP/первую рабочую версию/познаем дзен — потому что просто не понимает, как организовать гибкое тестирование. В итоге часто получаются срывы сроков поставки, ошибки на демо и, самое страшное, в ПРОМ-среде.
В нашем случае была очень похожая ситуация: Управление разработки продуктов больших данных X5 Retail Group существует уже 2 года, и на первых порах качество продуктов поддерживалось только силами самих разработчиков — не было выделенной роли QA-специалиста, а отдел тестирования и первый тестировщик в продукте появились только год назад, когда продукты уже успели стартовать.
Сегодня в отделе тестирования уже 15 человек: 11 тестировщиков сопровождают продукты в командах, два человека развивают направление нагрузочного тестирования и еще два – направление автоматизации тестирования. Во многих продуктовых командах тестировщики стали катализатором важных изменений: их приход упорядочил процесс разработки и повысил стабильность релизов. Для этого мы подключали тестировщиков к уже работающим командам по следующей схеме:
1. Погружаемся в процесс
На первом этапе нам надо понять, как сейчас работает команда, как в ней распределяются роли и как происходит обмен информацией. Тестировщик начинает помогать с тестированием, больше в виде «контроля качества», попутно оценивая зрелость команды и процессов в команде – для этого есть своя небольшая «тепловая карта» зрелости, пример которой можно увидеть ниже. На ней можно видеть, насколько развиты различные направления (разработка, тестирование, DG, DevOps, поддержка) в каждом из наших продуктов.
Тепловая карта оценки зрелости
Оценку зрелости процессов тестировщики собирают вместе с разработчиками, оценивая набор технологических и методических практик, используемых командой. В итоге по тепловой карте мы можем увидеть, что и на каком участке можно улучшить – например развить практику Unit-тестов в разработке или автоматизировать проверки API в тестировании – для каждой стадии жизни продукта (прототип, пилот, пром) рекомендуется свой набор практик.
2. Вырабатываем рекомендации по улучшению
Разобравшись, как живет команда, можно продумать первые рекомендации по улучшению ее работы. Тут мы придерживаемся следующей логики: тестировщики – не выделенная функция, отвечающая за определенный участок, мы часть команды и можем влиять на весь процесс. Для того, чтобы облегчить запуск улучшений, начинаем с базовых вещей:
3. Презентуем наши улучшения руководителям команд и заинтересованным лицам, делая акцент на том, какие проблемы решат эти улучшения
Процесс пойдёт проще, если заручиться поддержкой команды. Важно «продать» свою идею, показать, какой профит принесут предложенные вами изменения. Например, критерии приемки, которые мы упоминали выше, могут выглядеть как дополнительная работа для аналитика, но когда команда понимает, какую экономию времени она получит – а это от часов до дней, которые могут уходить на уточнение задачи, – то принимает улучшение намного легче.
В некоторых случаях можно действовать через владельца продукта. Например, продукту не хватает мониторинга (допустим, технического, с логами и красивыми графиками) и на настройку нет времени, ведь это не продуктовая задача. В таком случае можно обратиться к продакту и пояснить, какие именно выгоды он получит от мониторинга (стабильнее сразу не станет, но вырастет скорость локализации проблем), и попросить его выделить на это ресурсы.
Параллельно со стандартизацией работы в продуктовых командах идёт проработка подходов к тестированию, которые обеспечивают качество продуктов, например, оценка и подготовка необходимых объемов тестовых данных, проработка тестовой модели, формирование точек будущей автоматизации и т.д.
Всегда есть вероятность, что команда не примет предлагаемые изменения, какими бы разумными они вам ни казались. В каждом отдельном случае необходимо формировать свои подходы и искать индивидуальный способ убеждения. Продукты очень разные, и подходы, работающие в одном продукте, совсем не работают в другом.
Многие команды уверены, что способны сами организовать свою работу, и иногда это действительно так. Были случаи, когда наше участие сводилось к рекомендации основных точек проверки, и дальше команда прекрасно все реализовывала на уровне кода, а мы просто оставались рядом, всегда готовые помочь. Но чаще происходит по-другому: в команду приходит наш сотрудник, и разработчики в шутку начинают «плакать» от найденных тестировщиком дефектов, радуясь при этом, что дефекты найдены до демо или промышленного релиза.
Что изменилось
Перемены в продуктовых командах шли по-разному и затронули разные стороны процесса. В одной из команд тестирование сначала стало узким местом: оно требовало времени, и не все понимали, что же происходит на этом этапе. В виде эксперимента мы подключили разработчиков к запуску тестов, в результате чего они смогли прочувствовать работу тестировщиков и даже увидеть продукт в целом – не отдельную функцию построения отчета, например, а весь путь от авторизации пользователя в продукте и проведения бизнес-операций до итога – выгрузки отчета. Так мы усилили вовлеченность всей команды, сделали прозрачным процесс тестирования и показали важность этого действия, а описанная выше практика стала регулярной.
В другом продукте с нашей помощью изменился релизный цикл. Изначально было устроено так, что результаты спринта уходили в тестирование в пятницу после обеда, а в понедельник продукт уже попадал к заказчику. На тестирование и исправление критических ошибок оставался самый конец пятницы и лишь начало понедельника, и в итоге новая версия нередко выходила «сырой» или же разработчикам приходилось срочно фиксить баги в выходные. После пары сложных сдвигов поставки команда все же перенесла сдачу спринта на среду (не уменьшила длину спринта, а просто сдвинула график на два дня). Теперь у команды есть время проверить и исправить поставку в спокойной обстановке.
Окончательное решение, меняться или нет, остается за командой: именно она отвечает за продукт и его выход, поэтому она и выбирает наиболее удобный для себя вариант. Цель нашей работы – не в том, чтобы навязать программистам свои подходы, а в том, чтобы дать максимум информации о возможных рисках и предложить подходящие продукту улучшения и действия.
Что удалось сделать нашему отделу тестирования за прошедший год:
В планах – работать с методологией тестирования (в частности, с подходами к тестированию в Agile), активно развивать автоматизацию, довести до ума инструментарий, обеспечить интеграцию инструментов, более детально заняться инфраструктурой для тестирования и тестовыми данными, а в идеале – прикоснуться и к работе с обучаемыми моделями.
Изменения всегда сложны, но они необходимы, если мы болеем за наши продукты. И именно тестировщики могут внести значительный вклад в обеспечение качества продуктов.
В следующих материалах я с коллегами расскажу, как мы тестируем конкретные продукты, о выборе стратегии тестирования, об инструментах (например, Allure Enterprise edition – удобное средство для управления тестированием, формирования отчетности и даже управления автотестами), о том, как внедряем автоматические тесты в пайплайн и какие варианты развития видим (Test Driven Development, если вы подумали о нем, это только один из возможных вариантов ).
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Продолжу хвастаться статусом книги.
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Алан Ричардсон
Перевод: Ольга Алифанова
Когда мы работаем над Agile-проектом, нам требуется гигантская гибкость и возможность подгонки того, что мы делаем, под нужную форму.
Я могу сказать, чем Agile-тестирование не является. Существительным.
Поэтому когда мы спрашиваем, что такое Agile-тестирование – это не вещь. Нельзя купить пачку Agile-тестирования… Это глагол, это подход, это процесс.
Это то, как мы тестируем в Agile-проектах.
Это то, что мы делаем, и образ нашего мышления. Характерного для Agile-проекта.
Это кажется тавтологичным, очевидным, но по какой-то причине люди все усложняют, и началось это не вчера, как мы сейчас и выясним.
Люди цепляются за слова. А цепляются за них они потому, что не понимают по-настоящему, что эти слова означают. Они не понимали, что тестирование значило раньше. И Agile-тестирование кажется им новшеством.
В Agile мы необязательно заранее знаем, что мы будем делать.
Мы будем адаптироваться. Мы будем приоритезировать одну функциональность против другой, и тест-подход это компенсирует. И это делает наше тестирование уникальным.
Оно уникально для окружения, в котором мы работаем, для компании, на которую мы работаем, для организации. Оно может различаться в каждом департаменте этой организации и в каждой команде этой организации. А иногда оно различается для каждого члена команды.
Чем более последователен и логичен процесс в Agile, тем лучше он работает. Стоит надеяться, что все члены команды разделяют одно и то же видение проекта, но так бывает не всегда.
Процесс тестирования – не нечто отдельное, живущее параллельной жизнью, не то, что можно отдать на аутсорс и оффшор. Это процесс, тесно связанный с подходом к программированию.
Потому что все это – подход к разработке ПО.
Одна часть этого подхода – программирование.
Другая часть – тестирование.
Они сливаются воедино, создавая эффективный процесс Agile-разработки.
Возможно, в нашем обычном процессе программирования внедрено множество снижающих риск процессов (TDD, ATDD).
Следовательно, подход к тестированию меняется, потому что меняется профилирование рисков.
Риски будут возникать в других местах системы, поэтому мы тестируем иначе, чтобы постараться это учесть.
Хочется верить, что тестировщик может тестировать лучше других; может тестировать иначе, чем другие. И мы хотим соответствующим образом использовать эти навыки в проекте, чтобы тестировщики не тратили свое время, покрывая только базовые критерии приемки.
Потому что практически кто угодно может протестировать на покрытие базовых приемочных критериев.
По мере развития проекта профиль его рисков меняется. Когда проект стартует, мы принимаем высокие риски, потому что мы стараемся создать минимально жизнеспособный продукт, хоть что-нибудь, чтобы обосновать определенные предположения, убедиться, что мы на верном пути, или полностью определиться, чего же хотят наши пользователи. Однако позднее мы хотим сделать наш проект более устойчивым, и не принимаем на себя столько риска, когда системой уже пользуются живые люди.
По мере того, как команда учится работать совместно, происходит передача знаний. Программисты учатся лучше тестировать, так как работают с тестировщиками. Следовательно, количество тестирования, выполненного программистами, со временем меняется. Тестовый подход меняется и адаптируется.
Подход Agile на самом деле ничем фундаментально не отличается от любого другого тестирования. Отличия заключаются в том, что у нас принято ассоциировать тестирование с большим количеством процессов, ловушек, атрибутики. Множеством дополнений.
Эти дополнения – ответ на требования процесса разработки, делающего множество всего заранее. А тестирование очень часто меняется в ответ на требования разработки.
Еще больше тут требуется вербальная коммуникация, дабы брать на себя ответственность за идентификацию рисков и проблем, когда они возникают.
Нам не нужна расширенная документация.
Это не значит, что у нас ее вообще нет.
Попытки что-то записать все еще важны для нас.
Но это не значит, что нам нужен инструмент управления тестированием – мы можем использовать какой угодно инструмент для отслеживания нашего проекта.
Все это – не тестирование.
Нам нужно понимать суть тестирования.
Это очень важно в Agile-процессах: мы делаем нечто постепенно, по ходу пьесы. И это означает, что мы отвечаем на нужды и изменения окружающей среды на основании своего опыта и опыта других людей, на основании того, что происходит в мире, конференций, статей. Мы впитываем все это. Мы экспериментируем. Мы видим, что работает, а что нет.
«Делать что-то по ходу пьесы» звучит так, как будто это что-то плохое. Мы делаем продукт по ходу дела, потому что мы тратим много времени на изучение областей, которые работают, которые связаны со сложными динамическими системами, и учимся у них.
Тестирование никогда не было про тестировщика.
Тестирование всегда было про процессы, которые мы используем, про подход, который мы применяем, и про полученные результаты. И Agile в особенности отвергает подход «тестировщик занимается тестированием».
Agile про то, что тестировать – глагол, процесс в проекте. И если тестировщики держатся за тестирование обеими руками, крича, что «тестируем тут мы», то они не пользуются гибкостью и свободой Agile-проекта.
Нет такого, что вы приходите в Agile, и начинается «ага, это Agile-проект, нам нужна тест-стратегия, на одну страничку, потому что это Agile, а наш процесс в том, что…». Все развивается. Все меняется в зависимости от нужд проекта, навыков людей в команде, динамики существующего набора, и мы ожидаем этих перемен.
Мы можем добиться успеха в Agile через понимание и использование сути тестирования, и этому мы как тестировщики должны научиться. Это та ценность, которую мы даем Agile-проектам – сущность тестирования. И иногда мы – единственные, кто может ее внедрить, пока мы не научим других, как это правильно делается.
Более подробное мнение Алана Ричардсона см. на видео (на английском языке)
Agile с точки зрения программиста
Недавно наткнулся на интересную статью «Меня беспокоит Agile, и я хочу об этом поговорить». В ней рассказывается про тюнинг этого процесса с точки зрения менеджера.
Мне же захотелось описать, что такое agile для меня как программиста. Без манифестов и громких слов. И что в нем особенного по сравнению с другими методологиями.
Предистория
Я работаю программистом в течение 9 лет. За это время попробовал себя в 7 компаниях от совершенно «беспроцессных» до сертифицированных СММI 5 уровня (кто знает, что это такое, не стоит сдерживать улыбку)). С этой компании с самым «строгим» в моей жизни процессом я и начну…
2008 год. Компания Моторола. Я параллельно заканчивал обучение в институте и имел 3 года опыта работы по специальности за спиной. В общем, считал себя опытным программистом. И тут в первый (и, надеюсь, последний) раз столкнулся с по-настоящему «негибким» процессом. Моторола очень гордилась своей сертифицированной CMMI Level 5 моделью разработки ПО и собственной концепцией управления производством от 1986 года Six Cigma.
Вполне допускаю, что для разработки железа тот процесс мог быть полезен. Возможно, что ПО для покорения космоса тоже стоит создавать под чем-то подобным. Но когда для написания простых клиентских приложений требовалось документации в несколько раз больше, чем кода, то это уже полный абсурд. Я чувствовал себя настоящим научным работником. Только вместо исследования кривизны пространства-времени, писал многостраничную документацию об имплиментации крошечного JSR. Который, к сожалению, не позволял направить ракету на марс, а лишь реализовывал API для получения уровня заряда батареи телефона.
Тогда я думал, что возможно так надо в больших компаниях и надеялся, что этим хотя бы достигается высокое качество продуктов, которыми пользуются миллионы человек. Но чем дольше я работал по такому процессу, тем больше осознавал бесполезность всех этих документаций. Как минимум, потому что большинство из них никто никогда не читал, а времени на создание и многоуровневые review тратилось уйма. При этом на качество кода это никак положительно не влияло.
И тут у Моторолы кончились деньги и настал cost saving. Начальство нам отчиталось, как много финансов удалось сэкономить, убрав одноразовые ложки из компанейских столовых по всему миру, но на этом не остановилось. Наш процесс разработки был резко преобразован в Agile.
Отличия от «негибкой» Моторолы
Что изменилось? Все.
Отличия от беспроцессности
Итог перехода на Agile
Наша команда разрабатывала приложение myFaves. Его надо реализовать для каждой платформы телефона, который компания хочет продаваться через мобильного оператора T-Mobile. Таким образом, данное приложение разрабатывалось десятки раз в стенах Моторолы. Но именно нашей команде удалось уложиться в самые короткие сроки за всю историю компании. Качество же тоже оказалось на самом высоком уровне, в результате чего оператор принял наш продукт на первом же test cycle. При этом разработка велась командой, обучавшейся этой системе по ходу создания продукта. Да и Андроид тогда еще был очень сырым. К тому же некоторые вроде меня обучались и самой Java.
Дальнейшие мысли
После этого, мне довелось ещё познать разные виды процессов, работая в Корее в Самсунге, затем в отечественных и американских компаниях. Но пока все вернулось снова к Agile в моей текущей компании Netflix.
Плюсы Agile
При этом я полностью понимаю, почему весь мир переходит на гибкие методологии. И для меня как инженера есть ряд незаменимых плюсов этого процесса:
Минусы
Также в глаза бросается и неидеальность данного процесса:
В заключении, вспоминается известная фраза Уинстона Черчилля про демократию, которую вполне можно применить и к Agile:
«Демократия — наихудшая форма правления, за исключением всех остальных, которые пробовались время от времени.»