Всем привет! Я Алена, QA Lead :)
Сегодня я хочу обсудить важную тему, которая касается всех нас в сфере разработки ПО — методология Agile и ее влияние на тестирование. Внедрение Agile произвело революцию в процессе разработки, и тестирование не осталось в стороне. В этой статье я расскажу об основных принципах Agile, как они меняют подход к тестированию и какие преимущества это дает командам.
Надеюсь, эта информация будет полезной и вдохновит вас на внедрение Agile-подходов в свою практику!
Что такое Agile?
Эти принципы привели к появлению различных фреймворков, таких как Scrum, Kanban и Extreme Programming (XP), каждый из которых предлагает уникальные подходы к реализации ценностей Agile.
?Интересный факт: Хотя Agile был формализован в 2001 году, его корни можно проследить до 1950-х годов в обрабатывающей промышленности, в частности, в принципах бережливого производства в Японии.
Влияние Agile на тестирование
Давайте рассмотрим, как Agile изменил подход к тестированию и какие преимущества это принесло.
Тестирование начинается с самых ранних этапов жизненного цикла программного обеспечения. Преимущества: это позволяет выявлять и решать проблемы раньше, сокращая время и затраты.
В Agile тестирование проводится постоянно, параллельно с разработкой. Преимущества: позволяет быстро получать обратную связь и вносить необходимые изменения.
Акцент на автоматизации. Agile-методологии часто используют автоматизированные тесты для повышения эффективности. Преимущества: позволяет быстро выполнять регрессионные тесты и получать обратную связь о работоспособности новых функций.
В Agile все члены команды, включая разработчиков, тестировщиков и бизнес-аналитиков, несут ответственность за качество продукта. Преимущества: это приводит к более тесному сотрудничеству и улучшению качества.
Учитывая ограниченное время в каждом спринте, команды Agile часто применяют подходы к тестированию, основанные на оценке рисков. Преимущества: позволяет командам сосредоточиться на тех аспектах продукта, которые могут вызвать наибольшие проблемы или иметь наиболее серьезные последствия в случае сбоя.
Agile-проекты обычно используют пользовательские истории для определения требований. Тестировщики должны адаптироваться к тестированию на основе этих пользовательских историй, гарантируя, что критерии приемки выполнены.
Мой текущий проект помогает предпринимателям управлять своими финансами, отслеживать проекты и взаимодействовать с клиентами. Мы выбрали методологию Agile, используя Scrum как один из популярных фреймворков.
И вот как мы реализовали процессы на проекте:
-
Планирование и приоритизация спринта.
? Создание бэклога продукта. Сюда включаем общий список функций и улучшений, ранжированных по приоритетам. Например, в верхней части бэклога могут быть такие функции, как создание инвойсов, отслеживание расходов и интеграция с банковскими счетами.
? В начале каждого спринта мы собираемся, чтобы определить, какие задачи будут выполнены в течение этого периода. Команда оценивает сложность каждой задачи и определяет, сколько задач можно выполнить за спринт. QA активно участвуют в обсуждении, помогая уточнить критерии приемки для новых функций.
-
Разработка и тестирование.
?Разработчики регулярно интегрируют свои изменения в основной код, что позволяет быстро обнаруживать и исправлять ошибки.
?В процессе разработки функционала, QA разрабатывает тестовые сценарии, основываясь на требованиях.
?Тестирование проводится на протяжении всего спринта, а не только в конце. Это позволяет быстро выявлять и устранять проблемы.
?Команда QA использует фреймворк для автоматизации тестов (в нашем случае Playwright), что позволяет нам быстро проверять, не нарушены ли существующие функции при добавлении новых.
?Команда проводит ежедневные короткие встречи для обсуждения прогресса, проблем и планирования на день.
?Команда регулярно пересматривает свои планы и приоритеты, чтобы адаптироваться к изменениям в требованиях или рыночных условиях.
-
Обратная связь, улучшения, ретроспектива.
?После завершения спринта команда проводит демо для бизнеса, на котором демонстрируются новые функции. QA может предоставить информацию о найденных дефектах и предложить улучшения на основе обратной связи пользователей. Это позволяет команде адаптировать функционал под реальные потребности клиентов.
?По завершении спринта проводим ретроспективу, где обсуждаем успехи и области для улучшения. QA может предложить оптимизацию процесса тестирования или выявить узкие места, которые затрудняют тестирование.
Проблемы тестирования в Agile
Хотя Agile и дает много преимуществ тестированию, он также создает проблемы.
Динамическая природа Agile требует от тестировщиков способности адаптироваться и владения различными инструментами и методами.
Короткие спринты могут заставить QA быстро завершать свою работу. Для решения проблемы поможет расставление приоритетов в тестировании.
Постоянное сотрудничество может привести к проблемам в общении, если члены команды не согласованы.
Также, когда команды начинают использовать автоматизацию, может возникнуть steep learning curve (то есть, довольно сложный процесс обучения) и потребуются первоначальные вложения в ресурсы.
Частые изменения могут затруднить поддержку тестовых случаев. Для минимизации этой проблемы, тестируйте в первую очередь наиболее рискованные области системы.
В заключении моей статьи хотелось бы сказать, что в условиях быстро меняющегося мира технологий Agile становится необходимостью, а команды, способные адаптироваться и интегрировать тестирование в свою практику, получают конкурентные преимущества на рынке.
Комментарии (17)
OlegZH
17.10.2024 19:57Мой текущий проект помогает предпринимателям управлять своими финансами, отслеживать проекты и взаимодействовать с клиентами.
А Вы можете поточнее определить, что именно значит "управлять своими финансами", как здесь возникают "проекты" и кто такие "клиенты"?
Традиционная разработка начинается с определения сущностей и отношений между ними. Было бы неплохо, сначала, увидеть, как выглядит такая схема в начале пути, и во что она превращается в конце пути.
Ключевой и самые главный вопрос: можно ли каким-нибудь (волшебным?) способом сразу получить конечную схему?
OlegZH
17.10.2024 19:57Создание бэклога продукта. Сюда включаем общий список функций и улучшений, ранжированных по приоритетам. Например, в верхней части бэклога могут быть такие функции, как создание инвойсов, отслеживание расходов и интеграция с банковскими счетами.
Разработка программного продукта по описываемой схеме, по своей сути, превращается в очень случайный процесс, когда поток реализации никак не упорядочен, а локальные "улучшения" могут оборачиваться глобальными ухудшениями.
OlegZH
17.10.2024 19:57В начале каждого спринта мы собираемся, чтобы определить, какие задачи будут выполнены в течение этого периода. Команда оценивает сложность каждой задачи и определяет, сколько задач можно выполнить за спринт. QA активно участвуют в обсуждении, помогая уточнить критерии приемки для новых функций.
Практически дословное воспроизведение алгоритма работы порождающей языковой модели! Отсюда становится понятным успех применения таких моделей. Это же — общепринятая практика!
OlegZH
17.10.2024 19:57Разработчики регулярно интегрируют свои изменения в основной код, что позволяет быстро обнаруживать и исправлять ошибки.
Как можно что-то просто так интегрировать в основной код? Опять же, здесь очень не хватает сравнительного анализа: вот мы здесь исправили локальные ошибки, но, зато потом столкнулись с ошибками в другом месте и потом долго ковырялись и выяснили, что дело было в ранних и, вроде бы, уже проверенных изменениях.
На самом деле, всё это — яркий пример отсутствия какой-либо теории проектирования. Была бы теория, мы бы знали, какие изменения являются допустимыми, и с каждым допустимыми изменением была бы связана своя оценка риска, учитывающего взаимосвязи компонентов. Кстати, это говорит ещё и о необходимости некоторого над-уровня разработки, когда организуются поток изменений в определённом направлении, при этом, обязательно должны быть свои инварианты.
OlegZH
17.10.2024 19:57В процессе разработки функционала, QA разрабатывает тестовые сценарии, основываясь на требованиях.
Волга впадает в Каспийское море. Без примеров никак?
OlegZH
17.10.2024 19:57Тестирование проводится на протяжении всего спринта, а не только в конце. Это позволяет быстро выявлять и устранять проблемы.
Безграничное тестирование! Когда же мы пишем код?
Я не спорю. Вполне возможно, так и нужно действовать, постоянно что-то тестировать, то есть — проверять. Тут бы и хотелось бы услышать, какие бывают тесты, что именно тестируется, каковы сценарии тестирования? И кто-нибудь тестировал тестирование?
OlegZH
17.10.2024 19:57Команда QA использует фреймворк для автоматизации тестов (в нашем случае Playwright), что позволяет нам быстро проверять, не нарушены ли существующие функции при добавлении новых.
Как он это делает? Он это делает лучше, чем другие? И кто такие другие?
OlegZH
17.10.2024 19:57Команда проводит ежедневные короткие встречи для обсуждения прогресса, проблем и планирования на день.
Так часто? И какую отдачу это даёт?
OlegZH
17.10.2024 19:57Команда регулярно пересматривает свои планы и приоритеты, чтобы адаптироваться к изменениям в требованиях или рыночных условиях.
Здесь очень хорошо пригодился бы реальный пример пересмотра планов. Вот, шли-шли, а потом пошли в другом направлении? И как это выглядит?
OlegZH
17.10.2024 19:57После завершения спринта команда проводит демо для бизнеса, на котором демонстрируются новые функции. QA может предоставить информацию о найденных дефектах и предложить улучшения на основе обратной связи пользователей. Это позволяет команде адаптировать функционал под реальные потребности клиентов.
А можно дать в руки заказчику некое ПО (типа конструктора), чтобы он сам всё описал? Несбыточная мечта? Маниловщина? (Языковые модели будут здесь, как раз, очень кстати. К этому всё и идёт?)
combo_str
17.10.2024 19:57Просто интересно, какого размера ваша команда? Вся команда разработки имеется в виду, т.е. вместе с BA, BI и т.д.
Что вы делаете, если фича подразумевает ооочень обширную функциональность и никак не влезает в спринт и при этом не может быть разбита на части, которые в каком-то конечном виде можно доставить юзеру?
Уклон в автоматизацию ну никак не подразумевает agile, ну и наоборот. Можно упарываться по автотестам и на ватерфлоу, никаких помех)
Подсказал бы кто, что делать с огромным количеством старых багов, тех. долгом и т.п.( В бэклог нумер2 сложить чтоль?))
OlegZH
17.10.2024 19:57По завершении спринта проводим ретроспективу, где обсуждаем успехи и области для улучшения. QA может предложить оптимизацию процесса тестирования или выявить узкие места, которые затрудняют тестирование.
Беда в том, что, когда одна команда разработчиков выявила узкие места и добралась до финиша, другая команда в другом месте начинает свои "круги ада", и как-то не удаётся тиражировать положительный опыт.
OlegZH
17.10.2024 19:57... в условиях быстро меняющегося мира технологий ...
А в чём, собственно, заключается это изменение? Задачи, ведь, как это представляется на первый взгляд, остаются теми же самыми. Что же меняется? Почему нельзя один раз получить удовлетворительное решение и, потом, растиражировать его?
RodionGork
17.10.2024 19:57Не серчайте, тема действительно глубокая т.к. у тестирования в "гибких методологиях" немало интересных нюансов и проблем возникает - но данная статья совершенно куда-то ушла от возможно обсуждения этих нюансов в какой-то популизм. Посмотрите на фразы ниже - неужели все эти три достоинства например стали возможны только благодаря Agile? Неужели без Agile нельзя начать тестировать "с ранних этапов" (TDD вообще предполагает тестирование до разработки не так ли)? Или может без Agile тестирование не проводится постоянно и все QA просто сидят без дела? И что, автоматизация без Agile не работает?
Давайте рассмотрим, как Agile изменил подход к тестированию и какие преимущества это принесло.
Тестирование начинается с самых ранних этапов жизненного цикла программного обеспечения. Преимущества: это позволяет выявлять и решать проблемы раньше, сокращая время и затраты.
В Agile тестирование проводится постоянно, параллельно с разработкой. Преимущества: позволяет быстро получать обратную связь и вносить необходимые изменения.
Акцент на автоматизации. Agile-методологии часто используют автоматизированные тесты для повышения эффективности. Преимущества: позволяет быстро выполнять регрессионные тесты и получать обратную связь о работоспособности новых функций.
В то же время пример достаточно серьёзных обсуждений - возьмите тестирование в Scrum - зададимся вопросом, когда спринт только начался и выполненных тасок ещё нет - что же будут тестировать тестировщики? А если они возвращают таски на доработку, как соразмерять капасити на их выполнение? Нужно ли что-то переносить в следующий спринт и так далее. Короче там из тестирования вылезает гора вопросов по которым проводятся всяческие семинары серьёзными людьми из крупных контор. Имеет смысл поискать подобные дискуссии - это немало обогатит горизонт познаний по проблеме.
HarleyKaos
17.10.2024 19:57Цеттатто: " Хотя Agile и дает много преимуществ тестированию, он также создает проблемы. "
Постоянный стресс команды из-за бесконечных спринтов и дедлайнов, приводящий к быстрому "выгоранию" членов команды
Сама философия Agile подразумевает главенство заказчика над разработчиком, вследствие чего на разработчика всем плевать ,и "давай-давай, шевелись" становится главной движущей силой проекта
Бесконечные митинги и созвоны сильно отвлекают от процесса создания кода, вследствие чего тратится слишком много времени на бессмысленную болтовню.
Waterfall со всех сторон лучше, поступило предложение вернуться к истокам.
OlegZH
Мне тут, как-то, уже намекнули на то, что все уже перешли на Agile, а всё остальное — устарело. Давайте, посмотрим...
Ценностей, говорите? В чём же эти ценности заключаются?
Подождите! А какие подходы были до того как?
1.1 А какие, вообще, есть этапы жизненного цикла?
1.2 Я предполагаю, что классический подход заключается в том, чтобы сначала полностью спроектировать целую систему, и садиться за кодирование/программирование строго послед того, как проектирование полностью завершено. Правильно ли я понимаю, что Agile допускает написание кода (и последующее его тестирование) на самых ранних этапах?
1.3. Стоп! А разве этап проектирования не заключается в том, что мы выявляем проблемы и, когда они выявлены, мы предлагаем их решение? Мне всегда казалось, что проектирование в этом и заключается, чтобы, сначала, ответить на вопрос, что мы хотим сделать, и, потом, на вопрос, как мы хотим это сделать. Ответ на вопрос как и показывает, что у разных вариантов реализации будут и разные проблемы.
2.1 С точки зрения системного подхода и анализа, и, вообще, традиционного подхода, здесь идёт речь о тестировании вербальных моделей. Если представить процесс создания системы, то, сначала, мы описываем функции и процедуры и, постепенно, уточняя детали, тестируем их на непротиворечивость. Разница здесь заключается в том, что в Agile начинают рано писать код, но что такое проектирование как ни литературное программирование?!
3.1 Чем же традиционный подход отличается от Agile? Можем обратиться к языковой модели и получить на выходе... Кстати, а что мы получим?
3.2 Неужели всё сводится к одним только тестам? Может быть, существует другой подход к построению качественного программного кода? Например, доказательное программирование? Можно представить себе работу проектировщика, как оператора базы данных. Только, в БД хранятся не данные, а код. Оператор заполняет БД сведениями, описывающими проектируемую систему и проверяет условия целостности. Как только получено полное и непротиворечивое описание (спецификацию), то можно будет передать такую базу программистам, а те изготовят конкретное изделие по спецификации. (Или это сделает языковая модель.)
3.3 Что такое "регрессионные тесты"? Это имеет отношение к доказательному программированию?
4.1 В чём же заключается ответственность?
4.2 Качество продукта зависит от квалификации сотрудников. Либо она есть, либо её нет (и тогда никакая ответственность не поможет). Если заказчик приходит с новыми "хотелками", то бизнес-аналитики плохо поработали. Здесь бы понять, почему пришёл заказчик...
4.3 Получается, что большую часть рабочего времени люди заняты исправлением своих "недодумок". Может быть, следует семь раз подумать, а уже потом начать "кодить"?
5.1 Откуда мы (у)знаем, что вызывает/вызовет наибольшие проблемы? Кто-нибудь анализировал реальные примеры разработки? кто-нибудь сопоставлял ожидания и реальность?
6.1 Пользовательские истории — это, конечно же, очень хорошо. Но у любой деятельности есть свои цели, процедуры и регламентам. Формализация всего этого приводит к чётким протоколам. Другими словами, нужно изначально иметь достаточно полное покрытие пользовательскими историями, а уже потом, доказав полноту, что-то делать дальше.