Пожалуй, ни в одной компании не найдется двух идентичных и взаимозаменяемых сотрудников. Одни превосходно разбираются в техниках тест-дизайна и ювелирно пишут тестовую документацию, другие — мастера различных видов и типов тестирования. В процессе работы над проектами сотрудники, как правило, дополняют друг друга, что благотворно сказывается на конечном продукте.
Вся наша работа по обеспечению качества выстроена на основе глубокой экспертизы прикладной области. Для одних команд — это страхование, для других — финансовые инструменты, интернет-банкинг или биржевая торговля, для третьих — широкий сектор государственных проектов.
Секрет в том, что тестировщики должны не просто разбираться в прикладной области, а должны знать ее специфику и наиболее типичные ошибки, более того – должны понимать своих пользователей.
Именно поэтому мы так много времени и сил уделяем обучению и погружению наших сотрудников.
Избыток документации и проблемы с погружением
Согласитесь, любой проект требует определённого времени для погружения в него. И неважно, маленький он или большой, государственный или коммерческий, все равно, прежде чем стать полноценным членом проектной команды, придется пройти путь становления. Вот и на одном государственном проекте, где команда тестирования состояла из чуть более 50-ти человек, мы с вводом нового человека сталкивались с необходимостью его интегрирования:
- В процессы, описанные в многочисленных регламентах.
- В предметную область, которая подробно раскрывается во множестве огромных томов нормативно-правовых актов Российской Федерации.
- В бизнес-логику отдельных подсистем (а их более сотни) и, что не менее важно, в особенности взаимодействия между собой этих подсистем.
- В используемые технологии и инструменты на проекте: серверные “мониторы”, инструменты для работы с логами, API (SOAP и REST), огромная база данных на PostgreSQL и прочее.
Что делать в такой ситуации? Особенно если сотрудник должен прийти на проект, а уже через две недели показать “класс”? Как его обучать? Как бы ни хотелось минимизировать свои затраты на этот процесс и попросту завалить новичка тонной информации в надежде, что он сам как-нибудь разберётся и через две недели его будет не отличить от опытных бойцов, выбрать нужно все-таки системный подход.
Что из себя представляет системный подход?
1. Каждого “новобранца” на проекте встречает объёмный документ, который, повествуя о великих перспективах, то и дело подводит к нужным документам и регламентам, необходимым сотруднику в первые дни его работы. Именно этот документ заменяет того самого наставника первых дней, который берет за руку и водит по важным местам проекта. А еще он высвобождает массу времени по одной простой причине: документ создавался после анализа многочисленных вопросов, задаваемых предыдущими новичками. Анализ — это важно!
2. Очень важно, чтобы сотрудник понимал не только то, как функционирует продукт, но и его логику с точки зрения бизнеса. А весь бизнес описан на уровне нормативно-правовых актов РФ, потому нам еще и приходилось учить сотрудников тонкостям юриспруденции! Сначала сотрудника информировали о разных организационных формах предприятий в РФ, а дальше плавно переходили к предметной области в разрезе сравнения “законодательство — ТЗ — наглядная функциональность перед глазами”, а в конце делался контрольный срез с ответами на такие вопросы:
3. Далее погружение переходило к этапу прохождения непосредственно регрессионного чек-листа. Сквозной бизнес-процесс, который начинается от регистрации пользователя и, пройдя через десятки ключевых подсистем по логической цепочке, завершается в виде отчета или некоего финального действия вроде оплаты пользователем. Таким образом, погружающийся имел возможность познакомиться со сквозными ключевыми бизнес-процессами и увидеть, каким образом главные подсистемы интегрируются между собой.
4. Далее в индивидуальном порядке определялись последующие этапы для погружения: кто слаб в SoapUI, подтягиваем его в нем, других в SQL или Excel-интеграции; системный мониторинг слабоват — пожалуйста, прокачиваем сотрудника здесь. Для каждого направления свои наборы материалов, свои контроли. Например:
5. На этом этапе начинается самое интересное — работа. Несмотря на то, что все предыдущие этапы тоже делались на реальных данных и в реальных условиях, на этом этапе уже наступает персональная ответственность за качество теста. Но при этом к сотруднику приставляется наставник, который направляет, указывая путь к свету.
Весь этот путь длится две недели, после чего сотрудник демонстрирует приобретённые знания и достижения перед руководителем тестирования на проекте и своим тест-менеджером и наставником. По итогам защиты формируется список рекомендаций по тем моментам, которые необходимо улучшить, и наступает заключительный этап.
Финал. Спустя три месяца сотрудник проходит последний контроль — проектную аттестацию, в рамках которой независимый менеджер подгруппы по тестированию проводит опрос по следующим направлениям:
- регламентированные производственные процессы;
- использование технологий и инструментов на проекте;
- ключевые бизнес-процессы продукта;
- теория тестирования (да-да, нам важно и это).
Небольшой блок из базы вопросов:
Вся аттестация протоколируется, и каждый ответ оценивается по утвержденной 5-балльной шкале. Далее выводится средняя оценка и рекомендации по необходимым улучшениям. Вся эта информация агрегируется в профайл сотрудника и будет доступна руководству тестирования до последнего дня пребывания сотрудника на проекте.
Дашборд профайлов сотрудников:
Это все? Нет. Теперь каждый квартал этот сотрудник, как и ряд других, будет проходить упрощенную аттестацию по той же схеме, подтверждая свою квалификацию независимому линейному руководителю, а в его профайле будет показываться динамика роста его квалификации.
Много ли времени уходит на ежеквартальные аттестации? Признаться, не мало, но оно того стоит, потому что уже через год работы на проекте сотрудники имеют очень высокий уровень погруженности в бизнес-логику продукта, в технологии, без проблем справляются со сложными техническими задачами и грамотно подходят к вопросу применения тест-анализа и тест-дизайна.
Недостаток информации или ее полное отсутствие
На проекте в сфере финансовых инвестиций, мы с умом подошли к проблеме отсутствия документации и полностью ее решили. Как? — Написали расширенные тест-кейсы и согласовали их с заказчиком. При старте проекта команда получила вводную от заказчика: “На данный момент у нас нет какой-либо документации, сможете протестировать систему и задокументировать текущий функционал в тест-кейсах?” Мы ответили: “Да. Легко!”.
Для начала команда разработала шаблон, который позже был отправлен заказчику на согласование. Обсудив мелкие непонятные детали с заказчиком, мы согласовали шаблон будущих тест-кейсов и приступили к описанию системы.
Описываем реализованный функционал в тест-кейсах, согласовываем с заказчиком
В процессе написания тест-кейсов мы обнаружили калькуляторы прогноза, показывающие на выходе несколько значений (по типу кредитного калькулятора). Для тестирования и описания в тест-кейсах, необходимо было знать, по каким формулам выполняется расчет итоговых значений. Однако на тот момент заказчик нам их не предоставил. Часть расчётов удалось понять и описать самостоятельно. Остальное – в подробных формулах получили от заказчика. В итоге все формулы целиком и полностью были зафиксированы в тест-кейсах. Все тест-кейсы были написаны подробнейшим образом, включая всевозможные варианты граничных значений, позитивное и негативное тестирование.
Далее эти тест-кейсы передали заказчику на проверку и согласование.
Утверждение тест-кейсов прошло практически без вопросов и замечаний. И в скором времени мы качественно протестировали продукт.
Не боимся заменить команду и сотрудничаем с аналитиком
Все новые доработки мы сначала описываем в тест-кейсах, согласовываем с заказчиком и только после этого приступаем к тестированию.
Зачем тратить время на такое подробное описание и почему нужно писать тест-кейсы перед тестированием? Ответы просты:
- Мы не боимся, что опытный сотрудник, владеющий глубокой экспертизой, заболеет или уволится.
- В любое время можно полностью заменить состав команды, даже на стажёров (пройдя систему по таким тест-кейсам, они поймут как саму систему, так и принципы тестирования, и, не имея особых знаний, будут применять их в будущем).
- Сокращаются возможные риски, возникающие при написании ТЗ разными участниками процесса.
- Все недочёты в документации выявляются ещё до начала тестирования.
Итак, благополучно преодолевая все сложности погружения в новые проекты, в этом месяце к нам присоединились 2 специалиста по ручному тестированию, 4 автоматизатора, 1 Тест-менеджер и 1 маркетинговая фея.
