Как провести эффективное собеседование QA-инженера за 35 минут

109 комментариев
Как провести эффективное собеседование QA-инженера за 35 минут

Егор Павловец методом проб и ошибок разработал алгоритм, который позволяет ему проводить собеседования с QA-инженерами, укладываясь в 35 (максимум — в 45) минут.

Читать далее…

Фото: via linkedIn.

Большинство ведущих специалистов работают в режиме жёсткой мультизадачности и постоянно вынуждены переключаться между разными контекстами. А ведь чем меньше вы отвлекаетесь от ключевой задачи — тем быстрее она будет выполнена.

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

Ключевая проблема в том, как провести собеседование быстро и эффективно. И крутого специалиста в свою команду подобрать, и от приоритетных задач надолго не отрываться.

Проблема N1: затяжные собеседования с 80% «сильных теоретиков»    

Обычно, когда открывается позиция джуниор-тестировщика, от желающих отбоя нет. На интервью сразу заметно, что 80% соискателей реально сильно подготовились по теории. На любой стандартный вопрос у «сильного теоретика» всегда готов ответ. И выходит, что из 10 человек — 8 показывают примерно одинаковый уровень.

На первых порах это обстоятельство было нашим главным тормозом. Да, когда начинаешь копать, сразу выявляются белые пятна. Но такие «раскопки», когда их приходится проводить в 80% случаев, отнимают существенно больше времени и надолго отрывают от горячей технической задачи по текущему проекту.

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

Проблема N2: тестовое задание с недельной отсрочкой

После некоторого анализа мы приняли первую попытку улучшить процесс. Да — добавили тестовое задание для junior-тестировщиков.

Тестовое задание заключалось в необходимости протестировать видоизменённое приложение из примеров приложений Android SDK, в которое мы умышленно вносили дефекты. Соискатель должен был написать отчёт по дефектам в течение недели.

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

Одна девочка вообще буквально за выходные выполнила тестовое задание, обставив около десятка конкурентов-парней по скорости и качеству выполнения. Женя, привет!  

В принципе, этот подход отлично работал, если бы не одно «но». Неделя. Ждать целую неделю — мучительно долго и скучно. Хотелось нанимать быстрее, с помощью каких-нибудь показателей, получаемых в реальном времени прямо во время собеседования.

KPI: отсеивание «болтунов» с запросом на зарплату в $2000

Стало очевидно, что необходимо тестовое задание включать прямо в процесс собеседования. Ведь всё равно у нас уже есть на руках приложение, в котором заведомо известны все дефекты.

Вопросы по теории тоже были тщательно переработаны. Мы выбрали 15 блиц-вопросов на 15 минут, на сколько из них соискатель отвечает — столько баллов и идёт в зачёт. Известных дефектов было всего около 10. Итого максимум 25 баллов.

Получилась своеобразная KPI (Key Performance Indicators, ключевые показатели эффективности) таблица соискателей — по теории и по практике.

Забавно, но никто ни разу не смог набрать максимум, хотя были люди, которые находили такие дефекты, о которых даже мы не знали!

По результатам нескольких десятков собеседований сразу стало очевидно, что некоторые соискатели — откровенные болтуны, которые при всём великолепном знании теории не смогли найти даже одного-единственного дефекта в приложении из двух экранов. И при этом с запросом на зарплату в 2000$!

Ребят с первых трёх позиций на вершине списка мы и наняли к себе в команду. В процессе работы они действительно проявили свой багхантерский талант. Каждый руководитель ведёт метрики эффективности, так вот эти ребята находили от 80 до 120 дефектов в месяц в таком приложении, как Prestigio eReader.

Сюрпризы 35-минутного собеседования

Очень удивило, что существуют кандидаты, которые отключаются прямо во время KPI собеседования, впадая в ступор. При затяжных интервью такого никогда не наблюдалось.

Например, во время быстрого опроса по теории около десятка человек просто сказали: я ничего не знаю; теорию не буду отвечать — ни на один вопрос.

После просьбы протестировать приложение заметки (2 экрана и меню, из серии примеров в Android SDK) некоторые из кандидатов предположили, что мы хотим воспользоваться их трудом в течении этих 15 минут, чтобы самим баги не искать. От такой дичи в ступор впали уже мы с эйчаром.

Табу на «мы вам перезвоним»  

Каждому человеку, который по своим KPI нам точно не подходил, мы не говорили печально известную фразу «мы вам перезвоним». А сразу указывали на слабые стороны, которые нужно подкачать, чтобы профессионально подрасти.

Расставались почти друзьями, поскольку давали реально нужную для соискателя обратную связь.

Резюме: отличные результаты на всех уровнях — от джуниора до сеньора

Конечно, невозможно вложиться в жёсткое ограничение 35 минут. Но ни одно наше собеседование не длилось дольше 45 минут.

В результате KPI подхода с более-менее жёстким таймингом каждой фазы собеседования удаётся очень быстро отсеивать неподходящих кандидатов. При этом не приходится нагружать человека тестовым заданием и ждать результата около недели.

Для руководителя нашего подразделения серьёзно облегчилась проблема выбора — перед глазами чёткая таблица с ответами по теории, результатами практического задания и ожидаемой зарплатой кандидата.

Кстати, данный KPI подход отлично показал себя на всех уровнях соискателей на QA позицию — от джуниора до сеньора. Мы даже вопросы не меняли.

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

Бонус: список вопросов позапрошлогоднего интервью

  1. Что делает QA команда?
  2. Что делает QC команда?
  3. В чём разница между QC и QA?
  4. Какие вам известны техники тестирования «чёрным ящиком», которые также используются для дизайна тест-кейсов?
  5. Вы использовали на практике тестирование методом «белого ящика»?
  6. Расскажите поподробней, какие техники используются в методе тестирования «белого ящика»?
  7. Назовите обязательные критерии тестового плана?
  8. Как определить, что тестирование релиз-кандидата завершено?
  9. Напишите команду установки Android-приложения на смартфон с помощью командной строки.
  10. Напишите команду удаления Android-приложения с помощью командной строки.
  11. Вы получили новое Android-устройство, сделали первый его запуск, прошли мастер настройки, но не можете подключить устройство к компьютеру. Что не так и как это исправить?
  12. Чем вы пользуетесь из инструментов Android-разработчика (из SDK и в настройках самого телефона — для разработчиков)?
  13. Как вы фильтруете вывод логкэта, чтобы получать только нужную информацию?
  14. Что, на ваш взгляд, нужно обязательно проверять в каждом Android-приложении, если отсутствуют спецификации, требования и т. д.?
  15. Какая разница между терминами Monkey testing и Ad hoc testing?


Колонка подготовлена при участии Натальи Провалинской

По теме
Все материалы по теме

Хотите сообщить важную новость? Пишите в Телеграм-бот.

А также подписывайтесь на наш Телеграм-канал.

Горячие события

Gismart Online Meetup
9 декабря

Gismart Online Meetup

Минск

Читайте также

