5 + 1 частых ошибок в тестировании в Agile-командах

Введение

За свою карьеру я неоднократно видела ситуации, когда команда называет себя Agile, но в их тестировании нет ничего гибкого. Вся команда уже внедрила Scrum или Kanban, процесс гибко перестраивается (или старается перестраиваться) под меняющиеся требования, а тестирование остается строго линейным и традиционным.

Тестировщики подключаются только на финальных этапах разработки, процессы автоматизации отсутствуют, а регрессионное тестирование откладывается на самый последний момент, когда до релиза осталось пару часов.

Как итог, вся гибкость разработки пропадает именно в тот момент, когда нужно максимально ускоряться — перед релизом.

Подобное несоответствие не только снижает скорость выпуска продукта, но и подрывает саму суть Agile. Ведь когда мы говорим об Agile, на первый план выходят гибкость и скорость, и если тестирование является бутылочным горлышком в процессах, то команда теряет значительную часть своей эффективности.

В своей статье я расскажу о 5 + 1 наиболее распространенных ошибках в Agile Testing, которые я встречала и продолжаю встречать в командах. Ошибки, которые мешают стать вашим командам гибкими и быстрыми. Я поделюсь алгоритмами, как избежать ловушек и что делать, если ваша команда уже попала в них.

Эта статья будет полезна Agile-коучам и Scrum-мастерам, которые ищут способы улучшить процессы обеспечения качества в своих командах, а также начинающим QA-инженерам, стремящимся внедрить больше гибкости в работу и использовать эффективные инструменты для повышения качества продукта.

Ошибка 1: Начинать тестирование слишком поздно

К чему приводит:

Отложенное до финальных этапов разработки тестирование существенно увеличивает риск обнаружения багов на поздних стадиях, когда их исправление становится сложным и дорогостоящим. Исправление ошибок на этом этапе требует значительных ресурсов, что часто приводит к задержкам релизов и перераспределению времени и усилий команды. Кроме того, существует высокая вероятность того, что серьёзные дефекты останутся незамеченными и попадут в прод, это может негативно сказаться на качестве продукта, пользовательском опыте и репутации продукта.

Как чинить 1:

Внедрите практику Shift-Left Testing – подход предполагает, что тестирование всегда должно начинаться на ранних стадиях, когда требования только обсуждаются. Это позволяет выявить возможные проблемы и риски ещё до того, как код написан, экономя время и ресурсы на исправления.

Для этого важно пересмотреть процесс планирования: приглашайте специалистов по тестированию (QA) участвовать в ранних обсуждениях и планировании. Их участие на этих этапах позволяет лучше понять технические и функциональные требования, помочь в определении тест-кейсов и условий приемки. QA могут заранее предложить тестовые сценарии и выявить потенциальные уязвимости в проектировании. Это приводит к снижению вероятности обнаружения критических дефектов на финальных этапах и делает тестирование не завершающим элементом процесса, а неотъемлемой его частью.

Как чинить 2:

Используйте практику 3 Амиго, когда разработчики, тестировщики и аналитики (или владельцы продукта) совместно обсуждают требования и сценарии конкретной задачи еще до начала работы над ней. Опыт тестировщика на этом этапе незаменим: благодаря глубокому знанию системы и процессов, тестировщик сможет выявить потенциальные проблемы, которые могут быть упущены остальными участниками команды. Тестировщик часто видит проект в более широком контексте, предугадывая, где могут возникнуть узкие места, риски или противоречия.

Ниже, я подготовила полезный PDF-файл, заглянув в который, вы сможете лучше понять разницу между двумя инструментами, так как, на первый взгляд, они могут показаться достаточно похожими.

Таким образом, при внедрении этих практик, роль тестировщика не ограничивается только тестированием готового продукта, а становится важной частью всего цикла разработки.

Ошибка 2: Не автоматизировать тесты

К чему приводит:

Полагаться только на ручное тестирование — это не только долго, но и рискованно. Тестировщики могут просто не успеть протестировать все необходимые сценарии, особенно если речь идет о регрессионных тестах. Это увеличивает риск того, что некоторые баги или важные сценарии будут упущены. Кроме того, человеческий фактор всегда присутствует — можно случайно пропустить критическую ошибку или неверно оценить результат. В результате процесс разработки и релиза замедляется, а качество продукта снижается из-за пропущенных проблем, которые могли бы быть своевременно обнаружены при наличии автоматизированных тестов. Автоматизация позволяет тестировать быстрее, охватывая широкий спектр сценариев, в том числе те, которые сложно проверить вручную, что в конечном итоге повышает общую стабильность и качество продукта.

