Я большая сторонница найма джуниор-тестировщиков. Под джуниором я подразумеваю человека, который никогда не занимался именно тестированием, вне зависимости от других рабочих заслуг и возраста.
Для меня найм джуниоров – это часть сбалансированной стратегии найма людей в команду, и мне любопытно, насколько мои мысли созвучны с позициями других людей, ответственных за найм тестировщиков.
Отношение к работе
Я ищу джуниоров, которые мечтают быть тестировщиками в Agile-окружении, работать в финансовом секторе и иметь возможность подтянуть навык автоматизации. Другими словами, я ищу джуниоров, которые мечтают именно о нашей конкретной позиции, а не просто о какой-нибудь там работе.
Такие люди выделяются из толпы. Они вдумчиво готовятся к собеседованию и задают глубокие вопросы про рабочие обязанности. По ним заметно, что они серьезно думали, чего потребует от них эта конкретная работа, и уже начали искать информацию о том, как с ней справляться. Желание работать именно здесь буквально написано у них на лице.
Если вы нанимаете именно таких джуниоров - вы получите высокомотивированного участника процесса, который страстно стремится стать лучше. В благоприятной среде он сумеет заразить своим энтузиазмом кого угодно. Может, ему пока что нечему научить коллег, но, как мне кажется, эта яростная жажда знаний не может не вдохновлять тех, кто трудится рядом с таким новичком.
Освоить новую, востребованную на рынке профессию за два месяца? Да еще и бесплатно? Легко! Компания «Петер-Сервис», крупнейший российский разработчик OSS/BSS-систем, открывает собственную Школу тестировщиков! В программе – минимум скучной теории и максимум практики по ручному и автоматизированному тестированию от действующих специалистов компании. Базовых знаний не требуется!
Продолжительность: 2 месяца, 94 часа (4 раза в неделю по 3 часа)
Публикуем подборку докладов с Analyst Days - 4, интересных для тестировщиков.
"Шагнуть навстречу тестированию требований. Советы тестировщика" – доклад Алексея Федорова о подводных камнях тестирования требований.
"После нас - хоть потоп! Как писать документацию на века" – доклад Кристины Ерофеевой о том, как создавать хорошую документацию.
"Немного об отношениях аналитика и тестировщика" – доклад Андрея Павлова об эффективном сосуществовании тестирования и аналитики.
"Как решить проблему, о которую уже все копья сломаны" – доклад Светланы Гончар об интегральном подходе к решению сложных проблем.
"Мы - хорошие, а они - плохие. Почему так происходит и что с этим делать" – доклад Надежды Тарасюк об эффективных коммуникациях в мультинациональных командах.
"Ревью проектных документов – борьба за качество" – доклад Андрея Кудинова о процессе ревью документации.
22-23 апреля 2016 г. в Санкт-Петербурге пройдет 5-я юбилейная международная конференция по системному и бизнес анализу «Analyst Days».
Наши читатели при регистрации на конференцию могут получить скидку.
Я хочу обсудить, пожалуй, самую знаменитую из устаревших концепций тестирования. Кто-то говорит о ней с восторгом, а кто-то не очень понимает, о чем речь. Зачастую ее недопонимают или применяют неправильно, и поэтому она, наверное, лучший кандидат на вышедшие из моды концепции тестирования, которые имеет смысл обсуждать. Так поговорим же про автоматизацию тестирования!
Прежде чем начать разговор
Под автоматизацией я – лично я – понимаю автоматизированное выполнение какого-либо действия. Соответственно, автоматизированное тестирование для меня – это автоматизация действий, помогающая процессу. Подчеркиваю: под автоматизацией я понимаю только это, а не автоматизацию процесса тестирования как такового. Я сознательно не прибегаю к термину "проверка", чтобы не удариться в долгую дискуссию про "тестирование" и "проверки" - я просто не готов поддержать этот спор в данный момент. Если вам интересна эта тема, прочитайте статью Испытания и проверки: уточнения" Майкла Болтона и Джеймса Баха - это потрясающая работа, я согласен с многими идеями в статье и рекомендую ее всем заинтересованным.
Работать в Agile-команде, по определению ориентированной на сотрудничество - во многих отношениях непростая задача. К примеру, мне, да и не только мне, очень трудно найти верный баланс между необходимостью взаимодействовать с коллегами и потребностью в сохранении своих коммуникативных способностей.
Я интроверт. Это совершенно не означает, что я застенчивая, или тихоня, или стою особняком от окружающих (хотя иногда я именно такая). Да, я люблю хорошенько все обдумать, прежде чем высказываться, но это тоже не то, что выделяет интровертов из толпы. Простейшее определение интровертов, которое мне подходит, звучит так:
"Интроверт расходует энергию на разговоры. Экстраверты от разговоров подзаряжаются".
Вот вам пример. Раньше я работала тестировщиком в Agile-команде с двухнедельными Scrum-спринтами. Каждый четверг мы устраивали трехчасовую встречу по планированию спринта (с 9 утра до 12 дня), на которой обсуждались пользовательские истории, ставились задачи, оценивались временные затраты, и утверждался бэклог на спринт.
Эта встреча рушила мне весь рабочий день. Многие из моих коллег покидали ее, бурля от полученной информации и предвкушая старт интересных задач. Я чувствовала себя совсем разбитой и не могла делать ничего полезного вплоть до утра пятницы. Вот она, разница между экстравертами и интровертами.
Посещая недавно прошедшие конференции, я осознала, что люди задают неправильные вопросы, когда речь заходит об автоматизации. Прошедший ISTQB-опрос звучал как "Как много (какой процент) тест-кейсов вы автоматизируете?". После своего доклада по автоматизации я беседовала с участницей конференции, которая сказала мне, что ее менеджер задавал ей тот же вопрос, и она не знала, что ему сказать. Она не одинока. Менеджеры часто задают этот вопрос. Ответить на него трудно, потому что это неверный вопрос.
Почему люди спрашивают об этом? Возможно, им нужна информация о прогрессе автоматизации, особенно если она только внедряется. Не то чтобы это необоснованный интерес, но это плохой вопрос - он основан на ряде неверных допущений:
Неверное допущение номер 1. Все ручные тест-кейсы должны быть автоматизированы.
Друзья! 30 января в Минске на площадке SPACE пройдет конференция сообщества COMAQA.BY, посвященная вопросам Автоматизированного и Ручного тестирования. Спешим порадовать новостью – для участия в событии не обязательно лететь в город-герой, достаточно расположиться с друзьями на диване по-удобнее иии подключиться к стриму.
Мы подготовили для вас расширенные версии докладов активистов сообщества COMAQA.BY, которые звучали на московской конференции SQA Days 18. А также, четыре совершенно новых доклада, 2 из которых посвящены мобильной Автоматизации! Подключайтесь, будет интересно!
Расписание трансляции:
12:30 - 13:10 «MobileAPI + CRM - using application related .xml files to build automation framework» Тимофей Авилин, Epam Systems
13:10 - 13:50 «Time to mock back-end!» Алексей Буль, Juno
14:10 - 14:50 «Непрерывная интеграция и автотесты. Сравнительный анализ инструментов» Вадим Зубович, www.COMAQA.BY; ISSoft / CoherentSolutions, DPI.Solutions
14:50 - 15:30 «Docker + Selenium Webdriver в рамках Continuous Integration» Антанас Мачярнис, www.COMAQA.BY; ISSoft, DPI.Solutions
15:30 - 16:10 «Новый процесс тестирования на "старом" проекте» Александр Полещук, www.COMAQA.BY; ISSoft
Мне никогда не нравился подход, при котором тестировщики отделены от основной команды и подключаются к работе на соответствующие "фазы" тестирования. Я проработал так около восьми лет, и все это время бился над ответами на следующие вопросы:
Почему мы так поздно подключились к проекту?
Почему в нем так много очевиднейших багов и проблем?
Почему продукт не соответствует спецификации?
Почему из раза в раз мы гоняем одни и те же кейсы и на этом основании считаем, что продукт готов и тестирование завершено?
Почему бы тестировщикам не начать задавать вопросы на более ранних стадиях разработки продукта?
Почему такие навыки тестировщика, как тест-дизайн, организационные способности, критическое мышление совсем не ценятся под конец проекта?
Почему некоторые тестировщики высоко специализированы - например, тестировщики производительности - но при этом куча прочих тестировщиков просто "гоняет любые функциональные тест-кейсы"?
Почему все ноют, что так работать невозможно, но ничегошеньки не делают, чтобы это изменить?
Я могу долго продолжать, я задавал массу таких вопросов.
Много лет я проработал в компаниях, где каждый был обязан сформулировать свою миссию, чтобы соответствовать внутренним стандартам, и поэтому питаю к миссиям некоторое отвращение. Однако моя команда все-таки сформулировала следующую "цель" нашего тестирования:
"Обеспечить информированное принятие решений, обнаруживая и делясь своевременной и релевантной информацией о ценности решений и рисках, сопутствующих им".
Это наша цель, это та задача, которую мы решаем. Мы тестируем, чтобы узнать что-то полезное, найти информацию, которая поможет заинтересованным лицам принять правильное решение. Да, это несколько общо, но это неплохая стартовая точка. Наша миссия помогает нам найти новые пути решения проблем тестирования.
Более того, миссия служит призмой, через которую мы смотрим на мир. Когда нам говорят "делайте так-то", мы вооружаемся своей миссией и спрашиваем, помогут ли эти действия достигнуть нашей цели, в правильном ли направлении мы будем двигаться?
Стив Джобс говорил: "Люди думают, что сконцентрироваться - это сказать "да" той вещи, на которой вы концентрируетесь. Это не так. Это означает, что вы должны сказать "нет" сотне других неплохих идей. Инновация - это умение сказать "нет" тысяче идей". В областях, схожих с тестированием, там, где процесс никогда не может быть полностью завершен, где каждое решение - это риск, подобная концентрация критична для успеха: мы должны быть в состоянии отказаться от вполне разумных предположений (а также от всяких глупостей). Миссия - прекрасный инструмент для исследования предположений и объяснения, почему нет.
Этот подход можно применять и на проектном уровне. Я заметил, что иногда тестировщики начинают размышлять, на какие важнейшие вопросы им необходимо найти ответ, и какая информация им нужна от других участников проекта. Частенько я слышал, как тестировщики беседуют с другими членами команды о целях своих проектов и том, какая информация им требуется, чтобы этих целей достичь. Я понял, что стратегия тестирования - это не кучка логистических указаний, а скорее список открытий, которые нужно сделать тестировщику. Постановка информационных целей и их уточнение постепенно становится неотъемлемой частью нашей работы - не везде, но в достаточно большом количестве мест, чтобы этот подход распространялся и далее.
Однако тут требуется предостережение. Когда вы определяете информационные задачи проекта, легко скатиться в "закрытые" вопросы вроде "Делает ли продукт это?", "Можем ли мы загружать данные?". Самые интересные вопросы, которые необходимо задать, всегда открытые: "Что и когда происходит?", "Сколько времени это займет?", "Сколько пользователей приложение выдержит перед тем, как упасть?". Не ограничивайте себя закрытыми вопросами. Небольшой совет: если вы переформулируете цели тестирования в форме вопросов, следите, что не все из них - закрытые. Задавать открытые вопросы очень важно.
20-21 мая 2016 г. в Санкт-Петербурге пройдет 19-я международная конференция в области обеспечения качества ПО «Software Quality Assurance Days».
Приглашаем вас принять участие в работе 19-й Международной конференции специалистов в области обеспечения качества ПО – SQA Days.
Конференция, как всегда, охватит широкий спектр профессиональных вопросов в области обеспечения качества, ключевыми из которых являются:
Методики и инструменты тестирования ПО;
Автоматизация тестирования ПО;
Подготовка, обучение и управление командами тестировщиков;
Процессы обеспечения качества в компании;
Управление тестированием и аутсорсинг;
Совершенствование процессов тестирования и инновации.
Что такое SQA Days?
Для многих специалистов и руководителей «Software Quality Assurance Days» это реальная возможность заявить о себе, повысить профессиональный уровень сотрудников, которые отвечают за ПО и, тем самым, укрепить конкурентные позиции и создать преимущество. SQA Days – это замечательная платформа общения и обмена опытом для людей, вовлеченных в сферу тестирования ПО. Ведущие профессионалы смогут рассказать о своих достижениях, показать, как эффективно использовать инструменты, методики и методологии. Для начинающих – это отличный шанс приобрести новые полезные знакомства в профессиональной среде.
Конференция посвящена вопросам, связанным с тестированием и обеспечением качества программного обеспечения:
функциональному тестированию;
интеграционному тестированию;
тестированию производительности;
автоматизации тестирования и инструментальным средствам;
конфигурационному тестированию;
тестированию удобства использования (usability);
тестированию защищенности (security);
статическим методам обеспечения качества;
внедрению процессов тестирования на предприятии;
управлению процессами обеспечения качества ПО;
менеджменту команд тестировщиков и инженеров качества ПО;
аутсорсингу тестирования;
тестированию системных приложений (не Web), а также тестированию игр и приложений для мобильных устройств;
мотивации проектной команды и сертификации специалистов в области обеспечения качества ПО.