«Яндекс» представил умную колонку с экраном
«Яндекс» представил умную колонку с экраном
«Яндекс» представил умную колонку с экраном
QA создала чат двора и дала интервью The Guardian. Утром пришли из ДФР
QA создала чат двора и дала интервью The Guardian. Утром пришли из ДФР
QA создала чат двора и дала интервью The Guardian. Утром пришли из ДФР
За пару дней до Хэллоуина Шон Уолкер, журналист The Guardian, пришёл в минскую квартиру, чтобы сделать материал. Здесь он договорился встретиться с активистами одного из районных чатов. Хотел узнать, как с помощью телеграма соседи начинают дружить и помогать друг другу, устраивают концерты. Встреча закончилась в 10 вечера. На следующее утро в двери троих администраторов чата позвонили незнакомые люди. Как потом оказалось — из ДФР. Двоих админов забрали на допрос, один — собрал вещи и уехал из страны. Этим админом была создательница чата Анна (имя изменено). Она рассказала dev.by свою версию событий.
16 комментариев
Совсем скоро начинаются курсы по тестированию от Otus. Успейте записаться
Совсем скоро начинаются курсы по тестированию от Otus. Успейте записаться
Совсем скоро начинаются курсы по тестированию от Otus. Успейте записаться
На OTUS стартуют курсы по тестированию для специалистов с минимальным опытом в сфере. За 4 месяца вы сможете освоить новые инструменты и навыки. Регистрируйтесь и начинайте обучение уже завтра.
«Попросил СЕО помочь отцу с работой, если что». QA-лид получил 13 суток. Он сын мэра
«Попросил СЕО помочь отцу с работой, если что». QA-лид получил 13 суток. Он сын мэра
«Попросил СЕО помочь отцу с работой, если что». QA-лид получил 13 суток. Он сын мэра
QA-лид Andersen Филипп Зарянкин в день тайной инаугурации переходил улицу на Романовской слободе и попал на Окрестина. Молодой человек — сын мэра Витебска.
10 комментариев

Обсуждение

4

Есть маленький вопрос о статье -- почему "Android Team Lead в Softeq Development" занимается собеседованием qa инженеров а не QA manager/ QA lead ? Cобеседование разработчиков ему не доверяют ввиду каких-то причин руководство кампании ?

0

Очень резоный вопрос :) Как HR компании расскажу, что QA Lead Егор был несколько лет назад, и уже давно занимается разработкой мобильных приложений. Так что у нас все в компании хорошо: QA-инженеров собеседуют QA-лиды, а Егор теперь собеседует разработчиков :)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
1

Спасибо за ожидаемый вопрос :) Данная техника использовалась на предыдущем месте работы (Prestigio, Softteco), где я был ведущим тестировщиком и руководителем департамента тестирования соответственно.

2

Здравствуйте, Егор. Хорошая статья, спасибо Вам! Возникло несколько вопросов:
1. Блиц-опрос в письменной или устной форме?
2. Какие требования к документированию дефектов?
3. Как реагировали соискатели уровня Senior на подобные собеседования?
4. Проводили ли вы групповые собеседования по такой схеме? Если нет, то почему?
Заранее спасибо за ответы.:)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
4

Здравстуйте!

У проводящего собес есть таблица, с вопросами и ответами, со всеми багами в приложении.

1. Устно, тот кто проводит собес - тыркает балы в таблицу по устному ответу (чтобы не терять время)
2. Описание устное, а собеседующий в таблице помечает найден ли нужный дефект или нет, либо добавляет новый. Главное - попадание в суть и северити.
3. Senior-ы многие сдулись, теория не была критичной частью собеседования, исключительно на сообразительность в стрессовой ситуации. Ни одного человека не было, кто встречался с "белым ящиком" :) Но сеньоры хорошо оч показывали себя на практической части, здесь разница была уже сильно заметна. Сеньор - такое звание интересное, которые многие сами себе присваивают, просто просидев тестировщиком-джуном 3 года в одной компании и при переходе в новую, в резюме уже - сеньор, 3 года опыта :)
4. Нет, считаю это недопустимым

Пожалуйста, спрашивайте еще! :) Ну или приходите на наше событие пообщаться лично :) (30 июня в календаре dev.by)

-1

Егор, а ты считаешь групповые собеседования в принципе недопустимыми, или именно по такой методике они недопустимы для тебя?

-1

3. Как реагировали соискатели уровня Senior на подобные собеседования?
> так в статье был указан блок "ри всём великолепном знании теории не смогли найти даже одного-единственного дефекта в приложении из двух экранов. И при этом с запросом на зарплату в 2000$!" или другими словами в кампании наверное была вилка "не больше" а чтобы отказ был более-менее справедливым появлялись вопросы ака "Напишите команду удаления Android-приложения с помощью командной строки." и прочей сочности)
4. Проводили ли вы групповые собеседования по такой схеме? Если нет, то почему?
> только доминирование и подчинение)

3

Спасибо за статью.
Любопытно было бы увидеть аpk и список багов, из отработанного.
Удивила потребность в использовании командной строки , при наличии beta .

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
1

30 июня приходите на QA Battle 2016 :) Это событие, как раз выросло из нашей техники собеседований, только в чуть более крупном формате.

Удивила потребность в использовании командной строки , при наличии beta .

Ничего не понятно :(

0

30 июня приходите на QA Battle 2016 :)
> участие как всегда платное?) для зрителей и участников ?)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
1

Дима, ну не первый год мы с вами на эту тему уже общаемся. Журналистам бесплатно! (=

Если вы готовы оплатить все издержки из собственного бюджета - делаем всем возврат билетов на карточки и мероприятие становится бесплатным :)

0

Нанимал в том числе и QA джуниоров. Никакой теорией не мучал, просто собеседовал как девелоперов. Тех кто согласился взял. Ни разу потом не пожалел. Времени тратится не много, в среднем за 2 собеса один подходящий кандидат.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-2

С джунами да, ищешь просто таланта или ломовую лошадь. А с мидами и сеньорами уже посложнее.

0

" Каждый руководитель ведёт метрики эффективности, так вот эти ребята находили от 80 до 120 дефектов в месяц".
Расскажите, пожалуйста, поподробнее про то какие метрики эффективности ведут руководители.
Спасибо !

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Расскажите, пожалуйста, поподробнее про то какие метрики эффективности ведут руководители.

У каждого свои метрики, продиктованные проектной необходимостью или какими-то другими условиями. В основном это различные KPI сотрудника, которые характеризуют его профессиональные качества. Если в компании есть программа профессионального развития - то соответствующие показатели также учитываются, контролируются и проверяются. По тестировщикам - значимые KPI, например, сколько его дефектов закрыто, как can't reproduce, won't fix, incompete и тд. Какой процент accepted дефектов командой разработки и resolved as fixed. Все по ситуации и как правило, если есть какая-то проблема. Если все ребята вджобывают, как ты сам, то смысла тратить силы на метрики - нет :) А если все вджобывают, а один в 9:00 пришел, в 17:45 ушел, за день ни одного дефекта не нашел.. Проблема? Очевидно - да. Приходите на батл в четверг, там будут хорошие окна временные пообщаться на любые темы с экспертами отрасли.

0

Чего-то любопытно стало:
>> А если все вджобывают, а один в 9:00 пришел, в 17:45 ушел ...

Это вы на что намекаете? Временное окошечко же вроде как ок (если я не разучился считать от только что съеденного супца).

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Супец :)

за день ни одного дефекта не нашел..

В случае с такими ребятами вести их личный KPI - обязательно. (Если нет возможности или желания уволить :D)

-1

От блин, т.е. если я напишу безбажный код - кого-то за это поругают? :(

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
1

Если дефекты не найдены - это нормальная ситуация (хотя и крайне редкая). Но при этом на выходе дня должен быть список проверенных модулей, функционала, экранов или других частей приложения, желательно в соответствии с тест кейсами со статусами - "проверено и работает".

В случае, когда дефекты не найдены, а на вопрос - а чем ты занималсь целый день получаешь ответ - ну я тут потыркала, там потыркала вроде работает - за такое наругают :)

-1

