Что такое agile тестирование
Agile Testing
Введение в Agile Тестирование
Принципы гибкого тестирования
1. Непрерывный: он обеспечивает обратную связь на постоянной основе, на постоянной основе, поэтому продукты отвечают потребностям бизнеса.
2. Командная работа. В другом программном обеспечении за тестирование отвечает группа тестирования, но в гибком тестировании, наряду с группой тестирования, разработчики и бизнес-аналитики в равной степени участвуют в тестировании.
3. Время отклика обратной связи: поскольку бизнес-команда участвует в гибком тестировании, обратная связь является быстрой и непрерывной, поэтому время отклика очень короткое.
4. Чистый и упрощенный код: дефекты, обнаруженные гибкой командой, исправляются в одной и той же итерации, и, следовательно, код остается чистым и упрощенным.
5. Проведение тестов: здесь тестирование проводится во время реализации, тогда как в других процессах тестирование выполняется после внедрения.
6. Легкие документы: Agile-тестеры используют многоразовые контрольные списки, чтобы выбрать тесты, которые необходимо сдать. Документы могут использоваться для нескольких целей, и инструменты также являются легкими.
7. Разработка через тестирование : здесь разработка основана на тестировании. Тестовые случаи написаны в соответствии с требованиями, поэтому этот подход называется Test Driven Development (TDD). В ПО для тестирования Waterfall тестирование проводится на последнем этапе.
Значения гибкого тестирования
Любые необходимые изменения принимаются и применяются. Хотя проект следует плану, он легко изменяется всякий раз, когда меняется ситуация. Таким образом, не нужно ждать до конца, чтобы узнать об изменившемся сценарии и закрыть проект из-за изменившегося требования.
Методы гибкого тестирования
Существуют различные гибкие методы тестирования, такие как:
1. Поведенческое развитие (BDD).
Поведение, управляемое поведением, улучшает общение, так что все участники понимают каждую функцию до начала процесса. Разработчики, аналитики и тестеры находятся в постоянном общении.
2. Acceptance Test Driven Development (ATDD).
3. Разведочные испытания.
При таком тестировании дизайн теста и его выполнение идут рука об руку. Акцент делается на работу программного обеспечения над документацией. Люди и общение важнее, чем процесс и инструменты. Поисковые тесты более приспособлены к изменениям. Планы испытаний разрабатываются и выполняются в соответствии с выводами тестеров.
План испытаний
В гибком тестировании план тестирования пишется и обновляется каждый раз. Это включает:
Фазы гибкого тестирования жизненного цикла
Существует 5 этапов жизненного цикла тестирования 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 ожидает ранней обратной связи от всех, кто занимается управлением, обеспечением качества и может помочь адаптировать сертификацию в соответствии с требованиями рынка.
Если вы хотите идти в ногу со временем в контексте управления качеством при создании современных клиентоориентированных продуктов, то будет полезно изучить материалы в первоисточнике.
По мере публикации новых глав мы обязательно будем рассказывать вам о них.
Как мы внедряли Agile-testing
Привет! Меня зовут Алёна Исакова, я ведущий тестировщик в Авито, и я хочу рассказать вам про свой опыт введения Agile-тестирования в команду. Когда я читала доступные на русском языке статьи про Agile-тестирование и ATDD, у меня сложилось впечатление, что я «не модная», «не по Agile». Казалось, что это некая сложная структура, которая требует включения разработчиков, и до её применения мне ещё «пахать и пахать».
Какое-то время я жила с этой мыслью, писала в задачи чек-лист проверок при постановке, собирала встречи «feature-team», на которую приглашались PM, QA, Frontend и Backend для обсуждения нюансов задачи до начала реализации.
Те, кто понимает о чем речь, уже заметили подвох, не правда ли?
Если погуглить, что такое «Agile testing», то можно встретить предложения по прохождению курсов, парочку статей со взглядами на подход и определение на Википедии:
«Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example is used to capture examples of desired and undesired behavior and guide coding».
Не знаю как вы, но я не дочитала это определение с первого раза, на меня напала тоска. На самом деле всё не так сухо. Суть в том, что Agile testing — это такой подход к процессу тестирования, при котором тестировщик гораздо больше участвует на первых этапах проработки задачи и меньше (либо совсем отсутствует) на последних, в отличие от подхода Waterfall.
Kак был устроен наш флоу работы с задачами
Стоит сказать, что изначально наша команда работала по трушному SCRUM’у, простите за выражение, что заведомо хорошо совмещается с Agile-тестированием, можно сказать, подразумевает его.
1. Постановка от заказчика (предположим, ПМ)
На данном этапе постановка задачи у нас проходила по схеме User Story, Acceptance criterias, Use case. Такая, заведомо Agile, постановка не случайна — это заслуга моей коллеги по юниту, которая уже вводила Agile-тестирование в своей команде. Почему у меня не получилось просто позаимствовать опыт соседней команды, расскажу ниже в статье.
2. Ревью постановки задачи тестировщиком
На этом этапе задача проверялась на однозначность, непротиворечивость и полноценность. В моем случае я ещё добавляла сюда же пункт «tests», в котором описывала дополнительные тест-кейсы (например, негативные), которые по формату было неуместно писать в Use case. На тот момент я не полностью осознавала, как пользоваться Acceptance criterias, поэтому просто старалась давать разработчику максимальные вводные по моим будущим проверкам.
3. Обсуждение задачи всеми заинтересованными или «feature-team»
Этап выполнялся по необходимости. Если после ревью тестировщик решал, что задача понятна и дополнительные обсуждения не требуются, переходили к четвертому пункту.
Если этап был необходим, то на встрече вносилась ясность по требованиям, дополнительным работам. Часто задача декомпозировалась, обсуждались условия тестирования при независимой работе фронтенда и бэкенда.
4. Задача следовала в бэклог, планировалась, выполнялась, выкатывалась и приносила пользу и счастье
Кажется, всё не так уж и плохо, но есть и что улучшить: как минимум, можно убрать пару лишних этапов, раз уж мы не понимаем зачем они.
Что сделали, чтобы улучшить
Испытывая неутолимое желание улучшать, мы с разработчиком прошли внутренний мастер-класс по Agile-тестированию. Оказалось, что для полного соответствия подходу команде надо лишь изменить терминологию и немного подкрутить винтики нашего кастомного велосипеда.
Ввести подход, наблюдая за командами, в которых он уже есть, недостаточно, необходим блок знаний и этап осознания, который в моём случае дал мастер-класс. Огромным плюсом послужило то, что мы прошли обучение вместе с разработчиком, что я всем настоятельно советую, его помощь сложно переоценить. Вы двое (тестировщик и разработчик) — необходимый и достаточный минимум для начала реализации подхода. Помимо этого, каждая команда и продукт индивидуальны, чтобы подточить этот метод под себя, необходимо, как минимум, попробовать.
Например, в соседней команде есть опыт полезного применения Unit-тестов с предварительным описанием в инструменте для хранения тест-кейсов и последующей автоматизацией. Наша команда решила сначала определять нужную проверку концептуально, автоматизировать, а уже после автоматически забирать кейсы из кода в инструмент для хранения. У вас, возможно, родится свой способ взаимодействия.
Я не заявляю, что без особого мероприятия нельзя ввести подход, ни в коем случае. Но необходимо выделить время для понимания, замотивировать команду и начать менять и меняться. Будьте готовы, что не все сразу примут увеличение времени проработки задачи с распростертыми объятиями, мне в этом плане повезло.
Что почитать на эту тему
«Agile-тестирование. Обучающий курс для всей команды», Джанет Грегори и Лайза Криспин. Книга недавно вышла в русском переводе и доступна на Озоне.
Что конкретно изменилось
С какими сложностями столкнулись
1. Что есть юнит тест
Мы столкнулись с тем, что мы, QA, не понимаем что именно проверяют unit-тесты и поэтому не доверяем им, а в дань нашей бдительности пишем тесты уровнем выше и стучим каблуком «автоматизировать, нельзя помиловать».
Как решили:
Мы с нашим просвещенным в Agile разработчиком (слава ему и его терпению) сели в уголке, и битый час он на пальцах объяснял мне что такое unit-тесты, с чем это едят и почему они не могут проверить ещё «вот эту вот фигулину». В результате наших страданий родилась потрясающая схема сервиса: так нарисовали, что аж сами поняли.
Одна выделенная стрелочка — один поход — одна проверка в unit тесте
В итоге спустя пару месяцев, я сама немного пишу юнит тесты и удаляю избыточные проверки на верхних уровнях. Это, конечно, в основном, копипаст, но осознанный!
Возможно, вы уже хорошо понимаете суть unit-тестов и вам не придется тратить время на этот пункт, но если нет — подкараульте своего разработчика в спокойной обстановке и нападите на него с вопросами.
2. В текущей реализации не все тесты можно опустить без доработок
Как решили:
Убрали лишние датасеты e2e-тестов за счет увеличения количества юнит-тестов.
Уже реализованные unit-тесты мы пересмотрели, расписали, какие проверки мы от них хотим. После этого, довольно ожидаемо, выяснилось, что части проверок нам недостаёт.
Определив, что и на каком уровне хотим, поставили задачи на будущее.
Потренировавшись на том, что уже есть, мы взялись за реальное применение подхода и начали писать проверки на методы, которых еще нет. Это было уже сложнее.
Выводы
Особенность этого подхода в том, что он естественный и растёт из таких вещей, как: «донести ценность до пользователя», «уменьшить ручную работу QA», «обеспечить покрытие». Как именно ты это будешь делать — другое дело, но у этого подхода есть, что тебе предложить и подсказать, какие отмычки применить, чтобы упростить твою жизнь и ничего не потерять.
К примеру, «Практики Agile testing» — это готовые инструменты для применения, а «Ценности» и «Принципы» — это то, что понятно тестировщику здорового человека, но всё же стоит неоднократно проговорить их себе и своей команде, потому что по опыту знаю: они часто отодвигаются на второй план в режиме высокой нагрузки.
Главное в ATDD методологии это то, что прежде, чем что-то делать, надо придумать критерий выполненной работы и критерий того, что работа сделана правильно. Подход, грубо говоря, определяет временной промежуток, на котором вы договариваетесь с командой. Остальное идёт по ходу действия пьесы.
Например, вы осознаете, что в ваших условиях вы не можете выделить интеграционную прослойку тестов — ничего страшного. Начните с первых этапов подхода: напишите критерии приёмки, определите тесты и их уровни, создайте задачу на светлое будущее. Самый полезный этап здесь — это определение проверок заранее, от ваших дотошных вопросов на этапе постановки задачи — самый быстрый позитивный результат, который докажет вашей команде, что вы не зря тратите их время.
Однажды, в разгаре обсуждения, мы с командой поняли, что пишем проверки на слишком уж много условий, и это нас надоумило на вопрос: «А точно ли на тот параметр мы делаем вызов метода?». Оказалось, что постановку задачи можно в корне упростить, вызывать саму сущность, а не логику выше уровнем от неё. То есть условий, когда у нас есть зависимая сущность, но нет самой сущности, не существует. Это упростило нам жизнь.
По тому, как определить уровень тест-кейса — это отдельный холивар, когда начнете ощущать боль, попробуйте обратиться к литературе. И помните, что практику надо применять там, где она действительно решает проблему, где она облегчает жизнь. Всем добра, удачи и котиков!