Техническое собеседование специалистов по качеству с опытом работы

Ранее я уже писала о своем опыте собеседования людей на позицию тестировщиков. Так сложилось, что я в основном собеседовала людей без опыта работы.
Относительно недавно мне самой пришлось искать работу. На этот раз я была по другую сторону баррикад. И как кандидату одни собеседования мне понравились, а другие - совсем наоборот. На основе этого опыта я сделала выводы о том, как нужно и как не нужно проводить собеседования.


 1. Практика, а не теория!
 БОльшая часть пройденных мной собеседований была посвящена проверке моих теоретических знаний
Спрашивали все подряд - отличия тестирования белого ящика от черного, классы эквивалентности, анализ граничных значений, уровни тестирования, понимание разных методологий разработки, знание SQL, отличие приват и протектед методов или переменных от паблик и так далее. Часто такие собеседования длились больше часа, что очень и очень изматывало обе стороны.
Смысла в таких собеседованиях мало, когда приходит человек с опытом работы больше полутора-двух лет. Существует большая разница между "знаю как" и "умею". Если приходит человек с опытом работы, то непродуктивно тратить время обоих, спрашивая основы теории тестирования. Если нужна теория - можно нанимать и джуниоров, но ведь человек пришел на позицию Middle\Senior и платить ему нужно намного больше,чем джуниору. Так почему бы не узнать, за что именно ему нужно будет платить деньги, за какой опыт, какие практические знания? Более того, кандидат выходит с собеседования, так и не поняв, какие именно его умения интересовали работодателя, с чем нужно будет иметь дело в случае успеха и на каком уровне.
Я сторонник той мысли, что для проверки знаний теории нужно давать практические задания. Если тестовое задание на знание этой теории придумать сложно, то стоит задуматься, действительно ли нужна эта теория.
Нужна проверка написания тестов? Просим привести пример тест кейса. Хотим проверить полноту? Можно поросить набросать небольшой список кейсов. Автоматизация? Просим написать простой код автотеста на любом языке (в крайнем случае, псевдокод) - тут как раз и проверим знание модификаторов видимости (доступа). Нужна проверка внимательности? Даем спецификацию и скриншоты готового приложения или даже даем компьютер с открытым тестовым приложением, в котором "заложены" баги.
Безусловно, теоретические знания тоже важны, но гораздо важнее понять, подходит ли кандидат для выполнения того объема работ, который от него будет требоваться, или нет. Время собеседования, как правило, ограничено, поэтому стоит потратить его на то,чтобы понять,что представляет из себя человек, как мыслит и что умеет делать, ведь гуглить и заучивать все научились еще в институте.

2. Техническое собеседование должен вести человек, который работает на том же проекте, на который проходит собеседование
Иногда техническое собеседование проводит просто "специалист по тестированию", "qa manager\lead", который работает в другой команде. Просто так сложилось,что в команде, в которую проходит собеседование, нет компетентных людей.
Итого получаем ,во-первых, скорее всего основную массу вопросов по теории, о чем говорилось выше. Во-вторых, кандидат не может задать технические вопросы, которые его интересуют, потому что собеседующий знает только поверхностно о том, какие технологии используются и как организован процесс.
Собеседование проводится для обеих сторон, и кандидату тоже интересно,что предлагает ему работодатель. Даже если в команде нет человека, который мог бы провести собеседование кандидата с опытом работы, можно попросить и более опытного сотрудника другой команды, но при условии, что он будет "в паре" с представителем той команды, в которую ищут пополнение. И представителем должен быть не один из менеджеров, а именно тестировщик любого уровня.

3. Качество связи должно быть таким, чтобы не отвлекать от главного
Если собеседование происходит по телефону\скайпу, нужно иметь лучшие телефоны, лучшую гарнитуру и лучшие звукоизолированные комнаты. Когда что-то фонит, когда слышишь собственный голос эхом, когда в соседней комнате громко смеются, когда шум автомобилей заглушает звук голоса собеседника - это сильно отвлекает и заставляет вслушиваться в слова, потом уже собирая их вместе и понимая смысл. Частые "повторите,пожалуйста, вопрос" с обеих сторон говорят о том, что собеседование можно считать неудавшимся.
Как правило,негативные впечатления после таких собеседований остаются у обеих сторон.

Подводя итог, хочется еще раз сказать,что собеседование проводится и для работодателя, и для кандидата - так что каждая из сторон может остаться недовольной. Для проведения эффективных и успешных собеседований нужно уважать время, потраченное обеими сторонами, соответственно, пытаться узнать максимум об опыте и интересах кандидата \ процессах, практиках и технологиях проекта.

Сказка о двух ящиках и одной тестировщице

