Сообщений в теме: 163

[Clauster]

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

Сниффер? Вы это серъезно, что-ли?

[Bars Master]

вот именно для такого вопроса я написал:

Приведу абстрактный пример

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

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

[dlg99]

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

Сниффер? Вы это серъезно, что-ли?

насчет использования сниффера на интервью - многие могут просто сконцентрироваться на других вещах.
IMO вменяемый человек все осознает после 15 минутного рассказа что-где-почему проверять. Т.е. проверять нужно на "вменяемость", а не на выдрессерованность в использовании конкретных утилит. В разных компаниях проблемы разные, тулсет разный. Где-то сниффер - необходимость, а где-то у веб приложения нагрузка > 100 юзеров и проблемы с тестированием бизнес-логики или секюрити.

Но при нормальном тестировании - Фиддлер обычная вещь. Посмотреть какие опции кеширование стоят у js/img/html/..., нет ли "левых" ajax/img/... запросов выдающих 404 - все это создаст ненужные проблемы под большой нагрузкой.

[Yuliana]

Clauster,

А сколько ещё более важного вы не узнаете.

Это смотря какого уровня специалиста я тестирую. Если мне нужен qualified, то наверняка таким образом я не узнаю умеет ли он составлять тестовую документацию. Я предлагаю программу для теста только как дополнительный пункт в собеседовании. И, знаю на опыте, что очень полезный.
Что касается UI-мартышек, то - поменьше негатива. Если вы тестер, то не забывайте, что когда-то вы таким были;)

[Yuliana]

...и почему рассматривается оценка исключительно "тыкабельности" соискателя

Вот

[Yuliana]

...и почему рассматривается оценка исключительно "тыкабельности" соискателя

Вот я тоже не поняла. Кстати, с тем же лист-боксером можно легко определить какой сложности баги умеет находить тестер и умеет ли он пользоваться документацией:)
Вообще странная у Clauster позиция. Что может быть важнее в тестировщике, чем умение находить баги разной сложности и доступно описывать шаги их воспроизведения.

[Clauster]

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

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

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

[Clauster]

Что касается UI-мартышек, то - поменьше негатива. Если вы тестер, то не забывайте, что когда-то вы таким были;)

Вы это точно знаете? :)
Ничего личного, но если кто-то обиделся - извините, видимо, есть на что. Вон, у Case даже тренинг есть - RoboMonkey или что-то типа того. Вячеслав, обижался кто-нибудь?

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

Если вы в Питере, приходите на интервью, обсудим. Действительно, мало кто задумывается, что может быть важнее в тестировщике, чем уметь искать баги и писать баг репорты? Разве не может, к примеру, аналитик искать баги, или даже ПМ, а я ещё знаю (прости, господи!) разработчиков которые не хуже других тестировщиков могут баги искать (и что интересно, ищут).

[Bars Master]

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

[dlg99]

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

умение их предотвращать.

[Yuliana]

Я, к сожалению, в Ереване:)

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

Поделитесь, плиз парой примеров таких задач. Без сарказма, и правда интересно.

- на выходе у вас список багов а не "подход к тестированию и знание области тестирования"

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

[Yuliana]

умение их предотвращать

Своевременное нахождение и есть предотвращение. А само предотвращение скорее работа аналитика и девелоперов.

[dlg99]

умение их предотвращать

Своевременное нахождение и есть предотвращение. А само предотвращение скорее работа аналитика и девелоперов.

а тест дизайн - работа тест дизайнера, а автоматизация - работа автоматизатора, и т.п.
Я Вас правильно понял?

[Yuliana]

а тест дизайн - работа тест дизайнера, а автоматизация - работа автоматизатора, и т.п.
Я Вас правильно понял?

Нет

Аналитик и девелопер еще и не гарантируют качество. Не надо передергивать:)

[dlg99]

Аналитик и девелопер еще и не гарантируют качество.

а тестировщик гарантирует?

[Yuliana]

а тестировщик гарантирует?

А вы не чувствуете, что это уже оффтопик. Гарантирует гарант качества, но в него вырастают как правило из тестировщика:))

[dlg99]

а тестировщик гарантирует?

Гарантирует гарант качества, но в него вырастают как правило из тестировщика:))

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

[Clauster]

Поделитесь, плиз парой примеров таких задач. Без сарказма, и правда интересно.

Да запросто. Берете любую из повседневных задач. Например, тестирование инсталляции - составить оптимальный список конфигураций на которых будем тестировать. Входные данные: ОС, редакция ОС, сервис пак, IIS и т.п. Что-то типа того.

[Case]

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

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

Yuliana, а вы попробуйте зайти с другой стороны, спросите Clauster-а, почему он так считает?

[Case]

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

умение их предотвращать.

+1.
Я бы добавил получение актуальной информации о статусе продукта по отношению к "готов к выпуску".