По итогам тендера мы получили возможность заняться тестированием единой автоматизированной системы одного из национальных сервисов пересылки корреспонденции. Функционал напоминает «единое окно», в котором работают сотрудники, чтобы ускорить все процессы. Сказать, что проект масштабный – это как линейкой попытаться измерить высоту айсберга. Когда наши специалисты включились в работу, на проде уже была 13 версия и странно попахивающее озеро негативных отзывов от пользователей. Кто-то из команды произнёс риторическое: «Challenge»? и остальные согласно кивнув, приступили к выполнению своей работы. Кто мог знать, что айсбергу только предстоит показать себя целиком.
Рекогносцировка на месте
Первым высадился десант из 5 тестировщиков. Провели разведку, присмотрелись – работы непочатый край.
Коммуникации на проекте практически не налажены. На просьбу предоставить информацию, а также на вопросы «какая должна быть информация и как она должна попасть в отчет», нам отвечали, что такой информации в природе не существует. Документирование не велось, а если и были какие-то документы, то не всегда была понятна их актуальность и часто в помощь просто призывался «всезнающий гугл».
На вопросы «как правильно должно работать приложение» ответ был «смотрите на стенды, как работает – значит так и правильно». А на вопрос как проверить правильность отчетов, звучал ответ – «распечатался – значит все хорошо».
Но даже посмотреть, как все работает на стендах, у нас не было возможности, так как на проекте наблюдался недостаток машин, и не все они были в рабочем состоянии. А накат новой версии длился несколько дней и в это время все тестировщики учились гадать на кофейной гуще и плясать с бубном.
Если разобраться, у нас почасовка, финансовой заинтересованности в консалтинге проектов и их улучшении у нас почти никогда нет. Но заставьте состоявшегося специалиста в области тестирования просиживать штаны и терпеть происходящий бардак… Одним словом, вы не захотите увидеть гнев терпеливого человека. Естественно, наших специалистов такой вариант тоже не устраивал, и мы решили менять ситуацию. Так как с проектом, помимо нас, работало еще несколько команд тестирования, первым делом мы решили разделить зоны ответственности.
Развертывание лагеря
Мы определили для себя такие основные задачи:
- проанализировать текущие кейсы regress и smoke;
- определить какие из них актуальны для текущего функционала;
- переработать нужные кейсы, сделав их актуальными;
- прогнать актуальные regress и smoke-тесты.
Для выполнения этих задач было необходимо:
- Оценить задачи и определиться с необходимым количеством тестировщиков.
- Запросить новые машины для тестирования.
- Предложить вариант оптимизации обновления контура для ускорения обновления ревизии.
- Обсудить изменения в багтрекере для отслеживания метрик и оптимизации тестирования.
- Ознакомиться с приложением, собрать и структурировать информацию по работе с ним.
- Подготовить программу погружения для новых участников проекта.
На период проблем с машинами записывать видео по работе приложения для возможности актуализации старых кейсов без машин, а также для быстрого знакомства с приложением новых тестировщиков в условиях дефицита машин.
Оценка работ и сбор отряда
Для оценки поставленных задач мы проанализировали полноту текущего покрытия, а также прикинули какое количество кейсов нужно для более полного покрытия функционала.
Для смоук-тестов мы решили оставить старое количество кейсов, потому что стояло требование укладываться с ними в 1 день. Основной упор делался на то, что кейсы должны быть актуальны, максимально понятны и покрывать основной функционал -1 приоритета (блокеры).
При этом регресс-тесты мы серьезно расширили, до 2000 штук, потому что именно такое количество позволяло оптимально покрыть функционал.
В итоге у нас получилось:
- 129 человеко-часов на смоук;
- 1250 – на регресс;
- 1000 – на кейсы TFS;
- 1000 – на доработку кейсов по новым багам в
почтовом TFS; - 1550 – на смоук, 12 раз в течение трёх месяцев;
- 1033 – на смоук, 8 раз в течение двух месяцев;
- 7343 – на доработку кейсов (с учетом рисков).
Зная объем работы, мы предложили заказчику несколько вариантов комплектации команды на выбор.
- Можно было заняться доработкой существующих кейсов смоука и регресса без учета дефектов, увеличив команду с 5 до 6 человек.
- Можно было заняться тестированием, и обработкой дефектов, заведенных командами тестирования до нас и дефектов с прода, расширив команду до 14 человек.
- Если дорабатывать кейсы по дефектам и тестировать их, то нужно было уже 17 человек.
- Чтобы выполнить все задачи на проекте, можно было увеличить команду до 20 человек.
Так как на проекте уже была одна команда, они взяли на себя тестирование доработок, а мы взяли в работу все остальные задачи. Так наша команда была увеличена до 17 тестировщиков!
Оружие добывать в бою!
На самом деле количество тестировщиков на проекте определялось не только на основании указанных выше параметров. Приходилось учитывать также ограниченный бюджет. Чтобы и работа двигалась, и в бюджет вписаться, мы собрали для заказчика команду со значительной долей хоть и многообещающих, но джуниоров. Конечно не стоит думать, что мы просто бросили необстрелянных бойцов на амбразуру. Кто знаком с нашим подходом или работал с нами, тот знает – в ЛК уже как 5 лет работает отличная система наставничества и обучения. Каждый новичок имеет индивидуальный план погружения на проект с мануалами и ссылками на необходимые ресурсы. А на период отсутствия машин, обучение происходило с помощью видео, схем и таблиц, созданных более опытными первопроходцами из первого десанта.
Предложенные нами изменения и умение стоять на своём спустя некоторое время обеспечили нам полноценный доступ к 17 машинам. Новые машины да еще и на всех участников команды – это же отлично! Но они, увы, не всегда работали. И первое время нам приходилось ждать, пока заказчик их починит и актуализирует. Сидеть и ждать – губительно сказывается на морали наших ребят. Поэтому мы опять решили брать быка за рога. Крупица за крупицей собрали информацию, написали инструкции и постепенно забрали исправление/настройку машин себе. В итоге команда тестирования перестала зависеть от специалистов заказчика и работоспособности инфраструктуры.
Закрепиться на рубежах
Чтобы работать без простоев и облегчить задачу себе и другим командам, которые работают с нами и могли бы работать после нас, мы постоянно собирали актуальную информацию о работе системы. Особенно в те моменты, когда у нас не было полноценного доступа ко всем рабочим машинам.
Во-первых, с учетом того, что машин было впритык, да еще и они могут отличаться по свойствам, мы создали документ для учета их занятости, а также описания проблем и основных характеристик.
Во-вторых, мы проанализировали те пособия и руководства, которые удалось найти, на их актуальность и собрали все полезные ссылки в едином документе, для удобства их использования.
В-третьих, провели тест-анализ основного функционала чтобы наконец-то зафиксировать, как он реализован на текущий момент и какие есть возможности для более полного покрытия подсистем.
Что это нам дало? Благодаря актуализации кейсов смоука наша команда может обеспечить быстрый и качественный смоук функционала в любой момент, когда возникает такая необходимость.
А еще мы продолжаем работу по актуализации кейсов регресса. Например, в начале нашей работы было 1186 кейсов, которые покрывали около 25% функционала. И только 12 из них не требовали изменений. Еще 755 мы предложили исправить, а 316 и вовсе удалить. Вместо них появилось 1106 новых, которые мы предложили добавить. Так планируемое количество кейсов регресса выросло до 2050 и в нынешнем составе команды мы можем пройти его за 2 недели.
Основное достижение в том, что мы создали общую базу знаний и информации о проекте, которой удобно пользоваться, даже если вы только начали работу на проекте.
Сражение с багами
Проводя тестирование и анализируя ошибки с марта по май включительно, наша команда завела более 300 багов. Из них 10 – это блокирующие и 47 критичные. А также 173 средних и 132 низких.
Но самое главное достижение в том, что по сравнению с периодом, когда мы пришли на проект, количество ошибок, пропущенных на прод, уменьшилось практически втрое – с 61% в феврале до 23% в мае!
Чему мы научились
Несмотря на то, что проект только начинается и еще много всего предстоит сделать, мы традиционно подведем итоги того, чего мы уже добились.
- Мы снова убедились в том, что способны работать с проектами любой сложности: там где нет документации, нет структурированной информации, нет отчетов, нет даже четких ТЗ и доступа к машинам.
- Мы можем строить гибкие отношения и подстраиваться под любого заказчика – даже когда отсутствует желание клиента делиться проектной информацией и объяснять задачи.
- Мы готовы самостоятельно искать пути повышения эффективности тестирования, лишь бы не тормозить и не простаивать. Даже брать на себя вопрос отладки и настройки рабочих машин.
- Наша система подбора персонала продолжает работать с минимумом сбоев. Даже попадая в атмосферу тяжелых проектов, неопытные тестировщики не паникуют, а пытаются найти решения, при поддержке опытных наставников. Сложности только помогают команде сплотиться и мы рады за наших ребят!
- Наши свежие джуны отлично показали себя в деле. При этом они быстро прокачали свой профессиональный уровень и помогли заказчику вписаться в ограниченный бюджет.
- Мы убедились в простой «мудрости тестировщика» и постигли QA дзен. Не все баги одинаково подлежат устранению. Есть те, которые точно нужно исправить, а есть такие, которые не стоит трогать, чтобы не поломать то, что и так работает.
Поэтому мы делаем глубокий выдох, расслабляемся, отпускаем весь негатив и продолжаем плодотворно работать.
А если вам нужно, чтобы кто-то пришел и разгреб ваши завалы, в которых не сохранилось ни базы, ни ТЗ, ни инструкций — у нас есть такой опыт. Обращайтесь к продаванам «Лаборатории качества» и мы возьмемся за ваш проект!
Добрый день!
Это «оговорочка по Фрейду» или маркер сильно забагованного функционала?
Доброго дня!
Будем считать это проф. юмором )
Очень содержательная статья, спасибо!!!
[…] Регрессионное тестирование […]