Жила-была маленькая тестировщица, и по неопытности своей считала, что белый ящик - для программистов, а черный - Мекка для тестировщиков.
Но однажды наступил момент, когда ей в Jira подключили FishEye, и она смогла видеть то, каким образом был пофикшен тот или иной баг, или каким образом был заимплеменчен тот или иной функционал. По началу все изменения выглядели как наскальная живопись - было понятно о чем речь лишь по мутным и примитивным очертаниям. Тогда она стянула себе из системы контроля версий репозиторий, и очертания стали больше напоминать то,что они значили, ибо в IDE можно было перемещаться по классам и методам, чтобы понимать, что происходит. И тогда коммиты стали понятней, и несмотря на практику код ревью, принятую в команде, маленькая тестировщица все равно заглядывала в новый код посредством FishEye.
Это привело к тому, что отныне делать impact анализ можно было основываясь не только на словах разработчика и собственных предположениях, но и на том, что она сама видела. И оказалось, что, как правило, изменения затрагивали гораздо больше того, что было сказано разработчиком, и тестов нужно было сделать гораздо больше, чтобы убедиться в правильности имплементации. Чек листы стали более полными, что позволяло отловить больше багов.
А маленькая тестировщица теперь при получении тикета в Jira первым делом открывает вкладку Source и смотрит изменения в файлах, а уж потом приступает к тестированию. А в случае, если на нее ассайнят тикет, где такая вкладка для нее отсутствует, она брезгливо морщится и тяжело вздыхает.

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

но это не имеет никакого смысла до тех пор, пока нет доступа к коду.

Lessons learned in SCRUM. Lesson 2 - Add new person to help или "Ой ли?"

Никогда не верила в тот постулат, что добавление нового человека в скрам команду по началу влечет за собой потерю производительности. Ведь человека добавили, дополнительный мозговой центр и обладатель рук может только помочь!
Но на практике оказалось,что есть большая разница между тем, кого именно добавляют. И речь идет не столько о скиле (что тоже немаловажно), сколько о персональных качествах нового члена команды.
Итак, к примерам из жизни, но в этот раз без графиков, к сожалению.

Пример 1. В команду добавили не очень опытного человека. Он хочет учиться, у него горят глаза, ему нравиться работать в команде опытных людей. В нашем случае это привело к тому, что производительность команды не упала, а незначительно увеличилась. Безусловно, часть времени тратилась на помощь новичку в освоении новых знаний, в то же время порученную ему работу он делал добросовестно, давая более опытным товарищам время на работу с более сложными задачами.  
Пример 2. В команду добавили опытного человека. Он мыслит рационально, спокоен и рассудителен. Первый спринт производительность незначительно увеличилась, но после первого спринта начался рост и стабильный прирост к производительности команды, которую она показывала ранее.
Пример 3. В команду добавили опытного человека. Он реформатор, стремится улучшать качество продукта и процессов, но делает это слишком настойчиво и рьяно, его трудно убедить, даже если он просто явно не понимает еще всех внутренних процессов и условий работы.
Первый спринт производительность немного просела, потом вернулась к прежнему значению. По мере вливания нового человека в процесс производительность команды повышалась, и остановилась примерно на той же отметке, что и при добавлении человека из второго примера. Несмотря на то,что потенциал человека из примера 3 значительно выше, ожидаемого эффекта улучшения не получилось по той причине, что в команде возникло некоторое напряжение, связанное с непривычной для команды манерой обсуждения спорных моментов и невозможностью положиться на опыт друг друга - новичок не может положиться на опыт команды, так как еще не доверяет ей, а команда не может еще положиться на опыт новичка, так как привыкла решать проблемы сообща и приходя к компромиссу на основании выбора лучшего варианта на данный момент.

Подытоживая, хочу отметить, что к выбору нового человека в сложившуюся скрам команду нужно подходить с большой серьезностью и оценивать не только профессиональные качества кандидата, но и личностные. То, насколько быстро и безболезненно он вольется в команду, и вольется ли, напрямую влияет на отношения внутри команды и ее производительность. Не гонитесь за скилами кандидата - сначала прикиньте, сколько времени и сил займет у обоих сторон сгладить углы во взаимодействии.

Lessons learned in SCRUM. Lesson 1 - Commitment или "Не откусывайте больше, чем можете проглотить"

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

Итак,
Урок 1 - Commitment или "Не откусывайте больше, чем можете проглотить"

Понятие commitment в скраме обозначает  объем работ, который команда обязуется выполнить за спринт.
Чем плохо невыполнение обещанного объема работ:
- невозможно спланировать конечную дату релиза продукта
- недовольство стейкхолдеров всех уровней
- недовольство собой команды, что в конечном итоге ведет к понижению производительности ее труда ("Мы снова сфейлили спринт. Но мы всегда фейлим, так что все в нормально и так.")
- конфликты внутри команды ("Я успел сделать, что от меня требовалось, а из-за этих лентяев мы снова сфейлили.")
- стресс и усталость.