"В случае, когда дефекты не найдены, а на вопрос - а чем ты занималсь целый день получаешь ответ - ну я тут потыркала, там потыркала вроде работает - за такое наругают"

Сексист! :-)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Да не, просто были случаи :) Есть категория людей, убежденных, что айтишникам (неважно QA или нет) платят деньги за присутствие в офисе 8ч в день :) Собственно из-за подобной категории людей KPI собеседования и были разработаны, чтобы нанимать людей без последующей текучки кадров.

1

Вообще для этого существуют не kpi, а банальные task managers. Где ставиться задача -
"протыркать такой-то модуль, срок 1 день". И факт её закрытия или не закрытия и говорит об эффективности работы. Зачем нам kpi если задач не ставиться?

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Не все так просто. Как определить факт закрытия задачи, со слов исполнителя? Или по каким-то объективным индикаторам?

0

К закрытой задаче должны быть приложены тест кейсы проверенные! Сами скрипты кейсов+результаты. Мало того они еще и ревьювятся лидом, до выполнения.

Anonymous
Anonymous CTO в Lansoft
4

О божеее, а как проверить Вас как тим лида, что вы эффективно провели на работе день? То, что вы составили метрики на людей - в чем эффективность для проекта? Этими метрики не тестировались, ни кем не одобрены, кроме лично Вас. Есть задача, есть время выполнения этой задачи. Не вложился в срок - надо еще узнать причину, может менеджер оценку сделал глупую. Сделал быстрее - ок, я лично сделаю выборочное тестирование по задаче, и если мне ничего не попало подозрительного - молодец, попало подозрительное - сиди и работай дальше.
Многие компании превратились в сборище манагеров и лидов, которые пиарят свои собственные наработки в области "я знаю лучше других как контролировать других людей и их работу". Может это все для научных работ магистратуре-аспирантуре? Из них большинство уже кроме как "перекладывать задачи на других" больше ничего и не умеет (забыли).

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-3

может менеджер оценку сделал глупую

Менеджер дает оценку? Мы с одной планеты? :)

Anonymous
Anonymous CTO в Lansoft
1

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

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-2

Евгения, как исполнитель может не знать, за сколько он выполнит свою профессиональную обязанность? А менеджер в то же время получается - знает? :)

Anonymous
Anonymous CTO в Lansoft
1

Команда: Менеджер проекта+команда тестирования. Менеджер проекта пишет план (я понимаю, что у вас agile, но не ужели у вас менеджеры не занимаются планами и распределением средств?), прежде чем дать оценку он идет к кому? Он идет к тестирам и не простым, а постарше так по званию (хоть QA их зовите,хоть QC, хоть горшком) и спрашивает - сколько вам надо на тестирование? QA дает оценку - 1000 часов. И будет этим заниматься Вася и Маша, Вася и Маша придут из другого проекта, только на время тестирования (Вам не знакома миграция тестировщиков от проекта к проекту?) Манагер услышал про 1000 часов, посчитал смету и говорит: "Нет дорогой ты мой QA-QC-горшок, у нас всего на проект выделено средств на 500 часов тестирования. Так что как хочешь так и вложись мне в 500 часов."
Подумал QA-QC-горшок и придумал, что возьмет он не Васю и Машу, а Катю и Петю, потому что у них зп поменьше, а значит они могут и 1000 часов тестировать. Пришел и снова говорит "Дорогой ты наш, повелитель средств! Мы так хотим протестировать "белым ящиком"приложение, и провести тестирование после каждой итерации, я нашел выход, я потрачу 100 часов и напишу подробные сценарии, дам их дешевым джуниорам в работу, только дай нам 1000 часов!" Обрадовался манагер услышав фразу "могу взять дешевых" и сказал "Нет, 500 часов и дешевые джуниоры меня устраивают! А дальше хоть белым, хоть черным, хоть серым, хоть красным ящиком."

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-2

Как все запущено.. =)

Anonymous
Anonymous CTO в Lansoft
2

Да, детка, люди не только фонарики пишут и читалки ;) у людей есть бюджет и продукт на несколько лет разработки и развития. А вы тут ради тестирования читалок KPI-метрики придумываете. Целую крепко, ваша репка!

Сергей Зеневич
Сергей Зеневич зам директора в SoftTeco
3

Егор, отличная статья!

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

Удачи тебе! :-)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Сергей, спасибо. Видеть твой комментарий - награда для меня, оправдывающая все трудозатраты!

Удачи и успеха во всех твоих начинаниях!

2

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

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

Вообще я рад за Вас,предлагаю запатентавать и продать Гуглу ;)

-1

При этом я абсолютно уверен что в целом я бы оттестировал бы на проекте намного лучше и быстрее чем любой ваш кандитат, включая Вас самого ..

Слишком толсто :)

Встречаемся на QA Battle 2017? :D

2

>> Слишком толсто :)
Это скорее к статье вцелом относиться )
>> Встречаемся на QA Battle 2017? :D
Только при участии Егора в качестве участника и уверрености в том что задания готовлись 3ми лицами никак несвязанными с ним)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-2

При этом я абсолютно уверен что в целом я бы оттестировал бы на проекте намного лучше и быстрее чем любой ваш кандитат, включая Вас самого ..

Гитлер тоже был много в чем абсолютно уверен :)

4

У вас здесь в комментариях так сладко и елейно, аж попа слипается... как тут не разбавить ;)
Нет, у вас тут всё, конечно, правильно и логично, но скучно же!!! :)))
И так собеседование - стресс, так они ещё какое то ЕГЭ из приёма на работу умудрились устроить - KPI ввести...
Вот как тут нормально жить: в гимназию пойти - тестирование... в ВУЗ поступить - тестирование... права получить - тестирование... На работу устроиться - и тут тоже тестирование всунули... Уже в ЗАГС страшно идти...
А где же живое человеческое общение? В каких KPI измерить "горящие глаза"?
Поэтому Егора и прочих соучастных немедленно заставить смотреть футбол, где выигрывшей считается команда не забившая больше пусть и нелепых, но голов, а набравшая больше KPI: по проценту владения мячом, расстоянию, преодалевшему игроками команды, по проценту точных пасов и т.д. Вот можно ещё по совокупной стоимости игроков победу присуждать... :)
А мы и дальше будем смотреть футбол, где Исландия побеждает Англию, а Италия Португалию...
Ответ же на Вашу теорию, Егор, отлично продемонстрирован в фильме Moneyball. Да, набрёте вы команду с лучшими KPI, и они, действительно, будут лучшей командой, демонстрирующей лучший KPI, но просто этого будет явно не достаточно, что б выйграть Супербоул или Мировую серию... Так а ради чего, Егор, вы создаёте команду? Ради KPI или ради супербоула? ;)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

В случае с командами - соотношение забитых и пропущенных мячей, как раз и будет KPI :)
По русски - Ключевой индикатор производительности, если брать ваш пример с футоболом, то, русские однозначно воспринимают KPI ровно так, как вы и описали :)

Описанный в статье подход решил в то время важные проблемы - текучку QA кадров и серьезно поднялось качество работы QA команды.

2

Поэтому Егора и прочих соучастных немедленно заставить смотреть футбол, где выигрывшей считается команда не забившая больше пусть и нелепых, но голов, а набравшая больше KPI: по проценту владения мячом, расстоянию, преодалевшему игроками команды, по проценту точных пасов и т.д. Вот можно ещё по совокупной стоимости игроков победу присуждать... :)
> Mihail.che знатно снимаю шляпу)
Еще заметил, что такие подходы аккурат как возвращение к давно забытому старому с оголтелыми "пятилетку за три года", "красной машине" и молоку в "пакетике-тетраэдере" ... или как обязательные тренировки кахеистов кхл со штрафами за опоздание в сравнение с нхл где через день игра на которую ты приезжаешь подготовленным
ЗЫ: "а сколько ты сегодня багов нашел" "сколько строчек кода написал" "нас не волнует что ты закрыл таск и заказчик доволен" " у васи напротив тебя КPI выше и по результатам года и он получил свои $100 к окладу) а ты нет"

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Дима, а чем вы вообще занимаетесь в реальной жизни? :)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

