О нас
Добрый день, меня зовут Никита, я тестировщик программного обеспечения в компании Solit Clouds, мой опыт тестирования более 2,5 лет.
В текущий момент являюсь ответственным за тестирование мобильных приложений на Android.
В данной статье я хочу поделиться опытом с точки зрения непосредственного участника процесса, а именно:
как в нашей компании создавалась команда тестирования мобильных приложений;
какие на мой взгляд сложности встречаются при создании команды;
а также, по возможности, рассказать, как мы справлялись с ними;
Статья носит исключительно ознакомительный характер, не является пособием.
Одним из основных направлений деятельности нашей компании является разработка программного обеспечения в области здравоохранения, а именно:
ЕМИАС - Государственная информационная система «Единая медицинская информационно-аналитическая система города Москвы»;
EHR — высокопроизводительные решения обработки больших данных;
iDVP — Interactive Data Visualization Platform, продукт для сбора больших объемов данных, их хранения, обработки, анализа и презентации.
Подробнее можно ознакомиться на сайте компании https://solit-clouds.ru/
О командах тестирования
Некоторые тезисы, от которых я буду отталкиваться:
Важно идентифицировать себя как часть команды, например, как:
работник ИТ-индустрии;
сотрудник конкретной компании;
тестировщик в отделе тестирования компании;
часть продуктовой команды тестирования, работающей над определенным продуктом;
часть команды, отвечающей за тестирование определенной части продукта.
Так же команда определяется этапом планирования, если его нет, то, по сути, нет и команды.
Существует огромное множество классификаций команд, от хаоса до формализации. Я, условно, обозначу их по мере организации осознанности членов команды и их самостоятельности:
«кружок» или «тусовка», грубо говоря, люди объединены одними интересами, они хотят «делать», у них есть неформальный лидер. Он скорее «расшатывает» команду, а не приводит её к конкретной цели. Какой-то формализации или прогнозирования внутри команды нет;
«отряд» — им управляет жёсткий, но неформальный лидер, дисциплина, групповые ценности здесь выше индивидуальных;
«кооперация» - характеризуется наличием лидера, признанного коллективом, четкая определенность функционала каждого члена команды в рамках коллектива, но также свободой действия в рамках выполнения его задач;
«Команда» - содружество равных, тех, кто желает друг с другом работать, а главное умеет работать и в состоянии справляться с очень сложными задачами.
В нашем случае, благодаря решениям руководителей и подбору специалистов, удалось собрать коллектив, который в большей степени соответствовал «кооперации», и стремится в сторону «команды». Важная цель при создании команды - прогнозирование того, куда команда двинется дальше, что будет делать через месяц, два месяца. Справляется ли она с задачами, срабатывается коллектив или нет.
От того куда направлены члены команды зависит её согласованность и успех мероприятия.
Выделяю 3 основных уровня направленности члена команды:
Ориентирование либо на себя - «Моя самореализация важнее всего остального»;
Либо на социальную общность – «Отношения в команде для меня важнее задач»;
Либо ориентация на деятельность - «Задачи важнее всего».
Необходимо соблюдать баланс, между уровнями. Идеальный вариант, когда все 3 направления человек может реализовать в равной степени. Если же будет сильно «западать» один из уровней, то это, скорее всего, вызовет проблемы и отразится на продуктивности работы. Стоит учитывать личные качества сотрудников при планировании команды.
В каждой команде есть расходящиеся мнения, подкрепленные опытом и знаниями, которые рано или поздно столкнуться, что и приводит к конфликтным ситуациям, это нормально и не всегда является проблемой. Столкновения мнений приводит к развитию команды и совершенствованию, желанию сконцентрироваться на поиске решения, задуматься над тем, как мы подходим к задачам и как реализовать их максимально эффективно.
Камнем преткновения может стать что угодно, например, практический опыт и понимание в написании тестовой документации. В одних проектах, в угоду скорости тестирования и погруженности в продукт, отдают предпочтение использованию чек-листов, в других есть необходимость в максимально подробных тест-кейсах.
В такие моменты нужно искать компромисс и делиться опытом, быть открытым для обсуждения, что именно в текущий момент важнее и как это повлияет на продукт. В общем, нужно прийти к общему знаменателю.
Изначальное состояние команды тестирования мобильных приложений
В команду входил 1 тестировщик с опытом тестирования подобных продуктов, прошедший обучение тестированию мобильных приложений.
После принятия решения создать команду тестирования мобильных приложений, руководством отдела тестирования были проведены плавные перестановки специалистов из разных команд и заблаговременная подготовка членов будущей команды - отобраны подходящие кандидаты.
Вот что было сделано:
самоподготовка в теории тестирования мобильных приложений;
прохождение соответствующих курсов;
погружение в особенности продукта;
анализ и проработка необходимых устройств;
планирование задач проекта, как первостепенных, так и вторичных по важности;
а также, лидер команды начал погружение в ключевые вопросы, аспекты и сложности его работы, с учётом формирования самой команды.
Значимым фактором, на мой взгляд, была «плавность» перехода.
У участников команды было несколько месяцев для изучения материала, контроль и помощь со стороны опытных специалистов.
Немаловажную роль сыграло то, что будущие члены команды были помещены в один продукт, на стадии подготовки, не относящийся к целевой команде, благодаря этому коллеги, работая вместе, притирались друг к другу, обмениваясь знаниями и опытом. Это помогло избежать дополнительных столкновений опыта и мнений в новой команде и более продуктивно начать работу над тестированием новых приложений.
Не секрет, что для продуктивной команды крайне необходимо продумать взаимозаменяемость ключевых участников команды на случай отпуска, больничного и т. д. Разумеется, мы это предусмотрели.
Структура команды
На старте в команду входили 3 специалиста, отвечающие за разные направления:
тимлид (ТЛ) команды, обладающий общими знаниями тестирования на 2 платформах;
назначен ответственный за тестирование платформы iOS;
назначен ответственный за тестирование платформы Android.
После первичного распределения зон ответственности было начато тестирование первых сборок приложения.
Если задастся вопросом «кто такой ТЛ в нашей команде?»
ТЛ – достаточно жесткий, чтобы сказать «вот рамки», «вот сроки», решить кризисы, конфликты, столкновения внутри команды в сжатые сроки. Взять ответственность за команду.
У нас был подобран такой человек с необходимым уровнем компетенций, который и стал именно признанным лидером, ко мнению которого прислушиваются, но который, со своей стороны, может выслушать и выслушает мнение каждого члена команды. Человек способный оценить качества, черты и компетенции сотрудников.
На роли ответственных за платформы были выбраны сотрудники, обладающие достаточным практическим опытом в тестировании ПО, которые быстро выполняют поставленные задачи, быстро погружаются в продукт. Они способны наладить и вести вместе с ТЛ работу между различными подразделениями, чтобы выполнять задачи различной сложности, а также, делиться своим опытом между членами команды.
Заранее, были разделены обязанности:
Создание тестовой документации, которая у продукта отсутствовала. В данной активности принимали участие все члены новой команды;
Подготовка вводного материала для новичков в мобильном тестировании с нуля;
Создание Базы Знаний (БЗ) тестируемого продукта;
-
Планирование и оценка трудозатрат и возможностей команды. Планирование активностей легло на плечи ТЛ, в оценке трудозатрат участвовали все члены команды.
В процессе работы рос как функционал, так и состав команды.
Были набраны тестировщики-новички, которых нужно было обучать интегрировать в процесс в максимально короткое время.
Для достижения данной цели как раз и были использованы материалы, подготовленные заблаговременно.
В Базу Знаний самого продукта были уже добавлены:
Глоссарий терминов;
Состав участников команды и смежных отделов, для быстрой коммуникации;
Регламенты работы с задачами и «фичами»;
Проработан регламент создания тестовой документации и тестовых данных;
Инструкции по настройке оборудования, инструментов тестирования, обхода сложных ситуаций, возникающих из-за особенностей тестирования;
Была создана программа погружения в мобильное тестирование и программа погружения в продукт, включающая тестовые прогоны по готовому функционалу и другое.
Стоит так же упомянуть, что данный материал пригодился для обучения подключаемой, в процессе, команды внешних тестировщиков, с целью усиления, для выполнения конкретных задач.
Кроме того, все «джуны», которых мы принимаем в штат Solit Clouds, проходят базовое обучение, которое обеспечивает их стартовыми знаниями, а также систематизирует существующие по тестированию для выполнения задач начального уровня
Для новичков были назначены кураторы, контролирующие работу и прогресс.
Обратная связь играет большую роль не только в обучении. Важным фактором для ментора, является предоставление обратной связи не только в конце проделанной новичком работы, но и контроль в процессе. Чем раньше будет скорректирована работа при отклонении, тем лучше и быстрее будет достигнут результат, тем точнее и быстрее будут выявлены слабые стороны, на которые нужно обратить внимание.
Все это является необходимым для начала работы.
Структура сформированной команды
![](https://habrastorage.org/getpro/habr/upload_files/ba8/5a2/c11/ba85a2c112d1236e64eb10311d474a8f.png)
Подведу итоги
За более чем полгода мы создали команду, способную производить тестирование нескольких фич на 2 платформах одновременно.
При этом поддерживая однообразие в приложениях IOS и Android.
Наша команда способна принять и обучить в краткие сроки нового сотрудника, а также поддерживать развитие знаний и навыков всего коллектива подразделения.
Автор: Никита Гаевский
VanStiller
О чем статья? Просто мысли вслух о том, как устроена ваша команда тестирования?
Сколько уже видел подобных простынь состоящих на 90% из воды, без какой либо конкретики.
По каким параметрам вы определили, что у вас продуктивная команда? Конкретики никакой
Огромное количество вопросов возникает к содержимому:
"Важно идентифицировать себя как часть команды" тезис совершенно лишенный смысла. Нужно работать в команде, а идентифицировать себя можно хоть белкой, хоть камнем
Очень странное деление на "классификации команды". По сути речь о том, что в разных командах у лидеров есть разные привилегии и обязанности. Ваши "кружок", "отряд" и "кооперация" по сути одно и тоже
"Так же команда определяется этапом планирования, если его нет, то, по сути, нет и команды."
Это не так, команда может существовать и эффективно работать без четких горизонтов планирования. Автор никогда не работал на поддержке уже существующего проекта?
Удалось собрать коллектив, который в большей степени соответствовал «кооперации», и стремится в сторону «команды»
Это как выглядит на практике? У вас есть условный тимлид, и потом вы хотите его раскулачить до рядового тестера? И какую цель вы хотите этим достичь?
У нас был подобран такой человек с необходимым уровнем компетенций, который и стал именно признанным лидером, ко мнению которого прислушиваются, но который, со своей стороны, может выслушать и выслушает мнение каждого члена команды. Человек способный оценить качества, черты и компетенции сотрудников. Неплохая попытка подлизаться к тимлиду, респект) Не забудьте ему скинуть ссылку на вашу статью))
"За более чем полгода мы создали команду, способную производить тестирование нескольких фич на 2 платформах одновременно"
Это какое-то достижение для вашей команды? Было бы странно, если бы так не было, зачем иначе нужен отдел тестирования
"Наша команда способна принять и обучить в краткие сроки нового сотрудника, а также поддерживать развитие знаний и навыков всего коллектива подразделения." есть подозрение, что в вашей выборке участвовало пара человек, которых вы обучили. Не рановато ли делать выводы о результатах?
В общем подведу итог: автор попытался создать обучающую статью на примере своей команды. Причем никаких нестандартных решений здесь не было показано, так работает подавляющее большинство команд. Сложилось мнение что это вообще первый опыт работы у автора, впрочем это и неудивительно при всего 2.5 годах опыта. Рановато ему еще думать о командах, сначала стоит получить опыт хотя бы в нескольких проектах.