agile тестирование что это
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Алан Ричардсон
Перевод: Ольга Алифанова
Когда мы работаем над Agile-проектом, нам требуется гигантская гибкость и возможность подгонки того, что мы делаем, под нужную форму.
Я могу сказать, чем Agile-тестирование не является. Существительным.
Поэтому когда мы спрашиваем, что такое Agile-тестирование – это не вещь. Нельзя купить пачку Agile-тестирования… Это глагол, это подход, это процесс.
Это то, как мы тестируем в Agile-проектах.
Это то, что мы делаем, и образ нашего мышления. Характерного для Agile-проекта.
Это кажется тавтологичным, очевидным, но по какой-то причине люди все усложняют, и началось это не вчера, как мы сейчас и выясним.
Люди цепляются за слова. А цепляются за них они потому, что не понимают по-настоящему, что эти слова означают. Они не понимали, что тестирование значило раньше. И Agile-тестирование кажется им новшеством.
В Agile мы необязательно заранее знаем, что мы будем делать.
Мы будем адаптироваться. Мы будем приоритезировать одну функциональность против другой, и тест-подход это компенсирует. И это делает наше тестирование уникальным.
Оно уникально для окружения, в котором мы работаем, для компании, на которую мы работаем, для организации. Оно может различаться в каждом департаменте этой организации и в каждой команде этой организации. А иногда оно различается для каждого члена команды.
Чем более последователен и логичен процесс в Agile, тем лучше он работает. Стоит надеяться, что все члены команды разделяют одно и то же видение проекта, но так бывает не всегда.
Процесс тестирования – не нечто отдельное, живущее параллельной жизнью, не то, что можно отдать на аутсорс и оффшор. Это процесс, тесно связанный с подходом к программированию.
Потому что все это – подход к разработке ПО.
Одна часть этого подхода – программирование.
Другая часть – тестирование.
Они сливаются воедино, создавая эффективный процесс Agile-разработки.
Возможно, в нашем обычном процессе программирования внедрено множество снижающих риск процессов (TDD, ATDD).
Следовательно, подход к тестированию меняется, потому что меняется профилирование рисков.
Риски будут возникать в других местах системы, поэтому мы тестируем иначе, чтобы постараться это учесть.
Хочется верить, что тестировщик может тестировать лучше других; может тестировать иначе, чем другие. И мы хотим соответствующим образом использовать эти навыки в проекте, чтобы тестировщики не тратили свое время, покрывая только базовые критерии приемки.
Потому что практически кто угодно может протестировать на покрытие базовых приемочных критериев.
По мере развития проекта профиль его рисков меняется. Когда проект стартует, мы принимаем высокие риски, потому что мы стараемся создать минимально жизнеспособный продукт, хоть что-нибудь, чтобы обосновать определенные предположения, убедиться, что мы на верном пути, или полностью определиться, чего же хотят наши пользователи. Однако позднее мы хотим сделать наш проект более устойчивым, и не принимаем на себя столько риска, когда системой уже пользуются живые люди.
По мере того, как команда учится работать совместно, происходит передача знаний. Программисты учатся лучше тестировать, так как работают с тестировщиками. Следовательно, количество тестирования, выполненного программистами, со временем меняется. Тестовый подход меняется и адаптируется.
Подход Agile на самом деле ничем фундаментально не отличается от любого другого тестирования. Отличия заключаются в том, что у нас принято ассоциировать тестирование с большим количеством процессов, ловушек, атрибутики. Множеством дополнений.
Эти дополнения – ответ на требования процесса разработки, делающего множество всего заранее. А тестирование очень часто меняется в ответ на требования разработки.
Еще больше тут требуется вербальная коммуникация, дабы брать на себя ответственность за идентификацию рисков и проблем, когда они возникают.
Нам не нужна расширенная документация.
Это не значит, что у нас ее вообще нет.
Попытки что-то записать все еще важны для нас.
Но это не значит, что нам нужен инструмент управления тестированием – мы можем использовать какой угодно инструмент для отслеживания нашего проекта.
Все это – не тестирование.
Нам нужно понимать суть тестирования.
Это очень важно в Agile-процессах: мы делаем нечто постепенно, по ходу пьесы. И это означает, что мы отвечаем на нужды и изменения окружающей среды на основании своего опыта и опыта других людей, на основании того, что происходит в мире, конференций, статей. Мы впитываем все это. Мы экспериментируем. Мы видим, что работает, а что нет.
«Делать что-то по ходу пьесы» звучит так, как будто это что-то плохое. Мы делаем продукт по ходу дела, потому что мы тратим много времени на изучение областей, которые работают, которые связаны со сложными динамическими системами, и учимся у них.
Тестирование никогда не было про тестировщика.
Тестирование всегда было про процессы, которые мы используем, про подход, который мы применяем, и про полученные результаты. И Agile в особенности отвергает подход «тестировщик занимается тестированием».
Agile про то, что тестировать – глагол, процесс в проекте. И если тестировщики держатся за тестирование обеими руками, крича, что «тестируем тут мы», то они не пользуются гибкостью и свободой Agile-проекта.
Нет такого, что вы приходите в Agile, и начинается «ага, это Agile-проект, нам нужна тест-стратегия, на одну страничку, потому что это Agile, а наш процесс в том, что…». Все развивается. Все меняется в зависимости от нужд проекта, навыков людей в команде, динамики существующего набора, и мы ожидаем этих перемен.
Мы можем добиться успеха в Agile через понимание и использование сути тестирования, и этому мы как тестировщики должны научиться. Это та ценность, которую мы даем Agile-проектам – сущность тестирования. И иногда мы – единственные, кто может ее внедрить, пока мы не научим других, как это правильно делается.
Более подробное мнение Алана Ричардсона см. на видео (на английском языке)
Повышение качества с помощью agile-методик тестирования
Необходимость в ручном тестировании по-прежнему существует — но не в том виде, как все привыкли
Просмотр тем
Когда для управления проектом используется каскадная модель, разработка и тестирование осуществляются на двух разных этапах: разработчики создают функцию, а затем передают ее команде по контролю качества для тестирования, самоустраняясь от участия в дальнейшем процессе. Команда по контролю качества составляет и реализует подробные планы тестирования. Она также документирует все дефекты, обнаруженные в ходе тщательной проверки на предмет ухудшений, которые новая работа могла вызвать в существующей функциональности.
Многие команды, применяющие каскадную или другие традиционные модели тестирования, сталкиваются с тем, что по мере развития продукта объем тестирования многократно увеличивается, и отдел по контролю качества вынужден стараться изо всех сил, чтобы не отстать. Владельцы проекта встают перед тяжелым выбором: перенести релиз на более позднюю дату или сэкономить на тестировании (попробуйте угадать с первого раза, какой из этих вариантов выбирают в 99 % случаев). А тем временем разработчики начинают заниматься другими делами. При этом не только растет технический долг, но и для устранения каждого дефекта требуется дорогостоящее переключение контекста между двумя фрагментами базы кода. Положение усугубляется.
Как на беду, заработная плата команды по контролю качества обычно зависит от количества обнаруженных ошибок, из-за чего разработчики вынуждены занимать оборонительную позицию. Неужели нельзя найти для разработчиков и отдела по контролю качества способ уменьшить количество ошибок в коде и одновременно избавить владельцев проекта от мучительного выбора? Не позволит ли это создавать более качественное во всех отношениях ПО?
Отказ от традиционных способов тестирования в пользу agile
Команды Agile и DevOps стремятся наладить стабильную поставку новых функций высокого качества. Однако традиционные методики тестирования попросту не вписываются в принципы Agile или DevOps. Высокие темпы разработки требуют нового подхода к обеспечению качества каждой сборки. В компании Atlassian тестирование проводится по принципам Agile. Все тонкости нашего подхода к тестированию раскроет Пенни Уайетт — руководитель команды по контролю качества Jira Software.
Технический долг, как задолженность по кредитной карте, растущая с процентами, поначалу ощущается как небольшая заноза, но затем быстро приобретает пугающие масштабы и сковывает действия команды, не позволяя ей следовать принципам agile. Чтобы справиться с быстрорастущим техническим долгом, мы в компании даем разработчикам возможность быть главными специалистами по качеству (более того, мы ожидаем этого от них). Мы уверены, что разработчики обладают принципиально важными навыками для обеспечения качества продукта.
По нашему мнению, для каждой пользовательской истории в бэклоге нужно писать код дважды: код самой функции и код автоматического теста. В некоторых командах код функции пишут разработчики, а кодом автоматических тестов занимается специальная команда, но мы считаем, что гораздо эффективнее, когда оба вида кода пишет один специалист.
Баги в новых функциях и ухудшения в существующих следует воспринимать по-разному. Если баг обнаруживается во время разработки, выделите время, чтобы понять, в чем проблема, устраните ее и продолжайте работу. Если обнаруживается ухудшение (т. е. проблема возникла в той функциональности, которая раньше работала нормально), то оно, скорее всего, проявится снова. Разработайте автоматический тест, который предотвратил бы это ухудшение в будущем.
Из этого подхода не следует, что разработчики должны работать сами. Важно, чтобы в команде были и специалисты по контролю качества. Они видят разработку функции с другой стороны, и их мнение важно. Хорошие специалисты по контролю качества знают, где обычно скрываются баги, и могут предупредить разработчиков о подводных камнях.
Вмешательство человека через глубокое тестирование
В нашей компании разработчики вместе со специалистами по контролю качества проводят глубокое тестирование — полезную практику, применяемую при разработке, для отсеивания более серьезных багов. Как и при проверке кода, при глубоком тестировании в команде разработчиков происходит обмен знаниями, полученными в ходе него. У разработчиков развиваются навыки тестировщиков, благодаря чему они изначально поставляют код более высокого качества.
Можно подумать, что глубокое тестирование — это ручное тестирование, но на самом деле нет. Во всяком случае, это не то же самое, что ручное регрессионное тестирование. Для глубокого тестирования используется подход, основанный на оценке риска, и критическое мышление. Тестировщик может использовать свое знание рисков, особенностей реализации и потребностей клиентов, и на ранних стадиях тестирования эта возможность позволяет разработчику или специалисту по контролю качества быстро и системно находить проблемы без помощи тестовых сценариев, обстоятельных планов тестирования или требований. Нам этот подход кажется эффективнее традиционного ручного тестирования, поскольку мы применяем выводы, сделанные в ходе сеансов глубокого тестирования, к исходному коду и автоматическим тестам. При глубоком тестировании мы также получаем опыт использования новой функции, который нам не дает тестирование по сценарию.
Для поддержания качества на постоянном уровне нужно сочетать глубокое и автоматическое тестирование. Глубокое тестирование позволяет обеспечить более полное соответствие кода разрабатываемых функций требованиям к качеству, нежели автоматические тесты сами по себе. Если автоматические тесты просто делают разрабатываемую функцию более стабильной, благодаря глубокому тестированию повышаются удобство ее использования и ее практическая ценность в целом, а также улучшается визуальное исполнение.
Изменения могут оказаться непростыми — очень непростыми
В заключение хочу рассказать историю из жизни, которая прекрасно обобщает весь мой опыт agile-тестирования. Когда-то на заре карьеры я руководил командой разработчиков, которые были решительно против написания автоматических тестов, потому что «этим занимается команда по контролю качества». В течение нескольких итераций на выходе мы получали код с кучей багов, и в какой-то момент я понял, что сыт по горло рассказами о негативном влиянии автоматического тестирования на скорость работы команды. Я занял принципиальную позицию: отныне весь новый код должен проверяться с помощью автоматических тестов.
Уже после первой итерации качество кода повысилось. И разработчик, который больше всех противился тестовым сценариям, первым бросился исправлять ошибку, когда та была обнаружена в ходе тестирования! В следующих итерациях были составлены новые автоматические тесты, была расширена поддержка браузеров и улучшилась наша культура разработки. Да, для выпуска функции пришлось потратить больше времени. Но количество ошибок и объем доработок резко снизился, и в результате мы сэкономили уйму времени.
Изменения очень редко происходят легко. Но, как и в случае со многими стоящими вещами, если приложить усилия и начать работать по новой модели, на выходе останется только вопрос: «Почему мы не сделали это раньше?!»
Сертификация ISTQB – современные стандарты качества и тестирования в Agile-командах
Тестирование тестированию рознь. Кто-то продолжает тыкать палкой в продукт, кто-то смог автоматизировать максимальное количество тестов. Некоторым удалось познать дзен и двигаться к балансу в процессе управления качеством. Так, в Сбере подход к тестированию уже давно изменился. Это не просто инструменты и автоматизация. Это изменение парадигмы. В команде, в которой мне посчастливилось работать уже 5-й год, мы нашли для себя инструменты, которые позволяют использовать тестирование максимально эффективно, разложить всё по полочкам, осознать зависимости и последовательности. И вот с этими инструментами я хочу вас познакомить. Надеюсь, что материал поможет вам проложить верный курс в океане информации.
Если вы профессионально занимаетесь тестированием (тестировщик, специалист по обеспечению качества, эксперт по автоматизации тестирования или разработчик, тестирующий собственный код), то вы знаете, что тестирование – это сложно. Необходимо обладать широким техническим кругозором, оглядываться на собственный опыт, коллег, друзей-тестеров, проекты в которых довелось постигать тестирование. Но стоит заметить, что общие практики тестирования, применяемые годами, очень устарели. Порой создаётся впечатление, что мы, тестировщики, застряли в 80-х, в то время как разработчики уже ушли на десятки лет вперёд. Необходимо пересмотреть существующие практики в ответ на изменения в подходах создания продуктов. Сертификация ISTQB направлена на развитие общих практик управления качеством до лучшего уровня.
Если вы начинающий тестировщик, на собеседованиях вы могли сталкиваться с абсолютно разными интерпретациями и определениями понятия «качество». А если анализировали программы платных курсов, то наверняка пришли к выводу, что месяцами вы будете тестировать сайты-заглушки с парой форм для ввода. И вот с таким практическим опытом вам надо будет идти в реальные проекты, которые не похожи на то, к чему вы готовились. Если вы пришли из agile-команды, где на самом деле был классический waterfall с 2-недельным циклом релизов, а сейчас вам необходимо стать функциональным тестировщиком-автоматизатором, то вы вообще не знаете, как подступиться и с чего начать. Как раз в таких ситуациях может помочь ISTQB с полезными учебными материалами и возможностью пройти официальную сертификацию.
Тут сразу следует отметить – сертификация необязательна, если вы относитесь к той половине, которая считает, что можно быть специалистом и отлично делать свою работу и без официального сертификата. Но есть и те, кому сертификат может реально помочь в получении допуска к интересным и сложным задачам. Лично для меня сертификация открыла двери в несколько интересных проектов. Работая на аутсорсе, я мог получить интересные предложения только при наличии базовой сертификации для тестера – ISTQB The Certified Tester Foundation Level in Software Testing.
The International Software Testing Qualification Board (ISTQB) – это некоммерческая организация, основанная в 2002 году. На июль 2021 ISTQB проведено 1 065 000 экзаменов и выдано более 774 000 сертификатов в 129 странах по всему миру. Программа сертификации ISTQB является авторизованной, то есть официальной – за ней стоят люди, которые создают, администрируют и проводят экзамены.
ISTQB предлагает тестировщикам выбрать свои векторы в предложенной 3-уровневой схеме сертификации.
Начиналось всё с фундаментального (базового) уровня. Потом добавились продвинутый и экспертный уровни, которые объединились в core-вектор. Помимо этого, базовый уровень позволяет переключиться на развитие вектора для специалистов, если вы хотели бы углубиться в специализацию (нагрузочное тестирование, тестирование мобильных приложений или юзабилити-тестирование).
Источник: ISTQB Product Portfolio
Недавно, отвечая вызовам текущего времени, ISTQB открыла новый вектор «agile tester». Сейчас он находится в активной разработке и наполняется лучшими материалами и практиками, пользу которых оценят не только тестеры, но и все, кто участвует/вовлечён в создание продукта.
Вектор «agile tester» начал развиваться после осознания того, что существующие сертификации не покрывают требования, предъявляемые к современному тестировщику. Их фокус прежде всего направлен на «классическое тестирование», к которому многие привыкли ещё с прошлого века. Его основные этапы включают планирование тестирования, написание тест-кейсов (пожалуй, прогресс в том, что сейчас используется современный инструментарий – HP ALM, Adaptavist и т. п.), ручное выполнение тестов, создание отчётов и оценку, чтобы понять, нужно ли нам продолжать тестирование.
Такой процесс может быть запущен одновременно с проектом, но часто он не является частью разработки, а существует параллельно. При agile-разработке, которая становится популярнее из года в год, тестирование становится естественной частью agile-проекта, а не просто этапом между «разработчики написали код» и «клиенты получают свой продукт».
Соотвественно профиль современного тестировщика, который работает в agile-командах, отличается от профиля классического тестировщика. Современный тестировщик сегодня – это инженер, который разбирается и увлечён как разработкой, так и тестированием. Он способен помочь разработчикам найти ошибку как можно раньше, а не просто зафиксировать, что проблема существует.
Новые методологии (Agile, Lean, Scrum, Kanban), а также работа в маленьких многопрофильных командах популярны и применимы сейчас не только в области стартапов. В современном быстро меняющемся мире любая компания должна становиться более адаптивной, итеративной и гибкой.
Существующие модули ISTQB Foundation Level и Foundation Level Agile Tester помогают развить навыки, которые нужны для работы в командах, где применяются гибкие подходы.
По мере роста популярности agile-разработки стало очевидно, что для создания масштабных и сложных систем требуется сотрудничество нескольких команд. Поэтому были созданы новые и адаптированы существующие фреймворки для масштабирования agile в одиночных командах до нескольких групп и более. Например, Scaled Agile Framework (SAF), LeSS (Large-Scale Scrum), Scaling Lean.
Смена фокуса внимания с одиночных agile-команд на несколько групп, трайбов, блоков, которые реализуют один продукт, услугу и создают ценность называется «гибкость в масштабе (agile at scale)» или «масштабируемая гибкость (scaled agile)». Всё это приводит к тому, что подходы к тестированию тоже требуют масштабирования. ISTQB предлагает сертификацию продвинутого уровня, которая поможет специалистам развить компетенции, необходимые для эффективной работы и сотрудничества в таких требовательных условиях – Agile Test Leadership at Scale (ATLaS).
Несмотря на то, что полный объём материалов в модуле ещё не готов, уже сейчас опубликованы две главы для изучения. Ознакомиться с ними можно здесь. А для тех, кому поможет краткий обзор материалов, предлагаю summary по двум главам.
Chapter One
Основная цель любой коммерческой организации – получение прибыли. Это не секрет. И достигается прибыль через создание ценности, продуктов, предоставление услуг для клиента. Для того чтобы повысить ценность создаваемых продуктов и услуг, в материалах ISTQB предлагают прийти к осознанию ценностно-ориентированной организации (Values-driven organizations), где одной из ключевых операционных моделей управления является бизнес-гибкость (Business Agility). Это модель управления, где в центре находится клиент. Все решения, которые принимает компания, направлены на то, чтобы клиент был доволен. Повысить клиентоориентированность можно за счёт применения современных подходов, дисциплин и методологий (например: agile, lean и DevOps, SAF), через непрерывное преобразование, рост культуры и изменение образа мышления.
Важно в этом процессе уделять особое внимание понятию «качество», которое должно расти и меняться. Каждый, кто участвует в процессе создания ценности, продукта и услуг, начинает нести ответственность за качество. Для организации становится важным работать над распространением знаний о качестве в масштабах всей организации по горизонтали современными и гибкими способами.
В принципе, с этого материалы и начинаются. Первая глава посвящена современным требованиям к гибкости в бизнесе, возникающей необходимости в повышении качества выполняемых задач. Этого невозможно достичь, если возложить ответственность за качество на одиночные команды или людей с конкретными функциями (тестировщик).
Тестирование превращается в контроль качества, а это означает, что компаниям необходимо внедрять помощь/поддержку по качеству (quality assistance) во всей структуре, включая команды по реализации проекта.
Это меняет роль специалистов по обеспечению качества и тестировщиков, приближая её к управлению гибким тестированием, а также способствует развитию культуры качества и мышления. В Сбере показатели, относящиеся к контролю качества, фиксируются автоматически на большей части этапов и интегрированы в метрики каждой команды.
Отдельно рассматривается продвижение ценностно-ориентированного образа мышления и культуры контроля качества, описываются подходы и навыки quality assistance. Важно, что приводятся примеры навыков коучинга, профессиональной подготовки и управления процессами преобразования, необходимыми для привнесения в организацию quality assistance. Дополнительно рассматриваются уже существующие проблемы, связанные с качеством, чтобы проиллюстрировать, как quality assistance использует комбинацию навыков для решения поставленных задач.
Chapter two
Улучшение качества и рабочего потока создания ценности (value stream) в компании, придерживающейся ценностно-ориентированного мышления – вот основной стрим во второй главе. Рассматривается Value Stream Mapping (систематизирование потока ценности) с описанием навыков, которые понадобятся для применения этой техники. Одной из первых её представила и начала использовать Toyota, после чего многие в мире начали применять такой подход. Принципы производственного процесса Toyota реализованы в Сбере во всех процессах, в том числе в IT.
Сертификация поддерживает внедрение Value Stream Mapping в качестве ключевого инструмента для улучшения производительности и, как следствие, качества продукта или услуги. Анализ потоков ценности (value stream) исследуется с точки зрения качества и тестирования.
Рассматриваются базовые методы визуализации, типичные этапы систематизации потока ценности (value stream), способы выявления деятельности, не несущей дополнительной ценности, в виде 8 различных видов потерь. В принципе, можно научиться приносить пользу благодаря:
выявлению и удалению потерь;
повышению эффективности процессов, ориентированных на создание ценностей, услуг, продуктов;
сосредоточенности кросс-функциональных команд на бизнес-целях и удовлетворённости клиентов.
Резюме
Сертификация Agile Test Leadership at Scale направлена на тех, кто работает в компании, стремящейся к масштабированию agile-подходов в работе, где уже есть базовое понимание agile. Но также она будет интересна всем, кто хочет разобраться в современных подходах управления и способах обеспечения качества. Запуская сертификацию по главам, ISTQB ожидает ранней обратной связи от всех, кто занимается управлением, обеспечением качества и может помочь адаптировать сертификацию в соответствии с требованиями рынка.
Если вы хотите идти в ногу со временем в контексте управления качеством при создании современных клиентоориентированных продуктов, то будет полезно изучить материалы в первоисточнике.
По мере публикации новых глав мы обязательно будем рассказывать вам о них.