То что ты закрыл таск и заказчик доволен - может абсолютно ничего не значить для бизнеса, если заказчик за это не заплатил :) KPI - это инструмент по обстоятельствам, а про строчки кода и тд, давно уже известно, что это самая неэффективная метрика для оценки индивидуума и подходит только для больших команд или больших продуктов, и то, для приблизительной оценки трудозатрат.
Например, строк кода в ядре Линукс:
1991 Ядро Linux 0.1 10 239
2009 Ядро Linux 2.6.32 12 606 910

Очевидно, что за 18 лет, все таки что-то делали :)

1

Спасибо, Егор, что для меня дурака хоть на русский язык перевели, поучили меня. Теперь я поучу Вас :)
>> В случае с командами - соотношение забитых и пропущенных мячей, как раз и будет KPI
1) Это очень плохой KPI, показывающий очень мало полезного. Да вообще, по сути, ничего не показывающий :) Команды приезжают на чемпионат не для того, что бы забить побольше голов, а пропустить поменьше, а для того, что бы выиграть чемпионат и занять первое (ну или самое высокое по возможности) место среди всех претендентов. Это главная цель и ожидаемый результат. Итого хороший KPI для команды - это место занятое на чемпионате. Вы можете возразить, что мол при равном положении по результатам группового этапа и ничьей между командами как раз и используют показатель, основанный на оценке числа забитых и пропущенных мячей. Но и здесь, я обращаю ваше внимание, зачастую используют не соотношение забитых и пропущенных мячей, а их разницу. Ибо если в математике соотношение 3 к 1 и 15 к 5 имеет абсолютно одинаковый смысл, то в реальной жизни 15 забитых мячей к 5 пропущенным, согласитесь, смотрится поинтереснее, чем 3 к 1.
2) Вы акцентируете внимание на слове "производительность", раз вы именно так перевели этот термин. Но лично для меня, сугубо по моему дилетантскому мнению (что б никого не обидеть), "производительность" это самый "кривой" из переводов. Я бы использовал всё таки слова "результативность" или "эффективность" (хотя со вторым тут тоже вопросы). Всё таки производительность это отношение полученного результата к затрачиваемым ресурсам. Ведь при такой оценке какая-нибудь сборная России, которая вообще не готовилась и особо никаких ресурсов в виде усилий не затрачивала, но в итоге с нулевым затраченным ресурсом заняла хоть какое то там n-надцатое место, получается обладает сумасшедшей производительностью :)))
3) Даже для футболиста число забитых голов с точки зрения командной игры далеко не супер KPI. И команда составленная из 11 Мессии или Роналду, но вот никак не выиграет чемпионат. Надеюсь, не надо объяснять почему? А что вы делаете, когда основной упор при наборе делаете на какие то там тестирования и KPI? - вы и пытаетесь набрать команду из 11 Роналду!..
>> то, русские однозначно воспринимают KPI ровно так, как вы и описали :)
если не секрет, расскажите как же воспринимают KPI "нерусские"? ;)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-1

Я всегда открыт к обучению и всегда рад, когда есть люди способные чему-то научить, сейчас это редкость :) За это сразу ставлю плюс!

По большому счету я с вами согласен, но не согласен в том, что вы не признаете разницу забитых и пропущенных мячей ключевым показателем команды. Команда у которой этот показатель будет самым лучшим - станет чемпионом евро 2016. Очевидно, что этот показатель не единственный, но это главный верхнеуровневый индикатор успешности команды, который можно декомпозировать на составляющие, отвечая на вопрос, благодаря чему команда смогла добиться такого показателя? В ответе будут заложена совокупность второстепенных показателей: количество успешных пассов, набеганная дистанция, отбор, процент забивания пенальти и тд. Но все эти показатели лишь составляющие ключевого показателя, которым можно характеризовать команду в целом, всего одним показателем. Но за ним стоят сотни других - этого не отнять. С точки зрения управления, менеджеры опираются на данные показатели - это нормально. Есть талантливые менеджеры которые могут принимать мгновенные верные решения лишь на базе интуиции - но это единицы. Я не знаю наверняка, как на западе воспринимают KPI, но в большинстве случаев они его используют (судя по тем проектам, в которых я работал последние 8 лет).

0

>> вы не признаете разницу забитых и пропущенных мячей
Егор, ай не хорошо... терминам типа "отношение", "слогаемые", "делимое", "делитель", "разность" учат уже в начальной школе... "соотношение и разница" - я на этом в своём комментарии даже акцентировал внимание ;)
>> Команда у которой этот показатель будет самым лучшим - станет чемпионом евро 2016.
>> это главный верхнеуровневый индикатор успешности команды
вы, наверное, не очень увлекаетесь футболом? ;)

-2

специально ждал оканчания евро 2016, что б подтвердить свои слова... ибо мне тут иногда пишут "демогог" и "балобол", но в отличие от других "балоболов" (это не в ваш огород камень, не подумайте лишнего) я пытаюсь подтвердить свои аргументы фактами...
Итак по поводу "главного верхнеуровневого индикатора успешности команды" и "ключевого показателя".
Показатель "Разница забитых и пропущенный мячей":
Франция - 8 (!)
Уэльс, Португалия, Бельгия, Германия, Италия - 4.
Вы видите Португалию, опережающую на голову по этому показателю все остальные команды? И я нет... Зато я вижу Францию....
Статистика по забитым голам (показатель "голов за матч" - наиболее справедливый, так как отражает поправку на количество проведенных матчей).
Франция - 1.86
Бельгия - 1.8
Уэльс - 1.67
Исландия - 1.6
Венгрия - 1.5
Опять же... где же Португалия?.. Но мы же (вы же) говорили, что забивать побольше и пропускать поменьше это и есть основной ("самый главный", "верхнеуровневый" и какие там ещё эпитеты...) показатель успешности, то есть гарантирующий победу в соревновании.
А оказалось, что важно не с какой разницей голов побеждать, главное - побеждать... пусть с минимальной разницей... пусть даже с одним голом... но побеждать! ;)
Может так и с вашими KPI? Может не так уж и важно 120 багов в день находить? ;)
---
Егор, так как не первый раз вижу такие примеры, я предлагаю замутить статью по теме: как менеджеры выбирают KPI и почему зачастую они совершенно не эффективны и не показательны...

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Выбрать верный KPI - это искусство :) Как и выбрать те условия, в которых он будет информативным.

Вы выбрали суммарный показатель за весь чемпионат - поэтому Португалия туда не особо попала, а вы разбейте этот показатель на соответствующие стадии чемпионата, KPI группового этапа, KPI 1/8, KPI 1/4, KPI 1/2, KPI финала и сразу все станет на свои места :)

Смотрим групповую фазу:

Played Won Draw Lost For Against Goal difference Points
FRANCE 3 2 1 0 4 1 3 7
SWIZ 3 1 2 0 2 1 1 5
ALBANIA 3 1 0 2 1 3 -2 3
ROMANIA 3 0 1 2 2 4 -2 1

У Франции в группе лучшая разница по голам :)

В то время, как Португалия поставила задачу минимум и просто вышла из группы с нулевой разницей.