Алгоритм «Как чинить отсутствие автоматизации тестирования»

1. Определите критические зоны для автоматизации.
   Здесь вы можете выбрать один из пунктов, который больше всего подходит вашей ситуации:

а) Проанализируйте систему и выявите самые важные функции, критичные для стабильности продукта.

б) Определите участки, где чаще всего возникают проблемы или баги.

в) Сосредоточьтесь на функциональности, которая изменяется чаще всего и которая чаще всегда подвергается регрессионному тестированию.

2. Внедряйте автоматизацию пошагово:

• Начните с unit-тестов, проверяющих работу отдельных модулей.
• Далее добавьте интеграционные тесты, чтобы проверить взаимодействие между модулями.
• После этого внедрите end-to-end тесты для проверки работы всей системы целиком.

Здесь я намеренно сделала допущение, которое хочу обсудить:) А именно — автоматизация не обязательно начинается с unit-тестов.

Идеальным сценарием для внедрения автоматизации тестирования считается подход «снизу вверх»: сначала unit-тесты, затем интеграционные тесты, а потом end-to-end. Однако на практике это не всегда возможно.

Например, разработчики могут не поддерживать тестирование на уровне unit-тестов, или кодовая база может быть настолько устаревшей, что начинать с unit-тестирования сложно.

Что делать в таких ситуациях?

Если начать с unit-тестов не получается, это не значит, что автоматизация невозможна. Вы можете начать с любого доступного уровня тестирования.

Например:

• Интеграционные тесты: Они проверяют, как модули взаимодействуют друг с другом. Это станет хорошим стартом, если модули уже достаточно стабильны. 
• End-to-end тесты: Они проверяют работу системы целиком и часто становятся первым шагом для команд, работающих с устаревшими системами. Но нужно помнить, что такие тесты сложнее автоматизировать, они дольше выполняются и требуют больше усилий на поддержку.

Что важно учитывать?

• Чем выше уровень тестирования (например, end-to-end), тем больше сложностей и затрат на автоматизацию.
• Низкоуровневые тесты (unit, интеграционные) обеспечивают более быструю обратную связь и дешевле в обслуживании. Поэтому, если есть возможность, постепенно переходите к добавлению тестов на более низких уровнях.

3. Не пытайтесь автоматизировать всё сразу:

• Сосредоточьтесь на важных участках системы и автоматизируйте поэтапно.
• Не пытайтесь охватить все тесты сразу, расширяйте автоматизацию постепенно.

4. Создайте инфраструктуру для тестов:

• Обеспечьте стабильную инфраструктуру для выполнения тестов.
• Настройте автоматическое и быстрое выполнение тестов при каждом изменении в коде.

5. Инвестируйте в поддерживаемость. Пункт, который чаще всего забывают при внедрении автоматизации:

• Делайте тесты легко поддерживаемыми и модифицируемыми.
• Следите за тем, чтобы тесты были стабильными.

6. Оцените результаты:

• Постоянно анализируйте, как автоматизация помогает в выявлении багов и улучшении стабильности.
• Расширяйте охват автоматизацией на другие участки системы по мере необходимости.

Главное — начать. Автоматизация тестирования на любом уровне уже даст ценность, а при правильном подходе можно будет постепенно расширять покрытие автотестами в вашем продукте.

Ошибка 3: Не тестировать нагрузку и безопасность

К чему приводит:

Когда в компании не тестируют продукт на нагрузку или безопасность, это может обернуться большими проблемами. Система может отлично работать при небольшом количестве пользователей, но как только нагрузка возрастает, например во время распродаж, начинаются сбои, и сервис падает. Еще хуже, если не тестировать безопасность: уязвимости могут остаться незамеченными, что в итоге приведет к утечкам данных или взлому. Это не только сильно ударит по репутации, но и может привести к финансовым потерям.

Как чинить:

1. Определите критические зоны для тестирования:

• Проанализируйте систему, чтобы выявить компоненты, которые наиболее подвержены рискам при высоких нагрузках или уязвимы с точки зрения безопасности.

2. Создайте сценарии нагрузочного тестирования:

• Разработайте тесты, имитирующие реальные условия высокой нагрузки (пиковые периоды, массовое подключение пользователей).
• Настройте тесты для проверки максимальной производительности и стабильности системы под давлением.

3. Создайте сценарии тестирования безопасности:

• Определите потенциальные уязвимости системы.
• Разработайте тесты, которые проверяют защиту данных, систему авторизации, возможности атак (например, SQL-инъекции, XSS).

