Гибкие разработки становятся все более распространенными. Хотел бы рассмотреть в рамках Agile один из самых неоднозначных и сложных аспектов разработки – тестирование.
Agile пропагандирует командную работу и, как результат, тестировщик – это член команды с навыком тестирования, а не обособленная роль.
Что из этого вытекает:
Максимум коммуникации.
Процесс менее формален, и координация усилий команды, принятие решений происходит посредством тесной коммуникации. Поэтому тестировщик должен участвовать во всех командных мероприятиях (scrum митинги, ретроспективы, любые обсуждения), даже если он сидит отдельно от разработчиков.
Планирование.
Разработка состоит из спринтов – коротких итераций фиксированной длины, в конце которых имеем рабочий, оттестированный функционал. Тестировщик участвует в планировании спринта, в оценке фич. Т.е. тестирование – это обычный таск работы над фичей и он закладывается в оценку фичи. Участие тестировщика в оценке работ помогает избежать пренебрежения тестированием. Совместное планирование разработчиками и тестировщиками помогает выяснить детали фичи, которые помогут сделать оценку более точной и обеспечить знание фичи всеми.
Реализуем следующий подход: фича (story) не готова пока тестировщик не скажет, что это так. Нет фич готовых, но не оттестированных, иначе они считаются не сделанными. Все члены команды должны это понимать, и это незыблемый принцип . Избежать желания впихнуть побольше фич, невзирая на то, что все невозможно оттестировать, должна помочь командная ответственность за общий результат, в том числе и за качество.
Таски спринта – это общие таски всей команды.
Команда определяет скоуп, который она берется сделать за фиксированную итерацию. Все таски в этой итерации – таски команды. Если у тестировщика есть время, то он помогает разработчикам всем чем может. Если накопилось много тасков по тестированию, а конец спринта близко, разработчики помогают в тестировании, например, проводят нагрузочное тестирование.
Виды тестирования во время спринта:
Планирование тестирования
Пока не готова первая story идет планирование тестирования, изучение требований, создание тест-кейсов, возможна автоматизация, если есть время.
Приемочное тестирование билда
Происходят ежедневные сборки и перед началом тестирования, нужно прогнать тест на живучесть билда, автоматический тест естественно.
Тестирование фич
Оно начинается соответственно когда готова первая фича и продолжается пока последняя фича спринта не протестирована.
Очень важный момент: story должны быть разбиты так, чтобы программисты не делали их очень долго и не заканчивали ближе к концу спринта. Т.е. если спринт, например, 2 недели, т.е. 10 рабочих дней, то не должно быть тасков для девелопера на дней 7. Он тогда может вообще не успеть к концу спринта. Разбиваем таск или его могут выполнять 2 разработчика - это нормально. Таски не должны быть большими и будут завершаться равномерно по всему спринту.
Регрессионное тестирование
Тестирование релиз кандидата.
За 2 дня до конца спринта начинаем тестирование версии, которая пойдет в релиз. Больше изменений не вносим, если только важные фиксы.
Автоматизация тестирования
Сложно переоценить роль автоматизации при гибком подходе к разработке. Короткие итерации требуют частое перетестирование существующего функционала. Руками это будет очень дорого! Поэтому без автоматизации никуда!
В спринте должно закладываться время для автоматизации (создания новых, модернизация имеющихся автоматизированных тестов). Если возникают трудности с нехваткой времени - привлекаем помогать разработчиков. Без этого никуда. Либо нужно много ресурсов для ручного тестирования, либо будет толком оттестирован только новый функционал!
Распространенный случай, когда времени, ресурсов на тестирование не хватает. Рассмотрим сначала причины проблем, а затем способы их решения.
Причины нехватки тестирования:
Нехватка ресурсов тестирования.
Не хватает тестировщиков, чтобы обеспечить качество. Много программистов, мало тестировщиков.
Много ручного тестирования.
Неэффективный процесс тестирования.
Проблемы с планированием, с выделением времени на определенные активности, виды тестирования.
Нарастание функционала для регрессионного тестирования.
У нас есть команда, в ней X программистов и Y тестировщиков. Идут итерации, проект соответственно растет, растет и функционал, который нужно тестировать, ресурсы те же, начинает соответственно не хватать времени.
Способы решения проблем:
Автоматизируем, возможно привлекая разработчиков.
Если постоянно с увеличением функционала увеличивать его покрытие автоматическими тестами, то не будет увеличиваться кол-во ручной работы или по крайней мере увеличиваться медленнее. Здесь необходимо иметь ввиду трудозатраты на возможный апдейт автоматизированных тестов.
Увеличить покрытие кода юнит-тестами.
Улучшаем качество кода, которое идет на тестирование, всеми возможными способами.
Делать стабилизационные спринты.
В этих спринтах фиксим баги, проводим полное тестирование, автоматизируем, не разрабатываем новых фич (убедить заказчика в этом сложно , стараемся включить минимум нового).
Увеличить количество ресурсов тестирования.
Если не получается увеличить качество процесса разработки, тестирования, и проблема осталась, то остается только это. Возможно даже в ущерб количеству разработчиков, если бюджет ограничен.
Смысла в создании большого количества фич, которые не тестируются, нет.
16 лет dev.by — «дефолтный» источник информации о беларусском ИТ
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.