О нас

Добрый день, меня зовут Никита, я тестировщик программного обеспечения в компании Solit Clouds, мой опыт тестирования более 2,5 лет.

В текущий момент являюсь ответственным за тестирование мобильных приложений на Android.

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

• как в нашей компании создавалась команда тестирования мобильных приложений;

• какие на мой взгляд сложности встречаются при создании команды;

• а также, по возможности, рассказать, как мы справлялись с ними;

Статья носит исключительно ознакомительный характер, не является пособием.

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

• ЕМИАС - Государственная информационная система «Единая медицинская информационно-аналитическая система города Москвы»;

• EHR — высокопроизводительные решения обработки больших данных;

• iDVP — Interactive Data Visualization Platform, продукт для сбора больших объемов данных, их хранения, обработки, анализа и презентации.

Подробнее можно ознакомиться на сайте компании https://solit-clouds.ru/

О командах тестирования

Некоторые тезисы, от которых я буду отталкиваться:

Важно идентифицировать себя как часть команды, например, как:

• работник ИТ-индустрии;

• сотрудник конкретной компании;

• тестировщик в отделе тестирования компании;

• часть продуктовой команды тестирования, работающей над определенным продуктом;

• часть команды, отвечающей за тестирование определенной части продукта.

Так же команда определяется этапом планирования, если его нет, то, по сути, нет и команды.

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

• «кружок» или «тусовка», грубо говоря, люди объединены одними интересами, они хотят «делать», у них есть неформальный лидер. Он скорее «расшатывает» команду, а не приводит её к конкретной цели. Какой-то формализации или прогнозирования внутри команды нет;

• «отряд» — им управляет жёсткий, но неформальный лидер, дисциплина, групповые ценности здесь выше индивидуальных;

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

• «Команда» - содружество равных, тех, кто желает друг с другом работать, а главное умеет работать и в состоянии справляться с очень сложными задачами.

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

От того куда направлены члены команды зависит её согласованность и успех мероприятия.

Выделяю 3 основных уровня направленности члена команды:

• Ориентирование либо на себя - «Моя самореализация важнее всего остального»;

• Либо на социальную общность – «Отношения в команде для меня важнее задач»;

• Либо ориентация на деятельность - «Задачи важнее всего».

Необходимо соблюдать баланс, между уровнями. Идеальный вариант, когда все 3 направления человек может реализовать в равной степени. Если же будет сильно «западать» один из уровней, то это, скорее всего, вызовет проблемы и отразится на продуктивности работы. Стоит учитывать личные качества сотрудников при планировании команды.

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

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

Изначальное состояние команды тестирования мобильных приложений

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

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

Вот что было сделано:

• самоподготовка в теории тестирования мобильных приложений;

• прохождение соответствующих курсов;

• погружение в особенности продукта;

• анализ и проработка необходимых устройств;

• планирование задач проекта, как первостепенных, так и вторичных по важности;

• а также, лидер команды начал погружение в ключевые вопросы, аспекты и сложности его работы, с учётом формирования самой команды.

Значимым фактором, на мой взгляд, была «плавность» перехода.

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

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

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

Структура команды

На старте в команду входили 3 специалиста, отвечающие за разные направления:

• тимлид (ТЛ) команды, обладающий общими знаниями тестирования на 2 платформах;

• назначен ответственный за тестирование платформы iOS;

• назначен ответственный за тестирование платформы Android.

После первичного распределения зон ответственности было начато тестирование первых сборок приложения.

Если задастся вопросом «кто такой ТЛ в нашей команде?»
ТЛ – достаточно жесткий, чтобы сказать «вот рамки», «вот сроки», решить кризисы, конфликты, столкновения внутри команды в сжатые сроки. Взять ответственность за команду.

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

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

Заранее, были разделены обязанности:

• Создание тестовой документации, которая у продукта отсутствовала. В данной активности принимали участие все члены новой команды;

• Подготовка вводного материала для новичков в мобильном тестировании с нуля;

• Создание Базы Знаний (БЗ) тестируемого продукта;

• Планирование и оценка трудозатрат и возможностей команды. Планирование активностей легло на плечи ТЛ, в оценке трудозатрат участвовали все члены команды.

  В процессе работы рос как функционал, так и состав команды.

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

  Для достижения данной цели как раз и были использованы материалы, подготовленные заблаговременно.
  В Базу Знаний самого продукта были уже добавлены:

• Глоссарий терминов;

• Состав участников команды и смежных отделов, для быстрой коммуникации;

• Регламенты работы с задачами и «фичами»;

• Проработан регламент создания тестовой документации и тестовых данных;

• Инструкции по настройке оборудования, инструментов тестирования, обхода сложных ситуаций, возникающих из-за особенностей тестирования;

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

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

Кроме того, все «джуны», которых мы принимаем в штат Solit Clouds, проходят базовое обучение, которое обеспечивает их стартовыми знаниями, а также систематизирует существующие по тестированию для выполнения задач начального уровня

Для новичков были назначены кураторы, контролирующие работу и прогресс.

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

Все это является необходимым для начала работы.

Структура сформированной команды

Подведу итоги

За более чем полгода мы создали команду, способную производить тестирование нескольких фич на 2 платформах одновременно.
При этом поддерживая однообразие в приложениях IOS и Android.

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

Автор: Никита Гаевский