Типичная команда тестирования – это набор таких разных людей, как бизнес-эксперт, системный программист, пара-тройка технарей-тестировщиков и (иногда) менеджер.
Опытный менеджер знает, что один из тестировщиков интересуется мобильными приложениями, а другой - API, и старается нагружать их соответственно их интересам. Однако тут сразу возникают некоторые трудности. Что, если рабочая нагрузка просто не позволяет такого распределения? Например, эксперт по мобильным приложениям в отпуске, или члены команды жалуются, что годятся менеджеру как специалисты только в определенном качестве?
Что делать разумному менеджеру в таких случаях? Об этом мы и поговорим.
Ваша команда упорно трудилась над итерациями, и потратила кучу времени на разработку новой функциональности. И вот настал тот день, когда все готово к релизу. А действительно ли оно готово?
Как вы определяете, что вы можете выпускать ваше детище в релиз? Кто скажет "Поехали" и махнет рукой? Что именно нужно обязательно сделать перед релизом?
Вы постоянно заботитесь о качестве вашего продукта, и точно также вы должны беспокоиться об улучшении и оптимизации вашей релизной деятельности.
Хорошо налаженное управление релизом может как помочь, так и уничтожить ваш продукт, а также сберечь нервы и команде, и пользователям. Современные команды зациклены на том, чтобы выйти в релиз как можно быстрее. Это круто, но ставя такую цель, легко забыть о ряде важных моментов.
Команды состоят из множества разных людей, владеющими различными навыками и выполняющими различные роли. Каждая из ролей видит продукт по-своему и использует его специфически, да и сам продукт влияет на разные роли по-разному. Очень важно поразмышлять над этим перед релизом, а не только поинтересоваться, протестировано ли ПО. Тестирование, конечно, важная вещь (и позднее мы поговорим об этом), но релиз - это не только и не столько разработка, тестирование и выпуск в большой мир.
Чем лучше вы и ваши клиенты готовитесь к релизу, тем счастливее вы станете.
Вот на что стоит обратить внимание, когда релиз не за горами:
Работать в Agile-команде, по определению ориентированной на сотрудничество - во многих отношениях непростая задача. К примеру, мне, да и не только мне, очень трудно найти верный баланс между необходимостью взаимодействовать с коллегами и потребностью в сохранении своих коммуникативных способностей.
Я интроверт. Это совершенно не означает, что я застенчивая, или тихоня, или стою особняком от окружающих (хотя иногда я именно такая). Да, я люблю хорошенько все обдумать, прежде чем высказываться, но это тоже не то, что выделяет интровертов из толпы. Простейшее определение интровертов, которое мне подходит, звучит так:
"Интроверт расходует энергию на разговоры. Экстраверты от разговоров подзаряжаются".
Вот вам пример. Раньше я работала тестировщиком в Agile-команде с двухнедельными Scrum-спринтами. Каждый четверг мы устраивали трехчасовую встречу по планированию спринта (с 9 утра до 12 дня), на которой обсуждались пользовательские истории, ставились задачи, оценивались временные затраты, и утверждался бэклог на спринт.
Эта встреча рушила мне весь рабочий день. Многие из моих коллег покидали ее, бурля от полученной информации и предвкушая старт интересных задач. Я чувствовала себя совсем разбитой и не могла делать ничего полезного вплоть до утра пятницы. Вот она, разница между экстравертами и интровертами.
Мне никогда не нравился подход, при котором тестировщики отделены от основной команды и подключаются к работе на соответствующие "фазы" тестирования. Я проработал так около восьми лет, и все это время бился над ответами на следующие вопросы:
Почему мы так поздно подключились к проекту?
Почему в нем так много очевиднейших багов и проблем?
Почему продукт не соответствует спецификации?
Почему из раза в раз мы гоняем одни и те же кейсы и на этом основании считаем, что продукт готов и тестирование завершено?
Почему бы тестировщикам не начать задавать вопросы на более ранних стадиях разработки продукта?
Почему такие навыки тестировщика, как тест-дизайн, организационные способности, критическое мышление совсем не ценятся под конец проекта?
Почему некоторые тестировщики высоко специализированы - например, тестировщики производительности - но при этом куча прочих тестировщиков просто "гоняет любые функциональные тест-кейсы"?
Почему все ноют, что так работать невозможно, но ничегошеньки не делают, чтобы это изменить?
Я могу долго продолжать, я задавал массу таких вопросов.
Много лет я проработал в компаниях, где каждый был обязан сформулировать свою миссию, чтобы соответствовать внутренним стандартам, и поэтому питаю к миссиям некоторое отвращение. Однако моя команда все-таки сформулировала следующую "цель" нашего тестирования:
"Обеспечить информированное принятие решений, обнаруживая и делясь своевременной и релевантной информацией о ценности решений и рисках, сопутствующих им".
Это наша цель, это та задача, которую мы решаем. Мы тестируем, чтобы узнать что-то полезное, найти информацию, которая поможет заинтересованным лицам принять правильное решение. Да, это несколько общо, но это неплохая стартовая точка. Наша миссия помогает нам найти новые пути решения проблем тестирования.
Более того, миссия служит призмой, через которую мы смотрим на мир. Когда нам говорят "делайте так-то", мы вооружаемся своей миссией и спрашиваем, помогут ли эти действия достигнуть нашей цели, в правильном ли направлении мы будем двигаться?
Стив Джобс говорил: "Люди думают, что сконцентрироваться - это сказать "да" той вещи, на которой вы концентрируетесь. Это не так. Это означает, что вы должны сказать "нет" сотне других неплохих идей. Инновация - это умение сказать "нет" тысяче идей". В областях, схожих с тестированием, там, где процесс никогда не может быть полностью завершен, где каждое решение - это риск, подобная концентрация критична для успеха: мы должны быть в состоянии отказаться от вполне разумных предположений (а также от всяких глупостей). Миссия - прекрасный инструмент для исследования предположений и объяснения, почему нет.
Этот подход можно применять и на проектном уровне. Я заметил, что иногда тестировщики начинают размышлять, на какие важнейшие вопросы им необходимо найти ответ, и какая информация им нужна от других участников проекта. Частенько я слышал, как тестировщики беседуют с другими членами команды о целях своих проектов и том, какая информация им требуется, чтобы этих целей достичь. Я понял, что стратегия тестирования - это не кучка логистических указаний, а скорее список открытий, которые нужно сделать тестировщику. Постановка информационных целей и их уточнение постепенно становится неотъемлемой частью нашей работы - не везде, но в достаточно большом количестве мест, чтобы этот подход распространялся и далее.
Однако тут требуется предостережение. Когда вы определяете информационные задачи проекта, легко скатиться в "закрытые" вопросы вроде "Делает ли продукт это?", "Можем ли мы загружать данные?". Самые интересные вопросы, которые необходимо задать, всегда открытые: "Что и когда происходит?", "Сколько времени это займет?", "Сколько пользователей приложение выдержит перед тем, как упасть?". Не ограничивайте себя закрытыми вопросами. Небольшой совет: если вы переформулируете цели тестирования в форме вопросов, следите, что не все из них - закрытые. Задавать открытые вопросы очень важно.
Выступление Алексея Петрова на онлайн-конференции для специалистов по тестированию Chief ConfeT&QA.
Инструкции, шаблоны, регламенты и workflow, да даже всемогущие автотесты не появятся и не заработают сами собой.
Но как же найти нужных специалистов, где их искать и что спрашивать у них на собеседовании? Что рассказать о компании, о проектах, отделе? Какие тестовые задания подготовить и на что обращать внимание при их решении?
За последние три года я провел несколько сотен собеседований со специалистами в области тестирования самых разных профилей и уровня подготовки. Поэтому мой доклад будет содержать по-максимуму практических примеров и ситуаций, с которыми мне приходилось сталкиваться, а также принятых решений и рекомендаций по успешному найму тестировщиков.
Что подталкивает нас к организации обучения? В первую очередь — потребность в качественном улучшении работы и повышении квалификации сотрудников. Как правило, и сами сотрудники заинтересованы в том, чтобы развиваться. Нередко, правда, выясняется, что человек не знает, куда. Он просто хочет расти, но не понимает, какой ему нужен рост — «горизонтальный» или «вертикальный».
На выходе бизнес, в первую очередь, хочет получить квалифицированных сотрудников — «спецназовцев» от мира тестирования. С какими проблемами мы сталкиваемся?
Проблемы при организации обучения
1. В компании могут отсутствовать тренеры как таковые
Что же делать, если нет тренеров? На самом деле, это не проблема. Информацией можете делиться лично вы. Еще один вариант — сделать тренерами коллег. Например, если вам необходимо организовать обучение программированию, попробуйте подойти к одному из разработчиков и сказать: «О, Великий Сверхчеловек, озари меня своим знанием, научи меня программировать!». Возможно, это сработает. Также может сработать кейс с регулярными поставками пива. Одним словом, решение всегда есть.
У каждого из нас вызовет ухмылку требование к продукту «программа должна работать быстро» – слишком неформальное требование. Но при этом мы часто просим «быстренько протестировать последний билд».
И не удивляйтесь потом, что «быстренько» для вас означало совсем не то же самое количество времени, что и для другого человека.
Подход S.M.A.R.T. даст вам возможность раз и навсегда натренировать «мышцу постановки задач»: ставим задачи правильно – и команда гарантировано производит правильный результат.
Запись доклада Татьяны Зинченко на онлайн-конференции Chief ConfeT&QA.
Перфекционизм, гиперответственность, гипервнимательность – основные качества хорошего тест-менеджера, ведь так? Работа с командой, общение с заказчиком, общение с техподдержкой, а еще нужно протестировать, проверить, а еще книгу хорошую по тестированию посоветовали, да и пару статей прочитать бы. А на выходных усиленно изучаем тайм-менеджмент, потому что не успеваем сделать все и сразу… Знакомо?
Проходит некоторое количество времени, и возникают мысли о том, что на работе уже нет ничего нового, все знакомо, и ежедневная рутина утомляет. Коллектив тоже перестает радовать: одни и те же разговоры, одни и те же шутки. Новая книга может и подождать, пока я ее почитаю, а статью только вчера написали, так что она актуальности еще неделю не утратит – прочту позже. В блоге бы еще что-то написать, да вот как-то мыслей новых нет… Знакомо?
Кто-то сталкивался с подобными симптомами и успешно их преодолел. Кто-то скучает и уже не помнит, когда работа развивала и доставляла удовольствие. А кто-то еще только начинает взваливать на себя больше, чем может осилить, не подозревая, чем это может закончиться.
В своём докладе я расскажу самое важное о Синдроме Профессионального Выгорания в тестировании:
симптомы СПВ
что можно сделать с СПВ самостоятельно, а когда пора обращаться к специалистам
Хорошая команда, приятный коллектив, любимая работа… Что еще для счастья надо? И надо ли вообще?
Даже зная, что процессы неидеальны, мы продолжаем им следовать. И привыкаем. И считаем нормальными. Хорошо это или плохо?
Стоит ли что-то менять или лучше оставить «как было»? Стоит ли будущий выхлоп недовольства команды, ведь при внедрении новых практик всегда будет возникать сопротивление со стороны людей, привыкших жить иначе?
Я предлагаю посмотреть на работу в двух параллельных командах и на личном примере убедиться в том, что теория «у нас все и так хорошо» не так уж правдива.
Место для роста есть всегда! Но чтобы его обнаружить, надо посмотреть на свою работу, на свою команду немного под другим углом. С другой точки зрения. Я расскажу вам о том, почему это важно и как это сделать.
