Как проводить smoke и regress-тестирование без инструкций, ТЗ, предыдущих отчетов и даже машин?

По итогам тендера мы получили возможность заняться тестированием единой автоматизированной системы одного из национальных сервисов пересылки корреспонденции. Функционал напоминает «единое окно», в котором работают сотрудники, чтобы ускорить все процессы. Сказать, что проект масштабный – это как линейкой попытаться измерить высоту айсберга. Когда наши специалисты включились в работу, на проде уже была 13 версия и странно попахивающее озеро негативных отзывов от пользователей. Кто-то из команды произнёс риторическое: «Challenge»? и остальные согласно кивнув, приступили к выполнению своей работы. Кто мог знать, что айсбергу только предстоит показать себя целиком.

Рекогносцировка на месте

Первым высадился десант из 5 тестировщиков. Провели разведку, присмотрелись – работы непочатый край.

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

На вопросы «как правильно должно работать приложение» ответ был «смотрите на стенды, как работает – значит так и правильно». А на вопрос как проверить правильность отчетов, звучал ответ – «распечатался – значит все хорошо».

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

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

Развертывание лагеря

Мы определили для себя такие основные задачи:

  • проанализировать текущие кейсы regress и smoke;
  • определить какие из них актуальны для текущего функционала;
  • переработать нужные кейсы, сделав их актуальными;
  • прогнать актуальные regress и smoke-тесты.

Для выполнения этих задач было необходимо:

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

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

Оценка работ и сбор отряда

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

Для смоук-тестов мы решили оставить старое количество кейсов, потому что стояло требование укладываться с ними в 1 день. Основной упор делался на то, что кейсы должны быть актуальны, максимально понятны и покрывать основной функционал -1 приоритета (блокеры).

При этом регресс-тесты мы серьезно расширили, до 2000 штук, потому что именно такое количество позволяло оптимально покрыть функционал.

В итоге у нас получилось:

  • 129 человеко-часов на смоук;
  • 1250 – на регресс;
  • 1000 – на кейсы TFS;
  • 1000 – на доработку кейсов по новым багам в
    почтовом TFS;
  • 1550 – на смоук, 12 раз в течение трёх месяцев;
  • 1033 – на смоук, 8 раз в течение двух месяцев;
  • 7343 – на доработку кейсов (с учетом рисков).

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

  1. Можно было заняться доработкой существующих кейсов смоука и регресса без учета дефектов, увеличив команду с 5 до 6 человек.
  2. Можно было заняться тестированием, и обработкой дефектов, заведенных командами тестирования до нас и дефектов с прода, расширив команду до 14 человек.
  3. Если дорабатывать кейсы по дефектам и тестировать их, то нужно было уже 17 человек.
  4. Чтобы выполнить все задачи на проекте, можно было увеличить команду до 20 человек.

Так как на проекте уже была одна команда, они взяли на себя тестирование доработок, а мы взяли в работу все остальные задачи. Так наша команда была увеличена до 17 тестировщиков!

Оружие добывать в бою!

На самом деле количество тестировщиков на проекте определялось не только на основании указанных выше параметров. Приходилось учитывать также ограниченный бюджет. Чтобы и работа двигалась, и в бюджет вписаться, мы собрали для заказчика команду со значительной долей хоть и многообещающих, но джуниоров. Конечно не стоит думать, что мы просто бросили необстрелянных бойцов на амбразуру. Кто знаком с нашим подходом или работал с нами, тот знает – в ЛК уже как 5 лет работает отличная система наставничества и обучения. Каждый новичок имеет индивидуальный план погружения на проект с мануалами и ссылками на необходимые ресурсы. А на период отсутствия машин, обучение происходило с помощью видео, схем и таблиц, созданных более опытными первопроходцами из первого десанта.

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

Закрепиться на рубежах

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

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

Во-вторых, мы проанализировали те пособия и руководства, которые удалось найти, на их актуальность и собрали все полезные ссылки в едином документе, для удобства их использования.

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



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

А еще мы продолжаем работу по актуализации кейсов регресса. Например, в начале нашей работы было 1186 кейсов, которые покрывали около 25% функционала. И только 12 из них не требовали изменений. Еще 755 мы предложили исправить, а 316 и вовсе удалить. Вместо них появилось 1106 новых, которые мы предложили добавить. Так планируемое количество кейсов регресса выросло до 2050 и в нынешнем составе команды мы можем пройти его за 2 недели.

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

Сражение с багами

Проводя тестирование и анализируя ошибки с марта по май включительно, наша команда завела более 300 багов. Из них 10 – это блокирующие и 47 критичные. А также 173 средних и 132 низких.

Но самое главное достижение в том, что по сравнению с периодом, когда мы пришли на проект, количество ошибок, пропущенных на прод, уменьшилось практически втрое – с 61% в феврале до 23% в мае!

Чему мы научились

Несмотря на то, что проект только начинается и еще много всего предстоит сделать, мы традиционно подведем итоги того, чего мы уже добились.

  1. Мы снова убедились в том, что способны работать с проектами любой сложности: там где нет документации, нет структурированной информации, нет отчетов, нет даже четких ТЗ и доступа к машинам.
  2. Мы можем строить гибкие отношения и подстраиваться под любого заказчика – даже когда отсутствует желание клиента  делиться проектной информацией и объяснять задачи.
  3. Мы готовы самостоятельно искать пути повышения эффективности тестирования, лишь бы не тормозить и не простаивать. Даже брать на себя вопрос отладки и настройки рабочих машин.
  4. Наша система подбора персонала продолжает работать с минимумом сбоев. Даже попадая в атмосферу тяжелых проектов, неопытные тестировщики не паникуют, а пытаются найти решения, при поддержке опытных наставников. Сложности только помогают команде сплотиться и мы рады за наших ребят!
  5. Наши свежие джуны отлично показали себя в деле. При этом они быстро прокачали свой профессиональный уровень и помогли заказчику вписаться в ограниченный бюджет.
  6. Мы убедились в простой «мудрости тестировщика» и постигли QA дзен. Не все баги одинаково подлежат устранению. Есть те, которые точно нужно исправить, а есть такие, которые не стоит трогать, чтобы не поломать то, что и так работает.

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

А если вам нужно, чтобы кто-то пришел и разгреб ваши завалы, в которых не сохранилось ни базы, ни ТЗ, ни инструкций — у нас есть такой опыт. Обращайтесь к продаванам «Лаборатории качества» и мы возьмемся за ваш проект!

Об авторе

Редакция сайта

Поиск
Облако меток
8 марта (1)api (5)ISTQB FL (1)IT (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (2)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (2)ПОИНТ (3)Приёмочное тестирование (1)РИТ (1)Эльбрус (1)Юмор (2)автоматизация тестирования (7)аудит (2)аудит тестирования (2)аутсорс (5)баги (4)банковские приложения (1)бесплатный вебинар (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)галеры_qualitylab (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (3)ежемесячный отчет (14)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (2)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (22)лайф-хаки (4)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (3)обеспечение качества (13)обучение (8)онлайн-конференция (1)оптимизация тестирования (12)оффлайн тренинги (1)поздравление (2)поздравления (6)пользовательские истории (1)пример (2)проблемы (3)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (6)разработчики (1)распределенная команда (3)решения (4)ритейл-приложения (1)сертификация ISTQB FL (1)собеседование (1)специализация (2)с чего начать (2)тест-анализ (2)тестирование (49)тестирование безопасности (3)тестирование для бизнеса (2)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удаленная работа (1)удобство использования (2)управление проектами (3)управление рисками (1)успехи (6)целевая аудитория (3)юзабилити (3)
Получите совет