Если сравнить эти две команды, то очевидно, что Франция показала с двумя победами себя лучше, чем Португалия.

Переходим к фазам на выбывание:
Португалия и Франция постоянно показывают разницу забитых и пропущенных > 0, тем самым встречаются в финале.

В финале, Португалия показывает разницу забитых и пропущенных > 0, тем самым побеждая Францию. Все сходится! Просто вы KPI применили суммарно для всего чемпионата, не учитывая контекста отборочных раундов (группа, 1/8, 1/4, 1/2, финал).

Кстати, если бы не было групповых этапов, а все раунды соревнования были на выбывание, то ваш суммарный KPI стал бы в этом случае на 100% рабочим и именно он бы показал финалиста по лучшему результату.

0

Егор, а как у вас с атмосферой в коллективе?)) В qa отделе.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Я ж уже не работаю в QA, было отлично, т.к. все вджобыватели, примерно одинаковые по характеру, темпераменту, жизненным взглядам и целям. До этого когда были "разгильдосы" - конечно напряжение было. Счастлив, что от них удалось избавиться. Т.к. приходилось за ними много косяков доделывать и получать персонально за каждый их косяк от заказчиков и руководства, но это уже совсем другая история, про ведра валерьянки :)

Юрий Красовский
Юрий Красовский Web Developer в Wargaming / Гейм Стрим
0

Спасибо за статью!
Егор, скажите пожалуйста, что заставило Вас перейти из QA в разработку? Если можно то поподробнее :-)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Спасибо на добром слове! Надеюсь вы нашли что-нибудь полезное для себя в этом материале и мои труды не пропали зря :)

Если кратко - надоело и нет такой эмоциональной отдачи, как от разработки, ну и необходимость в творческой компоненте сыграла тоже не последнюю роль. Плюнув на зарплаты, должности и прочие успехи перешел в Android разработку :)

9

Замечательная статья! Но, Егор, зачем вы подобным подходом ограничиваетесь только на собеседованиях? Поэтому вот просто не мог такую же статью не написать:)
---
mihail_che методом проб и ошибок разработал алгоритм, который позволяет ему разводить девушку на секс укладываясь в 35 (максимум — в 45) минут.
Все мы сейчас живем в режиме жёсткой мультизадачности и постоянно вынуждены переключаться между разными контекстами. А ведь чем меньше вы отвлекаетесь от ключевой задачи — тем быстрее она будет выполнена.
Но иногда сложно отказать себе в удовольствии провести время с новой девушкой. Себя испытать да на людей посмотреть с горящими глазами и зашкаливающей мотивацией.
Проблема N1: затяжные собеседования с 80% «сильных теоретиков»
Обычно, когда сообщаешь девушке, что ты холостой программист, от желающих встречаться отбоя нет. На первом свидании сразу заметно, что 80% соискательниц реально сильно подготовились. Причёска, платье, лабутены. Боевой раскрас. И выходит, что из 10 человек — 8 показывают примерно одинаковый уровень.
На первых порах это обстоятельство было главным тормозом. Да, когда начинаешь копать, сразу выявляются белые пятна: "Я не такая". "Надо сначала лучше узнать друг друга". "Мама учила, что секс только после свадьбы." Но такие "раскопки", когда их приходится проводить в 80% случаев, отнимают существенно больше времени и надолго отрывают от "горячей технической задачи по текущему проекту." ;)
После серии затяжных свиданий стало понятно, что дальше так продолжать нельзя. Проекты "горят" (да какие там проекты - всё "горит") соискатели не подходят, время уходит впустую.
Проблема N2: тестовое задание с недельной отсрочкой
После некоторого анализа принял первую попытку улучшить процесс. Да — добавил предварительное удаленное общение для junior-категории. Тестовое задание заключалось в нескольких предварительных беседах в viber или контакте с обменом фотографиями. Соискатель должна была по итогам недели разговоров выслать фото топлес. Оценивалось также креативность подхода к выполнению задания, оформление, скорость выполнения задания. В результате из 8 девушек отсеялось около 6. Выбор из оставшихся двух уже обосновывался косвенными показателями. Одна девочка вообще буквально за выходные прошла тестовое задание. Женя, привет!
В принципе, этот подход отлично работал, если бы не одно "но". Неделя. Ждать целую неделю — мучительно долго и скучно. Хотелось быстрее, с помощью каких-нибудь показателей, получаемых в реальном времени прямо во время свидания.
KPI: отсеивание «болтунов» с запросом на зарплату в $2000
Стало очевидно, что необходимо тестовое задание - "топлес" включать прямо в процесс свидания. Ведь всё равно уже встретились, все возможности, как говориться, есть на руках. Вопросы по теории тоже были тщательно переработаны. Выбрал 15 блиц-вопросов на 15 минут, на сколько из них соискательница отвечает — столько баллов и идёт в зачёт. "Показать грудь" - 10 баллов. Итого максимум 25 баллов. Получилась своеобразная KPI (Key Performance Indicators, ключевые показатели эффективности) таблица соискательниц — по теории и по практике.
Забавно, но никто ни разу не смог набрать максимум, хотя были девушки, которые, что там грудь, показывали такое... По результатам нескольких десятков собеседований сразу стало очевидно, что некоторые соискательницы — откровенные болтушки, которые при всём великолепном знании теории не смогли даже в щёчку после свидания поцеловать. И при этом с запросами - подарки, рестораны, путешествия - ну не меньше 2000$ в месяц!
Сюрпризы 35-минутного собеседования
Очень удивило, что существуют девушки, которые отключаются прямо во время KPI-свидания, впадая в ступор. При затяжных свиданиях такого никогда не наблюдалось. Например, во время быстрого опроса около десятка девушек просто сказали: фу, что за гадости, что за вопросы, как ты такое вообще смеешь спрашивать, не буду отвечать ни на один вопрос. После просьбы показать грудь и снять себе на телефон некоторые из девушек предположили, что хочу этим воспользоваться в корыстных целях. От такой дичи в ступор можно впасть, правда?
Табу на «мы вам перезвоним»
Каждой девушке, которая по своим KPI мне точно не подходила, не говорил печально известную фразу "давай останемся друзьями" или "Я тебе перезвоню". А сразу честно указывал на слабые стороны, которые нужно подкачать, чтобы больше нравиться парням. Расставались почти друзьями, поскольку давал реально нужную обратную связь, правда некоторое время болела щека.
Резюме: отличные результаты на всех уровнях — от молоденьких девушек до молодых женщин.
Конечно, невозможно вложиться в жёсткое ограничение 35 минут. Но теперь ни одно наше свидание не длилось дольше 45 минут. Но главное - никаких предварительных долгих свиданий и букетно-конфетного периода! Всё чётко и сразу к делу!
В результате KPI подхода с более-менее жёстким таймингом каждой фазы свидания удаётся очень быстро отсеивать неподходящих кандидатов. Кстати, данный KPI подход отлично показал себя на всех уровнях - от студенток до уже вполне себе состоявшихся зрелых женщин. Даже вопросы не менял.
По моим наблюдениям, ключевая разница между этими уровнями заключалась фактически в скорости и качестве выполнения тестового задания. С точки зрения теории зрелые женщины проявили себя лучше, что вполне ожидаемо.
Бонус: список вопросов позапрошлогоднего интервью
1.Глотаешь?
2. ...
Дальше список не приводится по этическим соображениям.
Всем удачных быстрых KPI-собеседований!!!
---
Колонка подготовлена без участия и помощи Натальи Провалинской (кстати, вот почему?) :(

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

LOL! Вот это я реально крутой алгоритм разработал, подходит для всех жизненных ситуаций основанных на проблеме выбора! michail_che пищи еще! :D :D :D

Сорвал мне серию в 10 статей про KPI подход xDDDD

Сюрпризы 35-минутного собеседования - вот это ваще супер вышло! :D

1

>> Сорвал мне серию в 10 статей
и правильно, нечего превращаться в доктора Беловешкина :))
---
а идея с KPI в собеседовании хорошая (не сарказм), как я выше и писал, мне она нравится, например, как возможность превнесения большей прозрачности в процесс отбора кандидатов. Существенно облегчает процесс объяснения кандидату, почему он такой умный и красивый не прошёл, а вот того рядом сидящего взяли. Если только на ней не зацикливаться, конечно. Ибо творческую составляющую убивает напрочь. ;)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-1

