- PVSM.RU - https://www.pvsm.ru -
SCRUM — фреймворк управления проектами, в который наша команда попробовала внедрить этап тестирования. В этой статье мы хотим помочь не совершить наших ошибок тем командам, которые только начинают знакомиться со SCRUM. Участники же опытных SCRUM-команд приглашаются в комментарии, чтобы поделиться замечаниями и успехами. А в качестве иллюстраций — беговые дорожки, марафонцы, препятствия. Они тут неспроста. Да и Олимпиада же, в конце концов.
[1]
Начнём с перечисления ключевых особенностей SCRUM для тех, кто с ним не знаком:
Использование компанией Лайв Тайпинг [2] SCRUM-методологии в некоторых продуктах впоследствии дало свои положительные плоды: команда достигала дисциплины без надзора со стороны менеджера; задачи оценивались точнее, потому что их оценка происходила не в начале проекта, а по ходу, когда было уже известно о некоторых подводных камнях; со стороны заказчика поступал быстрый и качественный фидбек. Но вместе с его успешным внедрением встал вопрос о том, как в рамки этой методологии встроить уже имевшийся процесс тестирования. Рефлексии отдела тестирования нашей компании легли в основу всего, что написано ниже.
На старт, внимание…
Приоритетный вектор компании — разработка мобильных приложений. Это часто создаёт специфические рабочие условия: сроки бывают сжатыми, нормальной документации (как это бывает в случае со стартапами) нет, а требования заказчика меняются часто и резко. Из-за этого в организации тестирования возникает ряд сложностей, основная из которых — время. Если сравнивать большой энтерпрайз-проект и мобильный стартап, то в первом случае к проекту предъявляется море требований, но работать проще — зачастую есть и утверждённая документация, и сроки не такие сжатые. В мобильной разработке проекты не всегда настолько же масштабны, но из-за специфики тестирования мобильных платформ, особых требований к приложениям и частого отсутствия технической документации фронт работ получается сопоставимым, а времени на тестирование выделяется меньше.
Отсюда вытекают следующие проблемы тестирования мобильных приложений:
Изменения в требованиях происходят «на лету», поэтому смысла составлять ТЗ нет — больше времени уйдёт на его актуализацию, чем на разработку продукта. Также бывают проблемы в общении и информированности внутри команды: разработчик уточнил деталь у заказчика, но с остальными не поделился, или тестировщика не было на митинге, где принимались важные решения, не задокументированные из-за нехватки времени. И тому подобное. Как итог, у команды нет чёткого понимания проекта. Отсюда вытекает следующая проблема:
Часто работа над продуктом организован так, что сборка отдаётся на тестирование тогда, когда готова львиная доля функций. Если тестировщик не следил за развитием продукта, то перед началом тестирования он должен потратить много времени на вникание в его работу.
Когда ваше приложение, к примеру, предоставляет интеграцию с календарём, использует самостоятельно разработанные чаты, получает данные из соцсетей и делится информацией через них же или взаимодействует с облачными сервисами вроде Google Drive, сложность тестирования возрастает по экспоненте из-за различных вариантов взаимодействий.
Основной проблемой реализации тестирования в SCRUM была сложившаяся на тот момент практика тестирования. Она предполагала продолжительные этапы разработки, затем передачу сборки на тесты, приём баг-репортов, правки, опять тестирование, снова правки, и так до тех пор, пока заявленные на этом этапе функции не начинали работать правильно. Смысл же SCRUM — в относительно коротких спринтах, по окончанию которых у вас есть некоторый оформленный и рабочий инкремент продукта. В итоге у нас сложилось две схемы.
Схема 1. Назовем её «Однократное тестирование + проверка фиксов».
Ключевые моменты:
Получалось, что найденные в текущем спринте баги исправлялись только в следующем. Но так как заказчик был в курсе статуса проекта, и итоговая приёмка проводилась только в конце этапа, в спринт закладывается больше времени на тесты и фиксы, и всё вроде бы нормально.
Плюсы данного подхода:
Такой подход был очень похож на сложившийся в компании до перехода на SCRUM, что и позволило ознакомиться с методологией относительно безболезненно. Также к концу этапа сдавались полностью оттестированные функции, что освобождало от мук совести.
Минусы данного подхода:
Порой заказчик сам любил тестировать продукт, а у команды не было жёсткого списка тех задач, которые должны быть выполнены в данный спринт, кроме списка задач на этап. Это оборачивалось следующим:
Не ходите нашим тернистым путём — сразу возьмите за правило жёстко определять задачи на спринт и устранять критические баги в текущем спринте.
Итог работы по схеме: получился качественный продукт, но производственный процесс нельзя было полностью назвать SCRUM’ом. Заказчик был часто недоволен тем, что сам находил баги, хотя итоговый результат его вполне устроил.
Дышим ровно, бежим дальше.
Схема 2. Её назовём «Потоковое тестирование».
Ключевые моменты:
Эта схема уже больше похожа на реальный SCRUM, хоть и имеет место добор задач в спринт, чья длительность несколько раз менялась.
Плюсы данного подхода:
При соблюдении всех этих условий продуктивность работы растёт: каждый день примерно в одно время тестировщик получает сборки и даёт отчёт, чтобы команда при необходимости поправила критические вещи. Это позволяет ему лучше спланировать рабочее время и быть уверенным, что его не выдернут на другой проект.
Минусы данного подхода:
Характерная черта данной схемы ещё и в том, что если обнаруживается баг, связанный с какой-либо задачей, но баг этот не критический и не блокирующий, то задача всё равно помечается как выполненная. Однако же в комментариях баг снабжается описанием (либо на него даётся ссылка в баг-трекере), а ВП просматривает его и окончательно решает, принять или отклонить эту задачу. Плюс фоном есть чувство неловкости от того, что ты отдаешь заказчику сборку с багами.
Итог работы по схеме: значительно лучше первой схемы, но не без недостатков. Чтобы сгладить их, мы выделили для себя некоторые дополнительные правила.
Cейчас у вас откроется второе дыхание — мы выходим на финишную прямую.
Эти приёмы в ведении проектов по SCRUM-методологии мы вывели для себя в процессе работы и продолжаем их оттачивать. Надеемся, что они будут полезны и вам:
Единственные задачи, которые можно и нужно добавлять — это починка блокирующих багов. Также позволительно добавлять задачи поверх изначальных, но только при условии, что изначальные задачи выполнены, оттестированы, и всё работает как надо.
Каждая из сборок должна являться инкрементом продукта. Если после добавления очередной фичи всё поломается, и решение проблемы окажется долгим и сложным, можно отправить ВП одну из предыдущих сборок — уж одна-то из них окажется рабочей.
Если вы успешно протестируете сборку на Nexus 5, Galaxy S7 и Xperia Z3, то заказчик может взять свой LG G3, на котором всё окажется плохо. Рынок мобильных устройств (особенно Android) разнообразен, и сложно подстроиться под весь, поэтому надо задать границы.
Баги могут вылезти в последний момент, и вы обрекаете себя работать в выходные и таскать за собой кучу тестовых устройств, куда бы вы ни пошли. Это сильно скажется на качестве тестирования. Конец спринта лучше всего устанавливать во вторник-среду, тогда последние приготовления к сдаче будут проходить в штатном режиме.
Также внутри своей команды мы ввели небольшой элемент канбана. Возможны ситуации, когда список задач для теста растёт, а разработчики не отдают сборку тестировщику, потому что хотят сделать и отдать на тест побольше задач за раз; или когда к проверке готово много задач, а тестировщик не отдаёт сборку ВП, потому что хочет отдать максимально большую часть протестированного продукта. В итоге страдают все: у тестировщика аврал — времени до конца спринта мало, а задач на тест много; у разработчиков аврал — времени до конца спринта мало, а тестировщик прикатил вагон багов; у ВП аврал — времени до конца спринта мало, а команда всё чинит да тестирует, чинит да тестирует. Чтобы этого избежать, у каждого члена команды не может одновременно находиться в работе, например, более двух задач, а общее число задач в тесте и готовых для проверки не может превышать (тоже например) шести в каждом случае, если в команде три разработчика.
В первую очередь SCRUM сглаживает проблему отсутствующей документации и налаживает общение в команде: задачи ставятся постепенно и формулируются понятно, постоянно поддерживается связь с представителем заказчика, и разобраться в проекте гораздо легче. Параллельно с этим можно составлять тестовую документацию.
Тестирование начинается чуть позже разработки, что позволяет быть в контексте проекта с самого его начала и значительно упрощает работу. Все стремительно меняющиеся пожелания заказчиков оперативно обсуждаются с командой и принимаются (или не принимаются) коллегиально, так как ВП находится в тесном контакте с командой и со временем понимает, что реально сделать, а что нет.
Следование этим приёмам хоть и не гарантирует успешного завершения проекта, но как минимум поможет в этом. Надеемся, что они окажутся полезными. Если у вас есть свои примеры внедрения SCRUM, то мы будем рады увидеть их в комментариях.
Автор: Лайв Тайпинг
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/174389
Ссылки в тексте:
[1] Image: https://habrahabr.ru/company/livetyping/blog/307860/
[2] Лайв Тайпинг: http://livetyping.com
[3] Источник: https://habrahabr.ru/post/307860/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.