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

VH>а если ручного тестировщика ?

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

Здравствуйте, VerHanna, Вы писали:

VH>Собственно сабж.
VH>Какие вопросы ,на ваш взгляд, уместно задавать для QA так, чтобы проверить его адекватность и знания для работы в этой области.
VH>Понятно, что если берём на автоматизацию, то можно по программированию кое-чего позадовать, а если ручного тестировщика ?

На CodeFest'10 был доклад "Прием на работу тестировщика без опыта". Имеются запись и слайды. Про вопросы там тоже есть.

Здравствуйте, VerHanna, Вы писали:

VH>Собственно сабж.
VH>Какие вопросы ,на ваш взгляд, уместно задавать для QA так, чтобы проверить его адекватность и знания для работы в этой области.
VH>Понятно, что если берём на автоматизацию, то можно по программированию кое-чего позадовать, а если ручного тестировщика ?

Самый уместный вопрос: "Умеешь ли выгибать спинку, мурлыкать?"

Здравствуйте, dilmah, Вы писали:

VH>>а если ручного тестировщика ?

D>взять того кто на собеседовании сломает стул, прольет чай, и уронит сеть?

Такие люди реально есть. Собственно, у меня и самого есть "талант тестировщика" —
типа найти ошибку которая может быть только в полнолуние у тех кто родился 12 числа,
если текущий год нацело делится на 13. Но до самых экстремальных случаев, о
которых я слышал, мне ещё далеко, по счастью. Ибо эта фигня и на железо
очень даже распространяется.

Здравствуйте, VerHanna, Вы писали:

VH>Собственно сабж.
VH>Какие вопросы ,на ваш взгляд, уместно задавать для QA так, чтобы проверить его адекватность и знания для работы в этой области.
VH>Понятно, что если берём на автоматизацию, то можно по программированию кое-чего позадовать, а если ручного тестировщика ?

Вопросов может быть много самых разных, конечно. Можно что-то из теории, например, в чем различия QA, QC и тестировщика. Учитывая, что у нас обычно QA называют некоторый микс этих должностей, то вынос мозга можно получить.

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

А если дело касается автоматизации, то лучше поспрашивать что-то по части процессов, а то народ-то примерно знает как "левой пяткой почесать правое ухо", но вот для чего оно надо и какая от этого польза — тут уже веселее

Здравствуйте, VerHanna, Вы писали:

VH>Собственно сабж.
VH>Какие вопросы ,на ваш взгляд, уместно задавать для QA так, чтобы проверить его адекватность и знания для работы в этой области.
VH>Понятно, что если берём на автоматизацию, то можно по программированию кое-чего позадовать, а если ручного тестировщика ?

Даешь шариковую ручку, что на столе и спрашиваешь, что будем тестировать.

Здравствуйте, Ytz, Вы писали:

Ytz>Даешь шариковую ручку, что на столе и спрашиваешь, что будем тестировать.

А в ответ: "Давай спеки, тогда поговорим "

Здравствуйте, bkat, Вы писали:

B>в ответ: "Давай спеки, тогда поговорим "

— А нет спек, твои действия.

Здравствуйте, Marduk, Вы писали:

M>Здравствуйте, VerHanna, Вы писали:

VH>>Собственно сабж.
VH>>Какие вопросы ,на ваш взгляд, уместно задавать для QA так, чтобы проверить его адекватность и знания для работы в этой области.
VH>>Понятно, что если берём на автоматизацию, то можно по программированию кое-чего позадовать, а если ручного тестировщика ?

M>Вопросов может быть много самых разных, конечно. Можно что-то из теории, например, в чем различия QA, QC и тестировщика. Учитывая, что у нас обычно QA называют некоторый микс этих должностей, то вынос мозга можно получить.

Бредовый вопрос


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

Это хороший поинт.


M>А если дело касается автоматизации, то лучше поспрашивать что-то по части процессов, а то народ-то примерно знает как "левой пяткой почесать правое ухо", но вот для чего оно надо и какая от этого польза — тут уже веселее

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

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, bkat, Вы писали:

B>>в ответ: "Давай спеки, тогда поговорим "

M>— А нет спек, твои действия.

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

Здравствуйте, VerHanna, Вы писали:

VH>Здравствуйте, Marduk, Вы писали:

M>>Здравствуйте, VerHanna, Вы писали:

VH>>>Собственно сабж.
VH>>>Какие вопросы ,на ваш взгляд, уместно задавать для QA так, чтобы проверить его адекватность и знания для работы в этой области.
VH>>>Понятно, что если берём на автоматизацию, то можно по программированию кое-чего позадовать, а если ручного тестировщика ?

M>>Вопросов может быть много самых разных, конечно. Можно что-то из теории, например, в чем различия QA, QC и тестировщика. Учитывая, что у нас обычно QA называют некоторый микс этих должностей, то вынос мозга можно получить.

VH>Бредовый вопрос

Кстати, очень даже нет. Если вы хотите проверить знания человека для работы в данной области, он как минимум должен понимать, что его область, собственно, охватывает. Сами понимаете, QA — это далеко не бездумное тыканье по кнопочкам.

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

VH>Это хороший поинт.


M>>А если дело касается автоматизации, то лучше поспрашивать что-то по части процессов, а то народ-то примерно знает как "левой пяткой почесать правое ухо", но вот для чего оно надо и какая от этого польза — тут уже веселее

VH>Если дело касается автоматизации, то уместно спросить как отсортировать массив, хотя для программиста этот вопрос совершенно неприемлем.

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

• Когда имеет смысл внедрять автоматизацию? Когда нет?
  
• Как определить эффективность автоматизации (произнесение магического слова ROI — это 60-80% правильного ответа)?
  
• Какие есть типы фреймворков? (перечислить и указать особенности)
  
• В какой последовательности имеет смысл внедрять автоматизацию (рассматриваем n-tier архитектуры тестируемых приложений)?

VH>Можно также выяснить кое-что из базового программирования и названия контролов.

С контролами — это да. А вот с базовым программированием есть маленькие нюансы. Как правило, под автоматизированным тестированием, как выделенной активностью, по умлочанию подразумевают автоматизированное тестирование на уровне ГУИ. Это несколько некорректно, но реальность такова. И как правило, эта задача осуществляется с использованием специфичесих инструментов, некоторые из которых используют свои языки программирования + свою идеологию построения тестов и описания оконных объектов. Только относительно недавно набрали популярность средства, использующие более-менее нормальные ЯП и то, они еще не прописались повсюду на полных основаниях. Соответственно, в этих случаях приходится проверять на знание основных концепций конкретного инструмента, который собираетесь использовать. А там вкусностей хватает

Здравствуйте, dilmah, Вы писали:

VH>>а если ручного тестировщика ?
D>взять того кто на собеседовании сломает стул, прольет чай, и уронит сеть?
кофейные автоматы хорошо тестить (если они есть в компании). никогда не забуду куриный бульон с двойным сахаром...

M>С контролами — это да. А вот с базовым программированием есть маленькие нюансы. Как правило, под автоматизированным тестированием, как выделенной активностью, по умлочанию подразумевают автоматизированное тестирование на уровне ГУИ. Это несколько некорректно, но реальность такова. И как правило, эта задача осуществляется с использованием специфичесих инструментов, некоторые из которых используют свои языки программирования + свою идеологию построения тестов и описания оконных объектов. Только относительно недавно набрали популярность средства, использующие более-менее нормальные ЯП и то, они еще не прописались повсюду на полных основаниях. Соответственно, в этих случаях приходится проверять на знание основных концепций конкретного инструмента, который собираетесь использовать. А там вкусностей хватает

Ничего сложнее VBA

Здравствуйте, VerHanna, Вы писали:



M>>С контролами — это да. А вот с базовым программированием есть маленькие нюансы. Как правило, под автоматизированным тестированием, как выделенной активностью, по умлочанию подразумевают автоматизированное тестирование на уровне ГУИ. Это несколько некорректно, но реальность такова. И как правило, эта задача осуществляется с использованием специфичесих инструментов, некоторые из которых используют свои языки программирования + свою идеологию построения тестов и описания оконных объектов. Только относительно недавно набрали популярность средства, использующие более-менее нормальные ЯП и то, они еще не прописались повсюду на полных основаниях. Соответственно, в этих случаях приходится проверять на знание основных концепций конкретного инструмента, который собираетесь использовать. А там вкусностей хватает

VH>Ничего сложнее VBA

Технически, конечно, не особо сложнее, но практически важнее намного. Что-то подобное в соседней теме проскочило здесь

Автор: Wissenschaftler
Дата: 19.02.11

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

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

Например, как построить структуру объявления окон таким образом, чтобы:
1) Хранить только нужный набор элементов управления, пропуская промежуточные по иерархии уровни
2) Минимизировать явное определение фактических элементов, чтобы в случае изменения свойств контрола правка делается только в одном месте
3) Должны поддерживаться как статические так и динамические определения объектов (например, у какого-то элемента его идентификатор может определяться налету)

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

Или другой актуальный вопрос: как сделать так, чтобы тест выполнял свои действия не быстрее тестируемого приложения. На практике отсутствие этого — источник где-то 60-80% ложных ошибок самих тестов.

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

Хотя и по основам используемого ЯП можно погонять. Например, если это тот же Java или Ruby, то конечно основы этих языков нужны. Но я бы больше концентрировался именно на типовых ситуациях, так как решения выглядят примерно одинаково для любого используемого ЯП.

M>Или другой актуальный вопрос: как сделать так, чтобы тест выполнял свои действия не быстрее тестируемого приложения. На практике отсутствие этого — источник где-то 60-80% ложных ошибок самих тестов.

Хороший вопрос.
И вот ответ (я права?)

While нет_ответа_от_контрола
wait(1) ' секунды хватит ,когда захватит контрол выйдет сам из while
Wend


M>То есть надо акцентировать внимание на знании не столько конкретного языка, сколько вот на таких вещах, с которыми надо постоянно бороться. Если кандидат таких вещей не знает, то у него в работе будет очень много проблем.

M>Хотя и по основам используемого ЯП можно погонять. Например, если это тот же Java или Ruby, то конечно основы этих языков нужны. Но я бы больше концентрировался именно на типовых ситуациях, так как решения выглядят примерно одинаково для любого используемого ЯП.

Здравствуйте, VerHanna, Вы писали:



M>>Или другой актуальный вопрос: как сделать так, чтобы тест выполнял свои действия не быстрее тестируемого приложения. На практике отсутствие этого — источник где-то 60-80% ложных ошибок самих тестов.

VH>Хороший вопрос.
VH>И вот ответ (я права?)

VH>While нет_ответа_от_контрола
VH> wait(1) ' секунды хватит ,когда захватит контрол выйдет сам из while
VH>Wend

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

While контрол_в_нужном_состоянии
wait(1) ' секунды хватит ,когда захватит контрол выйдет сам из while
Wend

что должно быть обобщением, но будет ли работать, если (дальше уже идет проверка на знание конкретной системы, как она себя ведет):

• элемент существует/отсутствует и надо дождаться некоторого значения свойства
  
• элемент enabled/disabled и надо дождаться некоторого значения свойства

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

AVL>кофейные автоматы хорошо тестить (если они есть в компании). никогда не забуду куриный бульон с двойным сахаром...
А как насчет кофе без стаканчика?

Здравствуйте, VerHanna, Вы писали:

VH>Если дело касается автоматизации, то уместно спросить как отсортировать массив, хотя для программиста этот вопрос совершенно неприемлем.

Почему для программиста такой вопрос неприемлем?

Здравствуйте, Гоги, Вы писали:

Г>Здравствуйте, VerHanna, Вы писали:

VH>>Если дело касается автоматизации, то уместно спросить как отсортировать массив, хотя для программиста этот вопрос совершенно неприемлем.

Г>Почему для программиста такой вопрос неприемлем?
Соседняя ветка вам в помощь.
Вкратце, можно заучить как дважды два.