michail_che - как уже писали - снимаю шляпу, вы сделали мой день! :)

1

[внимательно переписал в блокнотик]

3

Читать Вашу статью было интереснее чем статью Егора.

0

в 10 статей про KPI
> cнова про QA или на этот раз по специальности Android team interview ? :)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-2

Да, QA Battle доделать в этом году (каком году.. 3 часа до начала!!1 А печенье еще не куплено) И расстаться с любимым QA, впрыгнув в объятия новой страсти Android разработки с головой :)

1

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

По методике: я бы не хотел таким баловаться. Отсеешь тех, кто долго запрягает, но потом быстро едет. Но если вас всё устраивает и даёт результаты - то отлично, вы нашли свою методику, почему бы и нет.

Кстати, кандидатов предупреждают, как будет проходить собеседование?

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-1

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

Anonymous
Anonymous CTO в Lansoft
2

Егор, объясните зачем на собеседовании Вы используете специфические вопросы по работе с Android. Т.е Вы реально считаете, что Вам нужны люди уже родившиеся со знаниями работы с Android из командной строки? Т.е кандидат, который имеет опыт работы в QA, в QC (назовите уже как хотите, сути это не изменит), имеет диплом БГУИРа или БГУ, но никогда не работавший на Android-проектах Вам не подходит, и пофиг на то, что все это можно постичь за неделю работы на проекте (какая-то дискриминация по возрастному принципу "Ты родился в эру Android - ты нам подходишь!"). Вы сами, то когда шли работать в тестирование знали это все?

Последнее время, просто убивают описания вакансий, описание как проходят собеседования. Такое ощущение, что это конкурс HRов и манагеров. Почитаешь вакансии, пообщаешься с HRами, и хочется провести собеседование им, проверить их уровень подготовленности. По поводу кандидатов с требованиями по зарплате тоже хочется сказать. Глядя на описания вакансий, и стресса при прохождении таких вот описанных выше собеседований, хочется посмотреть на тех кто просит на ваших собеседования зп по 500$ и счастлив работать за еду.

Собственно, что хотела сказать. Все собеседования в которых участвовала я проходили по принципу
- где учился?
- как учился?
- где работал?
- почему уходишь?
И разговор про тестирование на бытовом уровне. Потому что мне важно чтобы человек понимал принципы, мог самостоятельно разобраться и ответственно подходил к работе. А знает ли он команды линукса, андроида или еще что-то меня интересует мало. Завтра выйдут приложения под hololens я найду кандидата за неделю, проводя по 2-3 собеседования в день. А Вам еще придется вопросы придумать про hololens ;)

2

подписываюсь под каждым словом. принцип тестирования один и тот же, меняются только инструменты. У меня вообще создалось впечатление, что начали делить всех тестеров на desktop, mobile, web. Ну вот зачем это все?

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-2

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

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

что начали делить всех тестеров на desktop, mobile, web. Ну вот зачем это все?

Давно уже делят.. Web QA не сможет качественно протестить мобильный аплик and vice versa. Специфики на каждой платформе становится уже так много, что не все к этому готовы.

А Вам еще придется вопросы придумать про hololens ;)

Да, в моем случае, я их придумаю, изучив хотя бы поверхностно hololens и начну различать кандидатов, кто в теме, а кто нет. А Ваш профессиональный уровень останется прежним. Кто из нас теряет больше? :)

что все это можно постичь за неделю работы на проекте

Успехов, в постижении особенностей платформы Android за неделю :)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Да и Hololens в офисе есть, чего бы не попробовать из инженерного любопытства :)

Anonymous
Anonymous CTO в Lansoft
1

Это вы зря все написали. Потому, что прочитав вашу пиар-статью о том как вы из строителей стали лидом, мне вообще не хочется с Вами вступать в дебаты. Т.е вы считаете, что вы такой троешник из БНТУ который смог из строителей стать тим лидом смогли осилить особенности платформы, а кто-то другой не в силах? У вас комплексы, молодой человек. И эти комплексы вы прикрываете тем, что унижаете других людей своими тестами на профпригодность.

Талантов вы ищите. Надо искать людей с образованием, и людей умеющих работать, и думать! А такие вот "таланты" со стройки и строить не умеют качественно дома, и программы писать не умеют, зато все знают про то как все остальные должны работать.

За мой "профессиональный уровень" вы не беспокойтесь. Я не пытаюсь везде сунуть свой нос. Чтобы быть этакой "всезнайкой", знающей всего по немного, и думающей, что это круто.
Я найду человека, который способен работать с hololens, а сама буду заниматься своим делом.

3

То есть вы не талантов ищете, а конкретно тестеров, которые знают как тестить android. Не все таланты - тестируют андроид, не все андроид тестировщики - таланты.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-3

Складывается чувство, что я вам лично нанес смертельную рану какую-то...

- Потому, что прочитав вашу пиар-статью о том как вы из строителей стали лидом
- А такие вот "таланты" со стройки и строить не умеют качественно дома
- У вас комплексы, молодой человек
- вы такой троешник из БНТУ
- унижаете других людей своими тестами на профпригодность.
- Чтобы быть этакой "всезнайкой", знающей всего по немного, и думающей, что это круто.

У троеЧника, диплом инженера-программиста и диплом магистра технических наук БНТУ ФИТР со средним баллом 8.86 (одна 5ка, остальные 9, 10). Это так.. на минуточку :)

У мя два вопроса:
- Вы всерьез считаете, что телекоммуникационные инженеры строят дома?

#1 Вы утверждаете, что прочитали статью (мое интервью dev.by)
#2 Вы утверждаете, что инженеры по строительству телекоммуникаций строят дома...
#3 Известный факт, что вы закончили БГУИР (весьма уважаемый мной университет)
#4 Известный факт (исходя из вашего профиля), что вы работаете QA в LanSoft
#5 Вы утверждаете: Надо искать людей с образованием, и людей умеющих работать, и думать!

- Хотите, я напишу вам вывод - о вашей профпригодности QA исходя из изложенных пунктов выше без всяких KPI и собеседований вообще? :)
(для полноты картины не хватает только вашего уровня владения Английским языком)

То есть вы не талантов ищете, а конкретно тестеров, которые знают как тестить android. Не все таланты - тестируют андроид, не все андроид тестировщики - таланты.

Мы искали людей на пересечении этих двух множеств, чтобы получить: талант + андроид :) Т.к. стояли очень амбициозные задачи.

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

Anonymous
Anonymous CTO в Lansoft
-3

Хотите, я напишу вам вывод - о вашей профпригодности QA исходя из изложенных пунктов выше без всяких KPI и собеседований вообще? :)
- не приведи Господь, чтоб меня оценивали Вы!

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

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

