10

В описаниях вакансий на должность тестировщика чего только не увидишь. И тест-планы надо уметь писать, и багрекерами владеть. Столько-то лет опыта в тестировании веб-приложений, основы Java или C#. Желательно знать Selenium. Быть коммуникативным, умным, добрым.

И вот только одного на мой взгляд абсолютно важного для тестировщика скилла вы никогда не найдете в описании должности, или в тестовом задании: владение слепым методом печати.

Скажите, зачем вам тестировщик, который знает Selenium, если он печатает двумя пальцами, опустив голову в песок? Слепая печать (десятипальцевым методом, но если вы вдруг можете печатать вслепую меньшим количеством пальцем - ради бога) - базовый скилл любого айтишника, который изо дня в день должен писать большое количество связного текста, и особенно для тестировщика (баг-репорты, отчеты, тест кейсы, коммуникация с коллегами).

...грустно глядя на коллегу, который со скоростью черепахи вносит баг-репорт в систему...

1

Подумалось, что на собеседовании на должность тестировщика, я хотел бы проверить умение кандидата разбивать сложную задачу на множество простых. Ну и вообще увидеть понимание, зачем это нужно. Мне кажется, что если человек не умеет разбивать, то для него всегда придется разбивать задачу на такие куски, с которыми он умеет обращаться или он будет просто зависать на задаче без прогресса.  Фраза характеризующая проблему: "дай мне нормальное ТЗ"

Это не только про тестировщиков.

Что думаете по этому по поводу? Нужно проверять? Как проверять?

 

 

Ну пройдемся немного по докладам.

Сразу скажу, что постараюсь не оценивать доклады по принципу "узнал я что-то новое, или не узнал", потому после долгих лет (15) работы в IT я успел узнать довольно многое, и ехал на конференцию вовсе не чтобы глотнуть новизны в отрасли. Многие доклады, и мой в том числе, пишутся для новичков и средне-опытных тестировщиков, однако улучшение именно этого звена даст пользу всем нам, я уверен.

Не ко всем докладам пока есть видео, но скоро появятся, потерпите :).

Сергей Атрощенков "Тестовые оракулы на основе концепции EI/EQ (эмоционального интеллекта)"  http://sqadays.com/ru/talk/25831

Любопытный доклад про то, как наблюдения за эмоциями (субъективные факторы) могут помочь в работе определять объективные факты (например, баги замечать). Кое-что общего в идее есть с  вебинаром от  it-boost с http://it-boost.com/statistika-ili-intuitsiya-chey-kung-fu-kruche , где я впервые услышал понятие "жопочуй".  Хочу обратить внимание, что хотя эмоции наверняка дают интересные сигналы, их верную трактовку сильно усложняет наличие внешних (вне рабочих) эмоций (забыл молоко купить, футбольная команда вчера выиграла, зарплаты вечно не хватает и тд.) как очевидных, так и более глубоких подсознательных. Сергей посоветовал разделять вектора рабочих и внешних эмоций, но я думаю, что это на практике не всегда просто, может даже невозможно.

Ольга Павлова "Порог вхождения как критическая точка пользовательского опыта"  http://sqadays.com/ru/talk/24046

Веселенький доклад, который напоминает, что если просто сделать "как в спецификации записано", то можно очень быстро получить провальный проект, особенно, если сделать это на точке входа пользователя в программу. Юзабилити наше все, а если вам при первом запуске программы предлагают заполнить формуляр на 30 полей, то возможно вы даже и не узнаете, как хорошо и правильно все устроено внутри. В конце доклада возник небольшой флейм с зрителем из "Одноклассники.ру" по поводу того, что автор "только указывает на проблему, но не дает путей решения". Возможно это так, но тут я согласен с Ольгой - докладчик строит доклад на свое усмотрение. Укажешь путь решения - спросят "почему не обсудил, когда данные пути не подходят". Обсудил - "почему не все альтернативы указал". "И вообще теперь наговорил всякого, половина мне вообще не подходит, зря и слушал" :). Ребята, у нас 30 минут на "длинный" доклад, еще меньше на блиц. Есть вопросы - общайтесь с докладчиком. Хотите решить именно вашу проблему в глубине - некоторые докладчики предлагают консальтинговые услуги, звоните-заказывайте ;-).

Владимир Мозжечков "Техническое собеседование Senior QA. Проведение и прохождение" http://sqadays.com/ru/talk/24011

Несколько провокационный доклад про то, как проводят собеседования в фирме аутсорсинговой фирме Smartech (http://smartru.com). Оказалось, что мне проще положительно пройти тест на беременность, чем закончить техническое собеседование на Senior QA на отлично. Потому что, полный ответ на поставленную задачу даст мне только 3 балла из 5, а для 5-ки нужно еще догадаться, что часть задания была скрыта, и успешно решить ее про запас. Подход спорный, так как с одной стороны, некоторые сильные кандидаты просто по-доброму удивятся, увидя объём задания и соскочат. С другой стороны, представьте, у вас есть кандидат который сделал всё что задавали, плюс тест-план, плюс автоматизированные тесты, плюс еще небольшую диссертацию по TCP/IP протоколу приложил. Если спросите меня, то возможно и в работе он, когда получит задание протестировать небольшой проект, вложит туда свою энергию и способности, и потратит ресурсы на то, чтобы сделать больше, чем предусмотрено бюджетом заказчика. По мне, так лучше меньше, да лучше :). Доклад тем не менее весьма полезный, вы можете теперь представить, что потенциально могут спрашивать на собеседованиях, и если вы основательно подготовитесь к этому, то никакой другой вас уже не испугает :). К слову, в данный момент открытых QA вакансий на сайте фирмы, и на hh.ru нет.

Инна Смирнова "Эффективный тест-менеджмент... и как с ним бороться" http://sqadays.com/ru/talk/25902

Вопреки услышанной от кого-то из организаторов установки, что нельзя пересказывать чужие книжки в своем докладе, я считаю, что хорошая презентация отличной и полезной книги имеет свою ценность. Что и показали оценки доклада (2-ое место). Инна говорила про один из бестселлеров Ицхака Адизеса "Стили Менеджмента и Мисменеджмента" (http://www.amazon.com/Management-Mismanagement-Styles-Kalderon-Adizes/dp/0937120014 ) в применении к общению с (тест)-менеджерами, а также со взглядом на саморазвитие. Адизес различает 4 компоненты в стиле управления P (Производитель), А (Администратор), Е (предприниматель), I (интегратор). В каждом менеджере наиболее развиты одна или две компоненты, и недоразвиты или отсутствуют остальные (и это - норма (с) 🙂 ). У каждого стиля свои плюсы и минусы, к каждому стилю - свой подход. Можно пройти тест http://adizes.me/paei_test/ и узнать, к какому стилю относились бы вы, если бы были менеджером :).  У меня вышло PaEi, с преобладающим E:). Мне показалось, что большинство примеров были взяты прямо из книжки, было бы еще лучше, если бы Инна придумала примеры из повседневной жизни тестировщиков. Я книжку прочитал в 2011 году, и вспоминаю о разнице в типах, как правило, сразу после неудачного подхода к одному из "менеджеров", т.е. слишком поздно :). Поэтому меня интересовало то,  как можно практически применять знания типов (оценивать менеджеров и записывать буквочки в телефонную книжку)? Надеемся услышать об этом в следующий раз. 🙂
А в целом, если вы не слышали об Адизесе - обязательно прослушайте доклад!

Часть 2

Часть 3