Вот статистика работы реальной команды, вернее, только часть статистики. Для удобства столбцы обозначены цифрами 1-7, но это не обозначает номер спринта. Из графика видно, что команда все время "почти" выполняла коммитмент. Ну вот еще чуть - полдня или день - и все бы было красиво и хорошо. Но этих полдня всегда не хватает (кроме 3 столбца, когда сделали все).

 

 После многих спринтов, когда запланированная работа превышала реально сделанную (столбики 1-5), решили-таки коммититься на меньший объем. Результат поразил - в первый такой спринт команда выполнила почти на 5% больше,чем в предыдущий, а на второй - на 10% больше! (столбики 6 и 7) При этом реально потраченное на выполнение задач время практически не изменилось.

Лучше откусить кусок поменьше и добрать задачи. В конечном итоге, команда может сделать бОльший объем работы в более комфортных условиях.

Плюсы:
- удачно законченные спринты улучшают микроклимат в команде
- повышается производительность труда
- заинтересованные лица тоже довольны
- со временем команда учится более точно соизмерять свои силы и возможности.

Стратоконф: «Использование public clouds для нагрузочного тестирования web-сайтов»

Вот и закончилась первая встреча конференции Стратоконф.

Доклад был посвящен нагрузочному тестированию и назывался он «Использование public clouds для нагрузочного тестирования web-сайтов» (докладчик - Александр Балабанов).

Я редко сталкивалась с нагрузочным тестированием, поэтому тема была мне интересной и довольно новой. Очень порадовала именно практическая направленность - рассказали об инструментах и показали их работу практически в live-режиме (Chief, Tsung, Amazon Cloud). Из демонстрации стало ясно,что нагрузочное тестирование не так страшно, как мне о нем думалось ранее (во всяком случае, когда речь идет о вебе).

И все же чего-то не хватило. Возможно, краткого обзора "поставщиков" клаудов, существующих на сегодняшний день, или объяснения, почему же выбран именно амазон.

Не пропустить: Software Testing Virtual Conference от EuroSTAR

16 мая состоится Software Testing Virtual Conference от EuroSTAR. Конференция бесплатная, но требует предварительной регистрации. "Встреча" обещает быть интересной - хорошие темы, мега опытные докладчики... В общем, регистрируемся и ждем 16 мая!

На повестке дня:

Model Driven Development and its Impact on Testing. A Nanotech Case Study with Bryan Bakker, Sioux Embedded Systems B.V.

Bryan discusses how Sioux has developed several projects with a Model Driven Development approach. He talks through the problems they found, and details information they have used for follow-up projects.

Many Ways to Manage Exploratory Testing with James Lyndsay, Workroom Productions Ltd.

This talk will be a swift spin through the pros and cons of typical ways that teams manage exploratory testing. James will dip into some possible alternatives, taking inspiration from machine learning, lean approaches, and from other industries who find value in exploration.

Where (Testing) Ideas Come From with Alan Page, Microsoft

Alan discusses where new test ideas come from, and how anyone can use learning, creativity, pattern recognition and pragmatism to discover and apply new ideas anywhere - especially in software testing.

Thinking Visually in Software Testing with Alan Richardson, Compendium Developments

Alan shares his experience of using models and diagrams to help his test planning and communication of testing. He will cover "Not Thinking Visually" - what this looks like, why it is the norm, and traps your readers will fall into.

А здесь регистрация и более детальная информация о докладчиках.

Боевое крещение (Pairwise testing)

Впервые предоставилась возможность использовать pairwise testing в реальных условиях! До этого много читала и безусловно соглашалась с эфективностью этого подхода, однако,шанса все не выпадало. И вот свершилось!
Напомню,что

All-pairs testing"" or pairwise testing is a combinatorial software testing method that, for each pair of input parameters to a system (typically, a software algorithm), tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by "parallelizing" the tests of parameter pairs. The number of tests is typically O(nm), where n and m are the number of possibilities for each of the two parameters with the most choices.
(c) Wiki

О самом алгоритме подробнее можно прочитать здесь

Для генерации я использовала PICT от Майкрософт. Консольная утилитка на входе принимает файл модели (описание параметров и их значения), а на выходе выдает готовые комбинации, даже умеет в эксельку красиво выводить, что не может не радовать.
При необходимости можно создавать "подмодели", учитывать зависимые параметры и перебирать не парами, а,например, тройками параметров.

Результаты реально впечатляющие - из 150+ возможных комбинаций (потом надоело считать) было оставлено 14!