Складывается чувство, что я вам лично нанес смертельную рану какую-то.
- не надейтесь! Но вот такие статеечки на дев.бае уже вызывают тошноту. Как все идут в QA, как становятся лидами,манагерами и пытаются взрастить других на своих велосипедах. И рассказывают как они лучшую команду собрали. Вот статья которая про kpi , но она не бесит . Почитайте, подумайте, может поймёте...философию ж на 9 сдали https://habrahabr.ru/post/152445/

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-2

- ваши слова в статье были о том как Вы работали на стройке

Мммм.. и что? Строят только дома в вашем понимании, остальное материализуется из вселенского эфира? Как на вашей планете появляются дороги, мосты, кабельные сети?

ВНИМАНИЕ Разрыв шаблона: обе ступени высшего образования я получил платно, за собственные деньги, поэтому не был обременен проблемой распределения, а после Центра Проф Образования отработал 5 лет распределения на МТИСе - строя высокоскоростную магистральную линию оптоволоконной линии связи г. Минска. Что теперь ответите? :D

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-1

Evgenia Raneeva

Окей, суть ответа я понял: "Ой, все, держи -1!" :D

Anonymous
Anonymous CTO в Lansoft
3

Да мне так пофиг уже что вы мне тут ответили. Я уже почитала, как "тонкий психолог" у каждого спрашивает возьмет ли он себе в команду человека, который сказал "фу-фу-фу". Я ТААААК РААААДА, что Softeq меня не возьмет! Я туда даже не хочу хотеть теперь. Ни за фанту, ни за разрешение писать поучительные статьи на dev.by. Пойду читать habr. Шлю воздушные поцелуи "тонким психологам"

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

3й коммент к статье - к Softeq никакого отношения данная система собесов не имеет. Собсна, как и я к QA, уже больше года =) Данный подход практиковался мной на предыдущих местах работы.

"Комент пишу, материал не читаю"? :)

Anonymous
Anonymous CTO в Lansoft
0

Да все мы поняли, что в softeq именно таким способом именно Вы не собеседуете в отдел качества, но осадочек-то остался!

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Ну слава богу на 105 комменте, таки поняли :)

2

Никогда не понимал вопросов по теории в тестировании, за 4 года работы они мне ни разу не понадобилась. Всем должен руководствовать здравый смысл, а касательно самой идеи так в Гугле тестировщиков нет как таковых (вопрос почему?)
Особенно касательно QA и QC или тестового плана. Вы всерьез думаете что Junior Test Engineer должен знать ответы на эти вопросы?
В целом за правильный подход к интервью в виде фокусирования на реальной работе +, в качестве каких-то доп. вопросов про android commands or SDK и других теоритечских вопросов -. Это все вопросы 1ой минуты поиска в гугле. Ну правда, может быть же человек который ничего в этом не знает, но умеет ловить баги + адекватный и в 10 раз он будет лучше того, кто знает все ответы на ваши вопросы и найдет лишь только половину.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

но умеет ловить баги + адекватный и в 10 раз он будет лучше того, кто знает все ответы на ваши вопросы и найдет лишь только половину.

Почему все делят теорию или практику, мы набирали тех, кто силен и там, и там :) Из вашего примера, если бы был третий человек, который лучше обоих показал практику и лучше обоих показал теорию, и со стороны человеческих качеств зарекомендовал себя - ответ очевиден, кого взять из троих. Почитайте выше комменты Evgenia Raneeva вы бы себе такого специалиста взяли в команду? :)

0

Дело не в личности, а в целом к подходу.
Отвечая на Ваш вопрос, такого кандидата я бы не взял, потому что истины нет, есть мнения, но переходить на личности не стоит ни в каком случае: скорее всего такой человек в работе будет искать крайнего, а не понимать что собственно все в проекте - это большая сплоченная команда и крайних нет.
Касательно второго пункта: теория не очень часто применима как есть в прикладном искусстве разработки проекта: Вы когда-нибудь слышали, чтобы там, в куллуарах, QA обсуждали: давайте здесь мы будем применить тестирование белого ящика по такому-то паттерну. Junior QA Engineer вряд ли вообще может настроить проект, не говоря о том, чтобы читать и разбирать код.
Опять же, не разводя холиваров - мой основной пункт заключается в том, что теория вряд ли помогает отобрать нужного кандидата, разве что отвечает на вопрос является ли кандидат усидчивым. Когда человек делает тестовое задание - Вы можете понять как он рассуждает, чем больше заданий, тем больше понимания. Для джуниора ИМХО - это главное, умение задавать вопросы и рассуждать, а не только искать и находить баги. я бы в себе в команду вряд ли взял человека, который умеет находить только баги и знает теорию, но он ВСЕГДА прав и не может найти общего с разработчиками.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
1

давайте здесь мы будем применить тестирование белого ящика по такому-то паттерну

Буквально 4 дня назад с ребятами в кулуарах обсуждали :)
На вопросы по белому ящику на QA Battle 2 человека отличные ответы дали по методикам анализа пути, решений и ветвей..

что теория вряд ли помогает отобрать нужного кандидата, разве что отвечает на вопрос является ли кандидат усидчивым

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

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

Junior QA Engineer вряд ли вообще может настроить проект, не говоря о том, чтобы читать и разбирать код.

По описанной методике, в топ выбивались именно такие Junior/Mid QA, которые могли самостоятельно и проект настроить (т.к. необходимо было автотесты совместимости/соответствия Google запускать на всех прошивках), и тест кейсы писать, и оценить объем необходимого тестирования. Как говориться, на каждый товар - свой покупатель.

0

Ну в ответ лишь могу сказать, что если у Вас действительно такие Junior QA, которые сами разворачивают проекты, делают тестирование белого ящика, а еще и различные оценки, я Вам искренне завидую. Видимо поэтому меня однажды и не взяли в Softeq :)
Ну да ладно, суть не в этом: на моем собственном опыте, человек трижды умный в теории, не всегда трижды мастерит на практике. Меня лично интересует (как автоматизатора и бывшего ручника) код (if applicable), практическое тестирование, практическое применение тест дизайна и т.д. Лично для меня данный метод был наиболее приемлем при отборе кандидатов. Однако тем мир и красен, что у всех по-разному.
Рад, что данная методика для Вас работает, может быть, все-таки попробую как-нибудь поспрашивать теорию.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
2

Спасибо, хоть какой-то позитив! :) Данный метод собеседования не использовался в Softeq, а ток на моих предыдущих местах работы.

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

человек трижды умный в теории, не всегда трижды мастерит на практике.

Мой личный посыл - не разделяйте теорию и практику. ИМХО нужно стремиться быть трижды умным в теории и трижды мастером в практике, одно другому не мешает, а напротив, дополняет!

Успехов вам и сплошь бесхитросных багов! :)

0

почитайте выше комменты Evgenia Raneeva вы бы себе такого специалиста взяли в команду? :)

А вы бы взяли, если бы человек прошел ваше собеседование.

Или вы не только строитель, qa, девелопер, но еще и очень тонкий психолог?:)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
1

А вы бы взяли, если бы человек прошел ваше собеседование.

Это техническая часть собеседования, на ней оцениваются только профессиональные качества и косвенно личностные. Если бы она блестяще показала себя со всех сторон на собеседовании - добро пожаловать.

Или вы не только строитель, qa, девелопер, но еще и очень тонкий психолог?:)

По дипломам: радиомеханик 4го разряда, радиомонтер 5го разряда, электрик 5го разряда, сертифицирвоанный сварщик оптоволокна, инженер-программист, магистр технических наук, целюсь в аспирантуру :)