4. Автоматизируйте выполнение тестов:

• Интегрируйте тесты нагрузки и безопасности в пайплайн CI/CD.
• Автоматизируйте запуск этих тестов, чтобы они выполнялись регулярно и не требовали ручного запуска при каждом изменении.

5. Фиксируйте результаты тестов:

• Настройте систему для сбора и хранения результатов всех тестов.
• Анализируйте результаты, чтобы видеть, как система реагирует на изменения, и выявлять зоны для оптимизации.

6. Проводите анализ и настройку инфраструктуры:

• Следите за поведением системы во время тестов и оптимизируйте ее под возможные нагрузки.
• Проводите регулярный аудит системы безопасности на основе результатов тестирования и обновляйте настройки для улучшения защиты.

7. Обеспечьте постоянное тестирование:

• Настройте регулярные запуски тестов нагрузки и безопасности, чтобы убедиться в их актуальности по мере изменения системы.
• Периодически обновляйте тестовые сценарии в соответствии с новыми требованиями или изменениями в продукте.

Ошибка 4: Использовать одну метрику для оценки качества или не использовать их вовсе

К чему приводит:

Частый случай, когда вся оценка тестирования сводится только к количеству найденных багов. Это создает иллюзию, что работа идёт хорошо, хотя на самом деле не всё так гладко. Да, багов может быть немного, но что, если продукт тормозит, баги исправляются месяцами или тесты покрывают только часть системы? Фокусируясь только на количестве найденных ошибок, команда может упускать важные моменты, такие как производительность, скорость исправления багов, качество кода, и самое главное — насколько хорошо тесты охватывают функциональность продукта.

Здесь важно добавить, что в самой метрике «количество найденных багов» нет ничего плохого и ее нужно замерять, но для того, чтобы получать более широкую картину того, как дела обстоят с качеством, концентрироваться только на одной метрике недостаточно. Вопрос качества комплексный, и на него всегда нужно смотреть под разными углами, используя несколько метрик. 

Как чинить:

1. Определите ключевые аспекты качества продукта и выберите основные метрики.

Например:

• Количество багов: фиксируйте количество обнаруженных багов на разных стадиях разработки.
• Покрытие кода тестами: измеряйте процент кода, который покрыт автоматизированными тестами (unit, интеграционные, e2e-тесты).
• Скорость исправления багов: отслеживайте, сколько времени уходит на исправление багов с момента их обнаружения до момента фиксации.
• Стабильность сборок: мониторьте количество успешных сборок без ошибок и сбоев.
• Количество инцидентов на продакшене: регистрируйте баги, с которыми сталкиваются реальные пользователи на проде.

2. Настройте сбор данных для каждой метрики.

Например:

• Используйте инструменты CI/CD для автоматического подсчета стабильности сборок и покрытия кода тестами.
• Внедрите баг-трекер или настройте его так, чтобы фиксировать время обнаружения и исправления багов.
• Настройте мониторинг продакшена для отслеживания инцидентов.

3. Анализируйте данные на регулярной основе.

• Собирайте и оценивайте данные по каждой метрике на протяжении времени, чтобы выявить тренды и изменения в качестве продукта.
• Анализируйте причины изменений: например, увеличение количества багов может сигнализировать о необходимости пересмотра процессов тестирования.

4. Проводите ретроспективы на основе метрик.

• Включайте анализ метрик в регулярные ретроспективы, чтобы команда могла понять слабые места в процессе разработки и тестирования.
• Определите ключевые проблемы и находите пути их решения: пересмотр тестовой стратегии, улучшение автоматизации, обучение команды.

5. Мониторинг и корректировка процессов на основе данных.

• Постоянно отслеживайте результаты метрик и корректируйте ваши процессы и подходы по мере роста и изменения продукта.
• Определяйте новые цели для улучшения качества продукта и расширяйте систему метрик по мере необходимости.
• Обновляйте и добавляйте метрики по мере того, как меняются потребности в оценке качества.

Ошибка 5: Пренебрежение exploratory testing

К чему приводит:

Если пренебрегать exploratory testing, можно пропустить множество неожиданных багов, которые не выявляются стандартными тест-кейсами.

Exploratory testing — это метод тестирования, при котором тестировщик свободно исследует продукт без заранее прописанных сценариев. В процессе он придумывает и тут же проверяет различные гипотезы, исследуя поведение системы с разных сторон. Это помогает найти баги и проблемы, которые могут остаться незамеченными при стандартном тестировании по чек-листам или тест-кейсам.

Плюсы exploratory testing:

