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