Без тонкой психологии ни куда. От этого зависит успех во всех сферах взаимодействия с людьми. Даже сейчас, в комментариях, я учусь: делаю выводы и расту над собой, принимаю критику, не впускаю в сердце прямые оскорбления, изыскиваю значимую информацию. Есть очень дельные замечания, отмечаю себе их на последующее изучение, хоть с QA и завязал :)

0

вы мне Антона Семенченко напоминаете. Сначала восхищалась, а теперь понимаю что от таких нужно держаться подальше. Вот и от вас постараюсь.))

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Буду рад, если вы мне дадите критику со стороны: 1) что не так с Антоном 2) что не так со мной. И почему вы считаете, что нужно держаться подальше от нас? Замечу, я вас к себе, вроде ничем и не притягивал, чтобы вы держались поближе :D (минус вам не мой, я вообще никогда никому минусов не ставлю - такой вот принцип у мя появился недавно)

0

1. меня не волнуют минусы:)

2. Антон - возможно, замечательный спец, человек с отличной харизмой, но вот после прочтения вот этой статьи осталось какое-то неприятное послевкусие - https://dev.by/lenta/epam-systems/anton-semenchenko-obraschayu-vnimanie-na-endokrinnuyu-sistemu-kandidata. Создалось впечатление, что человек не в состоянии абстрагироваться, и на мир смотрит очень субъективно, как и на кандидатов что он отбирает.

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

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

Я в том плане, что зная к примеру компанию в которой вы работаете, стремиться туда я не буду. Хорошо, что в айти есть возможность выбирать.

К слову, ваш комментарий про безработицу в теме qa на онлайнере к вам, как и к вашим подходам доверия не внушает.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
1

вы очень сильно на кандидатов как бы через себя смотрите.

Вы что-то перепутали :)

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

что сколько людей, столько и подходов.

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

0

Ваш поинт понятен. Всего хорошего.

"Все врут"(с) доктор Хаус

прикольно, но руководитель подразделения выбирает, из людей которых он даже не видел)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-1

Увидит.. когда примет решение. Мне кажется вы не осознание масштабности потока кандидатов. Здесь, как в больнице, некогда плакать, оперировать нужно следующего.

1

Поддерживаю ваш подход. !!

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Приятно, что вы увидели рациональное зерно! :)

1

в гугле Software engineer in test
кроме того Гугл платит за баги всем желающим)

0

любопытсва ради: Чем, по Вашему мнению, отличается SDET от QA?

0

Изич)
https://en.wikipedia.org/wiki/Software_Design_Engineer_in_Test
The key difference that "SQA encompasses the entire software development"
https://en.wikipedia.org/wiki/Software_quality_assurance

Если простым языком отличие примерно как между мастером-наладчиком станка + он же на нём продукцию производит и ОТК.
ИМХО)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Если простым языком отличие примерно как между мастером-наладчиком станка + он же на нём продукцию производит и ОТК.

Если брать во внимание, вашу же ссылку на вики, цитата:
and they usually play a contributory or reviewer role in the creation of designs for production software

То ваше imho не согласуется с тем, что утверждает wiki.

Сколько MMR? :)

0

Написал простыми словами как понимаю сам.)
MMR - не встречал это термина, значит пока не нужно.
Кинете линк - почитаю для общего образования - раширять кругозор всегда полезно.

А Вы по сабжу ответьте на мой вопрос ниже, плиз.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
-1

По сабжу ответил. MMR - match making rank :D

"Изич)" обычно дотеры так говорят)

Кинете линк - почитаю для общего образования - раширять кругозор всегда полезно.

Чес гря, сам впервые встретил данный термин. По сути описания из вики - это программист, который тестит продукт методом белого ящика, выступает в роли контрибьютера (т.е. тоже пишет функционал или может его писать) и в роли ревьюевера (т.е. разработчики должны через него проводить свои исправления, а этот человек подтверждает, что код действительно соответствует решаемой задаче + code convention соблюдается). Фактически человек с комбинированными обязанностями тим лида и тестера, интересный гибрид. В наших проектах оч активно используется код ревью и реально эта QA мера серьезно снижает процент багов, доходящих до самих тестировщиков.

1

Спасибо)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Обращайся, я всегда открыт к передаче знаний :)

1

Ну вот. Это не QA и не разработчик. Попробуйте нанимать таких людей - весьма любоптные занятие.
Разработчику достаточно тяжело быть SDET'ом потому что нужно знать много паттернов тест-дизайна (хотя бы в теории) и быть very passionate to code style and consistency.
QA тяжело, потому что требует нетривиальных знаний в разработке.

Но будущее именно за таким способом QA ИМХО.

PS MMR ~3700

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Фактически человек с комбинированными обязанностями тим лида и тестера, интересный гибрид.

Я ж угадал! :D

Но будущее именно за таким способом QA ИМХО.

+1 убедился на собственном опыте.

2

" Каждый руководитель ведёт метрики эффективности, так вот эти ребята находили от 80 до 120 дефектов в месяц".
интерестный, но несколько настораживающий факт, при конечно неизвестных вводных:
- new feature testing = низкое качество разработки/коммуникации/BA ?
- regression = что делали до этого? почему баги не были найдены раньше ?
- на проекте нету QA только тестировщики?

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
1

Ничего не понятно, спросите, пожалуйста, другими словами если вам нужен ответ на ваш вопрос.

0

Почему так много багов? простыми словами.
Анализ причин?

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
2

Собсна, сам проект для понимания масштаба + к нему еще с десяток проектов чуть поменьше. Команда - четыре QA.

Все проекты нам достались в legacy состоянии, т.е. до нас уже было много написано, что-то оттестировано, что-то нет. Много проектов, много функционала = много багов.

Ключевые источники нестабильности:
- legacy код
- внешние источники данных (база Литрес по продуктам), своя база продуктов (конечно, в разных и меняющихся форматах)
- внешние платежные системы и их доступность, собственная платежная система и ее доступность
- функционал чтения книг из zip архивов
- контроль состояния чтения, аккаунта и его продуктов, его синхронизация online/offline
- сильная фрагментация Android платформы (собственных девайсов Prestigio выпускало 35 моделей в год)
- необходимость поддержки двух режимов работы приложения: вендорного и обычного (из гугл плей)
- различные версии open gl и необходимость их поддержки
- обязательная локализация на 25 языков с поддержкой RTL
- поддержка большого числа форматов книг

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

Решение:
+ хорошее покрытие тест кейсами и чек листами проблемных случаев
+ автоматизация тестов стабильности чтения и расхода батареи
+ очень тесное взаимодействие с командой разработки и проверка их фиксов on demand/real time (разработчик не собирает новый билд, а просто дает тестеру проверить текущий фикс на его дебаг билде, после того, когда все такие фиксы подтверждены тестером - сборка RC и проверка уже по тест кейсам на побочные эффекты и регрессионные проблемы)
+ эффект пестицида нивелировали постоянными сессиями ad hoc тестирования коллективного и за счет постоянного использования нашего продукта в повседневной жизни в роли обычного пользователя
+ распространили продукт среди друзей, знакомых и родственников - постоянно собирали с них обратную связь, как с фокус группы

0

y.paulavets, неутомим :)
А руководство кампании знает что это все в рабочее время происходит ?))

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

о_О причем здесь руководство компании? В Softeq отличный гибкий подход к рабочему времени, никто не парится по такой ерунде.

0

+ распространили продукт среди друзей, знакомых и родственников - постоянно собирали с них обратную связь, как с фокус группы
>> конечно какой NDA мы про него не слышали)

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Какой может быть NDA у публично доступного продукта на Google Play?

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже