Вы когда-нибудь задумывались о том, что команде, которая что-то разрабатывает, тестировщик или разработчик автотестов на самом деле не нужен? Этой команде необходим человек, который будет совмещать свою роль с ролью тестировщика.
Давайте рассмотрим традиционное положение вещей.
Если у вас не agile, то у вас скорее всего есть:
-отдел разработки;
-отдел аналитиков;
-отдел тестирования
И все они могут одновременно работают над разными продуктами.
А если вы еще решили делать автоматизацию тестирования, то появляется еще отдел автоматизации тестирования. И для управления всем этим добром, как правило, нужен руководитель проектов (РП). А теперь внимание, что делать РП, у которой тестировщика нет? Или он ушел в отпуск, или заболел?
-Забивать на качество продукта?
-Ждать когда он вернется?
-И нести финансовые потери от несвоевременного запуска продукта или же наоборот, от того что продукт выпустили в «забагованном» состоянии.
Если же у вас agile, то проблемы остаются те же. Только тут, как правило 1 тестировщик и 1 разработчик автотестов на команду, как минимум.
И тут помимо озвученных вопросов, возникает еще вопрос:
-Что делать, если этих двух людей на один проект? Проект не генерирует такую нагрузку для двоих?
-Что делать, если разработчик автотестов отказывается заниматься функциональным тестрованием, если вы оставляете его одного в команде?
-Или же, если тестировщик не настолько компетентен, чтобы писать автотесты самостоятельно?
В своем докладе автор расскажет о том, что такое кроссфункциональная команда. Расскажет, как на своем примере «затащили» роль тестировщика в каждого члена команды, а также от безвыходности и необходимости автоматизации тестирования научили разработчиков писать и помогать поддерживать автотесты тестировщикам.
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.
Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:
Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).
Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно здесь и здесь).
Вопрос от тестировщиков: "Зачастую мне дают продукт на тестирование, но не выделяют достаточно времени. Как мне одобрить релиз, если я недостаточно протестировал?"
Вот мой ответ.
Если вы тестировщик, то мне странно слышать, что вы отвечаете за одобрение релиза. Решение, выходить ли в релиз – это бизнес-решение, а совсем не техническое. Оно, безусловно, базируется на технических соображениях, и вполне естественно предоставить отчет об этих соображениях. С точки зрения бизнеса было бы глупо игнорировать этот отчет. Однако не менее глупая ситуация возникнет, если бизнес спихнет бизнес-решение на технический персонал. Мы служим бизнесу, а не управляем им, и технари зачастую не имеют доступа к бизнес-информации.
Идея, что тестировщики могут разрешить или запретить релиз, легко проверяется. Попробуйте отказаться от релиза, пока не будете достаточно довольны тем, что вы знаете о продукте и тем, сколько именно вы знаете. Вы быстро получите результат.
Пожалуй, ни в одной компании не найдется двух идентичных и взаимозаменяемых сотрудников. Одни превосходно разбираются в техниках тест-дизайна и ювелирно пишут тестовую документацию, другие — мастера различных видов и типов тестирования. В процессе работы над проектами сотрудники, как правило, дополняют друг друга, что благотворно сказывается на конечном продукте.
Вся наша работа по обеспечению качества выстроена на основе глубокой экспертизы прикладной области. Для одних команд — это страхование, для других — финансовые инструменты, интернет-банкинг или биржевая торговля, для третьих — широкий сектор государственных проектов.
Секрет в том, что тестировщики должны не просто разбираться в прикладной области, а должны знать ее специфику и наиболее типичные ошибки, более того – должны понимать своих пользователей.
Именно поэтому мы так много времени и сил уделяем обучению и погружению наших сотрудников.
Негласно считается, что хороший менеджер – это родитель одного, а лучше двух и более детей. Никогда не задумывались, почему? Возможно, менеджер-родитель обладает преимуществом в планировании? Может быть, он умеет грамотно распределять задачи? Или тут что-то связано с декомпозицией и оценкой времени?
Секрет же менеджера-родителя кроется в отношениях. Хороший менеджер-родитель переносит паттерны общения со своими детьми в команду. Растит новичков, защищает их от внешних угроз (к примеру, от негатива смежных команд), проявляет участие в жизни каждого, радуется успехам и с родительским терпением принимает нас такими, какие мы есть. Мне приходилось работать под руководством разных людей в разных командах, и самое приятное – находиться под опекой менеджера-родителя. В теплой семейной атмосфере и работать, знаете ли, приятнее, и расти в профессии легче.
В этой статье мы поговорим о неминуемом – о появлении новичка в команде. Можно ли при этом обеспечить ему безопасное погружение, не создавая также угрозы команде и всему проекту?
Каждый тестировщик в своей практике сталкивается с необходимостью погружения в тот или иной проект: его активности, правила, подходы, устоявшуюся практику. Однако далеко не всегда данный процесс налажен, имеет продуманную структуру, собранную воедино документацию и наставника, который весь этот процесс самоотверженно курирует.
От того, правильно или неправильно начинается погружение сотрудника, зависят очень многие факторы:
как быстро тестировщик станет полезным на проекте?
как много времени на погружение придётся затратить тест-менеджеру?
насколько комфортным для сотрудника будет период ознакомления?
качественный ли информационный фундамент будет заложен на будущее?
В рамках данного доклада мы рассмотрим, как научиться правильно погружаться в проекты, чтобы в максимально короткие сроки становиться востребованным сотрудником и чувствовать себя комфортно на протяжении всего процесса погружения и после него.
Доклад будет полезен начинающим специалистам, для которых важно строить крепкую карьеру в сфере тестирования с самого начала, и тест-менеджерам, формирующим грамотную команду.
Каждый руководитель должен понимать, на что способна его команда в целом и каждый сотрудник в отдельности. Понимание это достигается применением тех или иных техник, и сейчас я расскажу Вам о своей практике на примере одного из проектов, на котором я работал еще до поступления в ЛК.
Итак, меня назначили на должность тимлида группы тестирования, состоящей из 8 человек (далее «команда»): 1 ведущего, 3 старших и 4 «обычных» специалистов. Имея экспертные знания о продукте, я пока еще не представлял уровень подготовки членов команды, из-за чего не был уверен в качестве тестирования сложных задач и не мог правильно выделить время на их проверку. Задача выбора исполнителя для каждой доработки и оценки трудозатрат решалась непросто и далеко не всегда эффективно. Работа шла по схеме «сами берите в работу те задачи, которые лучше знаете».
Статья написана в соавторстве с Г.А. Агеевой, доцентом кафедры иностранных языков №2 Иркутского национального исследовательского технического университета
Команда – это организм, все части которого дополняют друг друга; это сообщество людей, имеющих единую цель.
У сотрудников в слаженной команде есть одно общее дело, одна на всех задача, которая должна быть решена. Каждый хорошо знает свой участок работы и может помочь другим; они вместе продумывают свои действия. В команде нет чужих, поэтому в ней выстраиваются живые и близкие личные отношения. Равнодушное «это не входит в мои обязанности» в настоящей команде просто невозможно услышать.
Но как добиться такой идиллии в том случае, когда вы, руководитель, не видите свою команду, не имеете возможности пообщаться с людьми вживую, понять их эмоции? Об этом мы и поговорим в статье.
При написании статьи использовались материалы А.Смирновой, подготовленные в рамках конференции тестировщиков «Котэ»
Тестирование – очень динамичная сфера, которая постоянно развивается; каждый день появляются новые инструменты, материалы и подходы. Тестировщик – это «универсальный солдат», зачастую объединяющий в себе различные навыки: написание кода, управление ресурсами, владение основами дизайна и верстки, а также знания в более узких прикладных областях. Руководители проектных команд стараются повышать квалификацию своих ребят, отправляя их на всевозможные курсы и тренинги. Но как быть со стажерами, с «проектными новобранцами»? Как правильно, а главное, чему именно нужно научить стажеров (особенно в распределенной команде), чтобы у них не пропал интерес к профессии, и чтобы это обучение принесло пользу не только «новобранцу», но и всему проекту? Об этом мы и расскажем в нашей статье.
Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.
Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задач. При этом не всегда получается отказаться от старых обязанностей. Приходится совмещать две роли на проекте. Так и я, имея опыт в тестировании и аналитике, дополнительно стала получать задачи руководителя проекта. Со временем я полностью перешла в управление проектами.
В этой статье я делюсь наблюдениями и выводами. Как в одном человеке конфликтуют привычки тестировщика и обязанности руководителя проекта? С какими проблемами приходится сталкиваться? Какую пользу можно извлечь при таком переходе? Если хотите получить ответы на эти вопросы, добро пожаловать под кат.
