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

[Bars Master]

написал, стер, были некоторые уточнения по фразам, которые потом сам понял :)

[LeshaL]

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

Ой, а я то тут причем? Вы наверное не мне писали. т.к. я только Сергею ответил, надеюсь, "по существу". Про собеседование и про тонкости определения качества я не писал тут.

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

[barancev]

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

Под школами имелись в виду не учебные заведения.
Сначала читать тут: http://www.io.com/~w...our_schools.pdf
Потом тут (подборка ссылок): http://testconsultan...s-evolving.html

[Clauster]

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

Я так понял это камень в мой огород. Сначала это был сарказм у Юлианы, теперь это подтасовывается как факт. Мой изначальный посыл в том, что давать на собеседовании тестовое задание протестировать программу (в данном случае ListBoxer, как я понял) - это пустая трата времени и усилий и в общем-то мало чего может нам сказать о кандидате. Другое дело, как это практикуется в Quest-e, когда выполненное тестовое задание является залогом приглашения на собеседование (отсечение левых кандидатов).
Обсуждение Майерса и целей тестирования пошло отдельной веткой в этом топике.

[Case]

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

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

[Case]

Мне кажется наше расхождение во мнениях не так уж и существенно.

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

Наверное, дело в том, что мы работаем в компаниях разного типа. Я, например, в аутсорсинговой, а Clauster, мне кажется в продуктовой линейке (скажите потом, правильно я догадалась или нет?:) В таких компаниях тестеры выполняют больше аналитической работы. А подход как у Green-а, возможно, свойственен тестерам в аутсорсинговых конторах.

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

[Green]

Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: http://www.questioni...of-testing.html

Первично то, что у нас есть задача и ее реализация. Нам нужно сравнить то что получилось с тем, что должно было получиться. Другими словами, сложить 2+2 и получить 4. Если мы складываем 2+2 и получаем 5, то это ошибка. В случае программы - дефект. Цель тестировщика - сравнить левую и правую части уравнения и сделать вывод о наличии или отсутствии ошибки. Если этот процесс не является поиском дефектов, то что это?

Теперь представим, что есть нечто сложнее, чем 2+2=4. Допустим по требованиям/спеке дано f(x)=y. По результатам эксперимента получается, что f(x)=2y. Где ошибка?
Если механически сравнить левую и правую сторону, то ошибка всегда получается в программе. А может ошибка в спецификации и правильно f(x)=2y, что и подтвержденено результатами эксперимента. Надо чуть чуть думать, просто сравнить не получается.
...

Вначале 2 LeshaL,
а кто сказал, что часть уравнения, с которой нужно сравнивать, - это программа?
А думать нужно всегда, даже когда просто гвоздь в стену заколачиваешь.


Теперь для двух Алексеев и всех остальных,
давайте рассмотрим типовое поведение тестировщика.

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

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

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


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

В итоге, все нужно выволить на заказчика и пусть он решает, что нужно исправлять, а что нет, дефект это или не дефект и т.п.

Правильно! Сто раз правильно!

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

Поэтому я утверждаю, что тестирование - первично. Результат тестирования - отчет (в моем понимании, отчет о несоответствии того что должно быть и что есть). А уже потом риск менеджмент, релиз менеджмент, тактическое и стратегическое управление и другие фенечки.

[Green]

Сергей, Юлиана, я работаю в аутсорсинговой компании, и я не разделяю вашу точку зрения :)

Да, про школы верно замечено. Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: http://www.questioni...of-testing.html

Кстати, эпиграфом к этой заметке служат вот такие слова Майерса, которого вы пытались привлечь как адвоката своей стороны:

"... one usually encounters a definition such as, 'Testing is the process of confirming that a program is correct. It is the demonstration that errors are not present.' The main trouble with this definition is that it is totally wrong; in fact, it almost defines the antonym of testing."

- Glenford Myers,
Software Reliability: Principles & Practices, 1976

Леша,
есть такой старый анекдот.

Принимают двоечника в комсомол и проверяют, как подготовился. Спрашивают:
- Знаешь, кто такой Ленин?
- Кто такой Хрущев?
- Кто такой Брежнев?
А двоечник абсолютно ничего не знает. Мычал он что-то, мычал, а потом спрашивает в ответ:
- А вы знаете Петьку хромого, Ваську косого и Фильку с пятой?
- Нет? Ну, так и нечего меня своими авторитетами пугать!

[barancev]

Кстати, эпиграфом к этой заметке служат вот такие слова Майерса, которого вы пытались привлечь как адвоката своей стороны:

Ну, так и нечего меня своими авторитетами пугать!

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

[LeshaL]

Я так понял это камень в мой огород. Сначала это был сарказм у Юлианы, теперь это подтасовывается как факт. Мой изначальный посыл в том, что давать на собеседовании тестовое задание протестировать программу (в данном случае ListBoxer, как я понял) - это пустая трата времени и усилий и в общем-то мало чего может нам сказать о кандидате. Другое дело, как это практикуется в Quest-e, когда выполненное тестовое задание является залогом приглашения на собеседование (отсечение левых кандидатов).
Обсуждение Майерса и целей тестирования пошло отдельной веткой в этом топике.

Нет, вы не так поняли, никаких камней ни в чей огород. Просто в данном топике обсуждается несколько разных вещей и ... вот меня втянули как-то в тему которую я и не обсуждал здесь.
Я лишь сказал свое мнение, внезависимости от вашего.
Еще раз но другими словами:
Филосовствование на тему что же такое тестирование и другие схожие темы - это хороший повод для разговора в курилке или за чашкой чая. Не для собеседования.
Узнать у кандидата, что же он понимает под тестированием на собеседовании - можно и даже нужно. Но не нужно ожидать какого-то правильного или неправильного ответа. Если у кандидата мнение отличается от мнения интервьювера - вовсе не означает, что кандидат плохой инженер.
И последнее, что я хотел сказать в предыдущем посте. Не всегда, человек обладающий теоретическими знаниями способен применять их на практике. Вот тут я предпочитаю на собеседовании иметь диалог с кандидатом, чтобы понять насколько его теоритечиские знания расходятся с практическими навыками. Бывают ситуации когда человека спросишь "вы знаете, что такое такой-то вид тестирования?". Он отвечает - нет, хотя оказывается, что на практике делал это 100 раз. Бывает и наоборот, спрашиваешь - все четко отвечает, вроде бы все понятно - спрашиваешь а вот когда невозможно применить такой вид тестирования - не может сказать. Спрашиваешь - а как бы вы организовали такое тестирование - не может придумать.

Речь о листбоксерах я вообще не веду.

Аккуратность составления баг-репортов проверяю на собеседовании всегда. После того как пришлось расстаться с одним инженером, который никак не мог понять, что описывать баги в духе "программа не работает" или "вижу exception в консоле" это не дело. Каждый такой баг-репорт отнимал время у нескольких инженеров (в том числе и у автора), чтобы разобраться что к чему.
И как показывает практика, некоторые люди совершенно не умеют формулировать в чем же собственно проблема, не говоря о том, чтобы пытаться докопаться до сути, чем же эта проблема вызвана. Этому, похоже, трудно научиться - и это легко проверить на собеседовании.

[LeshaL]

Вначале 2 LeshaL,
а кто сказал, что часть уравнения, с которой нужно сравнивать, - это программа?
А думать нужно всегда, даже когда просто гвоздь в стену заколачиваешь.
...
Поэтому я утверждаю, что тестирование - первично. Результат тестирования - отчет (в моем понимании, отчет о несоответствии того что должно быть и что есть). А уже потом риск менеджмент, релиз менеджмент, тактическое и стратегическое управление и другие фенечки.

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

Единственно, чем я бы тогда дополнил ваши слова - это то, что отчет о результатах эксперимента, это не всегда(хотя и в большинстве случаев) отчет о несоответствии того что должно быть и что есть.
Отчет может быть и том, что просто есть. У меня такие для последнего продукта каждый день приходили. Эксперимент без статуса Passed/Failed - а просто информация для коллег-девелоперов, применяемая ими в работе.
Отчет может быть сравнительный, например, при использовании сторонней библиотеки от компании XYZ у нас такие результаты, а при использовании аналогичной библиотеки от компании ZYX - такие. Дальше - делайте выводы - мое субъективное мнение прилагается к отчету.

[Yuliana]

А в аутсорсинге значит аналитики меньше? :)

Нет, в ауторсинге аналитикой занимается отдельный специалист, как правило:)

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

Мне кажется, в форуме есть как минимум два оппонента для которых существует только два мнения - свое и неправильное:) Кстати, при собеседовании я обязательно обращаю внимание на то как человек умеет вести дискуссию ;)

[Green]

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

Качество работы тестировщика напрямую зависит от двух навыков:
1. Навык формирования тестовой модели
2. Навык работы с моделью реализации

1. Навык формирования тестовой модели

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

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

2. Навык работы с моделью реализации

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

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

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

Ну, и отдельной строкой идут основы тестирования. Что такое дефект, как его оформлять, как писать тест кейс и т.п. Если вы берете специалиста, то, по меньшей мере, он должен владеть основами профессии.

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

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

[Clauster]

Поэтому я утверждаю, что тестирование - первично. Результат тестирования - отчет (в моем понимании, отчет о несоответствии того что должно быть и что есть). А уже потом риск менеджмент, релиз менеджмент, тактическое и стратегическое управление и другие фенечки.

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

[Green]

Мне кажется, в форуме есть как минимум два оппонента для которых существует только два мнения - свое и неправильное:)

Yuliana,
я Вас разочарую.
Это свойственно всему человечеству.

[Green]

Поэтому я утверждаю, что тестирование - первично. Результат тестирования - отчет (в моем понимании, отчет о несоответствии того что должно быть и что есть). А уже потом риск менеджмент, релиз менеджмент, тактическое и стратегическое управление и другие фенечки.

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

После моего поста они будут знать, что им следует отвечать на собеседовании.

[Yuliana]

Кстати, а как на счет личных качеств?:)

[Clauster]

Мне кажется, в форуме есть как минимум два оппонента для которых существует только два мнения - свое и неправильное:) Кстати, при собеседовании я обязательно обращаю внимание на то как человек умеет вести дискуссию ;)

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

[Clauster]

Поэтому я утверждаю, что тестирование - первично. Результат тестирования - отчет (в моем понимании, отчет о несоответствии того что должно быть и что есть). А уже потом риск менеджмент, релиз менеджмент, тактическое и стратегическое управление и другие фенечки.

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

После моего поста они будут знать, что им следует отвечать на собеседовании.

Мало ответить, надо ещё уметь отстоять свою точку зрения. [смайлик по вкусу]

[Yuliana]

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

По-моему вам следует это себе сказать:)) Что вы так нервничаете?:)