Идеальная IT-команда глазами Quality Assurance

Александра Новицкая

Старший специалист по тестированию в ГК Юзтех

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

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

Дисклеймер В статье я описываю личный опыт и личное мнение, которое может отличаться от вашего. Мне будет интересно почитать ваши истории и ваш взгляд на командную работу в QA сфере.

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

Погружение в проект

Опираясь на известный мне опыт работы в проектах, я выделила наиболее критичные ошибки погружения QA специалиста в проект:

• Позднее включение QA специалиста в разработку или инициирование проекта без QA специалиста;
• Оценка на тестирование со стороны менеджмента: QA специалист не оценивал объемы;
• Отсутствие майнд-карты проекта: как правило, нет времени на отрисовку;
• Устаревшие источники данных: нет актуальной информации в задачах или в составе команды;
• Управление проектом: акцент на процесс, а не на результат.

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

• Майнд-карта проекта: показывает масштаб и границы проекта, навигатор системы;
• Артефакты проекта: показывают условия реализации и объемы проекта;
• Чек-лист проекта: позволяет определить инструментарий и готовность начала работ на проекте;
• Оценка по объему работ: показывает вероятность попадания в заявленные дедлайны;
• Риски по объему работ: показывают возможные пределы гибкости проекта.

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

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

И ещё один немаловажный вопрос — это насколько наличие этих помощников востребовано у участников проекта? Безусловно это зависит от срока жизни проекта: одноразовый короткий проект имеет другие результаты в отличие от корпоративных глобальных проектов для широкой интернет аудитории. Также востребованность зависит от умения понимать возможности инструмента и применять его для достижения лучших результатов по задачам проекта.

Работа с требованиями

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

Работа с требованиями на проекте — это время волшебных коллабораций в команде! От этого зависит результат проекта, в том числе и профит проекта как для участников команды, так и для руководителя проекта.

Разнообразие источников, как правило, путает и дезориентирует участников, а также увеличивает срок принятия решений на проекте. Тем более, если приём и хранение документации не организованы должным образом.

Как участникам команды ориентироваться в этом многообразии и чему верить? Вновь прибывшие изменения требований или новые доработки не всегда своевременно проходят этап валидации, что также даёт свои очевидные минусы: ломается старая или ранее выполненная реализация, а это боль команды в виде регресса и новых костылей.

Кто же знал, что эти доработки окажут такое влияние на реализацию? Отсюда вытекающая проблема — отсутствие трассировки: сделал одну задачу — работает, добавили — что-то отвалилось или всё упало.

А где вся документация и сопутствующие артефакты хранятся? Есть несколько вариантов: или локально у участников, или в папках вне проекта, или в неочевидных папках проекта. Как в таком случае обойтись без лишней бюрократии и проволочек?

Для начала необходимо определить, что будет являться основным источником требований — куда будут смотреть все участники команды с уверенностью, что тут все актуальные требования с учётом последних изменений. Это позволит не только снизить скорость на поиск актуальных требований, но и повысить качество и скорость выполнения задач на проекте.

Но как своевременно актуализировать и связывать требования? Это ответственность каждого участника команды проекта: выявил изменение → согласовал изменение → зафиксировал. Это не делает каждого участника документоведом, а только показывает уровень ответственности участника в командной работе.

То, как вы это сделаете — оставите комментарий в документе или в задаче, или создадите отдельную задачу для других участников в команде — это уже второстепенный вопрос. Сначала это может показаться трудоёмким делом, отнимающим ресурсы, но тут ведь главное начать, а дальше эта привычка становится неотъемлемой частью твоей работы и приносит ощутимые результаты в рабочем проекте.

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

Вопрос хранения актуальных требований на сегодня реализуется с использованием различных готовых решений (например, Confluence). Главное, чтобы участникам проекта было комфортно работать с артефактами для выполнения своих задач.

DEV&QA

Вот мы и на кухне, как говорится! Все проекты у нас разные, и процессы в них выстраиваются по-разному. Это зависит и от специфики самого проекта, и от опыта руководителя проектов и, конечно же, от опыта участников команды. С чем же приходится сталкиваться QA специалисту на проекте?

• Сложная декомпозиция задач;
• Ленивое использование workflow задач;
• Отсутствие линков на зависимые задачи;
• Ленивое описание задач и результатов;
• Неактуальные комментарии в задачах;
• Не организована отгрузка задач QA специалиста;
• QA специалист является узким бутылочным горлышком;
• Руководитель проекта — тестировщик на проекте.

Самое интересное — это жизнь задач на проектах. Пришёл объем → нарезали → раздали, работаем! И вот на митинге радостно заявили о передаче задач в тестирование — челлендж объявляется открытым!

Идем в задачи… Задачу не перевели.Идем на стенд… Ещё не подлили на стенд.
Открываем задачу… Описание настолько краткое и ёмкое, что становится непонятно, с какого это пункта ТЗ.
Есть зависимые задачи — статус в процессе. Хм, а комментарий в этой задаче ещё актуальный?
Подлили, открываем стенд — а почему не так, как в требованиях? Это баг или фича?
Так обойдя череду препятствий, задача проверена! Но уже все залили на прод…
Подъехали срочные задачи с другого проекта… Бежим дальше…

Обращаю ваше внимание, что это реальная история на проекте. Да, так бывает.

Как избежать подобных ситуаций? Взращивать командную ответственность!

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

• Dev&QA = Пилот&Штурман;
• Меньше ожиданий, больше инициативы;
• Общая заинтересованность в результате;
• Критерии передачи / приёмки: кто, кому и как;
• Качество обратной связи.

Задача участников проекта — своевременно выявить и сообщить, задача руководителя проектов — оперативно отреагировать и принять решение.

Артефакты проекта

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

• От входа на проект: где мы проводим анализ и оценку, формируем обратную связь;
• До выхода из проекта: где мы передаем проект с актуальными результатами и выявленными рисками.

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

Со стороны QA специалиста могут быть подготовлены разные артефакты: от тест-плана до отчётов по тестированию. Востребованность в артефактах зависит от потребностей проекта и специфики проекта. Главная задача QA специалиста — определить оптимальный набор артефактов и подготовить обратную связь руководителю проектов по статусу артефактов (как на входе на проект, так и на выходе из проекта), а задача руководителя проектов — проанализировать обратную связь и предупредить возможные риски.

Заключение

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