• Стандартное тестирование сосредоточено на проверке заранее известных требований, но exploratory testing позволяет выявить скрытые проблемы, такие как неочевидные конфликты между модулями, ошибки при необычных нагрузках или некорректное поведение при граничных условиях. Это помогает заранее укрепить слабые места системы, делая продукт более устойчивым к нестандартным ситуациям.
• Exploratory testing часто дает инсайты, которые неочевидны при стандартном тестировании. Например, тестировщик может обнаружить нестыковки в бизнес-логике или неочевидные риски, которые затем обсуждаются с разработчиками и аналитиками. 

Как чинить:

Включите exploratory testing в регулярные процессы команды. Позвольте тестировщикам время от времени отходить от строгих сценариев и исследовать продукт так, как это сделал бы реальный пользователь, включая неожиданные действия и нестандартные сценарии. Определите время в каждом спринте для свободного исследования продукта. Это не только поможет обнаружить скрытые проблемы, но и даст более глубокое понимание работы системы в реальных условиях.

Ошибка 6: Игнорируем регрессионное тестирование или выделяем на него недостаточное количество времени

Этот пункт не столько про Agile тестирование, сколько общая проблема, которая встречается практически повсеместно. 

К чему приводит:

Когда команда игнорирует регрессионное тестирование или не уделяет ему достаточно времени, есть риск, что изменения в коде могут нарушить уже работающую функциональность. Новые баги могут появляться в тех частях системы, которые ранее были стабильными, что может привести к неожиданным инцидентам на продакшене. Без регулярного регрессионного тестирования качество продукта будет падать с каждым новым релизом, поскольку старые ошибки могут возвращаться, а команда даже не будет об этом знать до тех пор, пока пользователи не начнут жаловаться и писать гневные сообщения на всех возможных площадках.

А мы помним из первого пункта, что чем позже был найден баг, тем дороже и дольше его чинить для команды.

Как чинить 1:

Включите регрессионное тестирование в обязательный процесс перед каждым релизом. Используйте автоматизацию для регулярного запуска тестов на уже существующую функциональность при каждом изменении в коде, чтобы быть уверенными, что продукт остается стабильным даже после внесения изменений.

Как чинить 2:

Определите ключевые части системы, которые наиболее критичны для работы и которые чаще всего изменяются. Постепенно расширяйте набор регрессионных тестов на всю функциональность, уделяя особое внимание компонентам, где ранее возникали баги. Это поможет поддерживать стабильность системы и снизит риск появления новых багов в старых частях продукта.

Здесь хочу напомнить и обратить ваше внимание на то, что регрессионный набор тест-кейсов всегда должен пересматриваться. Изменения в системе, такие как добавление новых функций, рефакторинг, устранение багов или оптимизация кода, могут сделать часть старых тестов устаревшими или неактуальными. Если тест-кейсы не соответствуют текущему состоянию системы, они теряют свою ценность: вместо выявления реальных проблем они могут давать ложные данные о качестве или пропускать критические баги.

Регулярный пересмотр регрессионного набора тестов включает:

• Добавление новых тестов для новых функций. Если в системе появились новые сценарии использования, они должны быть покрыты тестами.
• Удаление устаревших тестов. Если функциональность была удалена или сильно изменена, тесты, связанные с ней нужно исключить из набора.
• Обновление существующих тестов. Сценарии могут требовать актуализации, чтобы соответствовать новым требованиям или изменениям в бизнес-логике.
• Оптимизация набора тестов. Пересматривайте набор, чтобы исключить дублирующиеся тесты или выявить «лишние» тесты, которые не добавляют ценности.

Agile Testing — это не просто способ ускорить процессы, но и возможность значительно повысить качество вашего продукта. Гибкое тестирование, интегрированное на каждом этапе разработки, помогает не только оперативно находить и исправлять ошибки, но и адаптироваться к изменениям и новым требованиям. Избегая ошибок, о которых я рассказала, и внедряя предложенные решения, ваша команда сможет сократить время на тестирование, снизить риски возникновения багов и повысить стабильность системы. Кстати, подробнее о том, как внедрить тестирование на всех этапах разработки и улучшить командное взаимодействие, я рассказываю на тренинге Agile Testing.

Помните, что тестирование — это не отдельная часть разработки, а важный элемент всей Agile-экосистемы. Привлекая QA на всех этапах, автоматизируя ключевые тесты и внедряя регулярные проверки на безопасность и нагрузку, вы обеспечите продукту не только высокое качество, но и гибкость, столь необходимую в современном мире разработки.