Собеседование

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

Хотите я вам дам задачку, ну так - размяться немного в форуме?

Вячеслав, поделитесь, пожалуйста.
Будет разгрузка мозгов после аврала

Пока вы не отвечаете мне как Клиенту или как Менеджеру Проекта в каком состоянии сейчас Продукт, мне вообще сиреневенько сколько усилий вы там куда-то потратили и насколько вы красиво описали баги. Неожиданно?

При чем тут клиент? Я говорю о приеме на работу тестера средней подготовки. Вы берете на работу тестера и он у вас сразу начинает общение с клиентом напрямую? Может вы еще и от новичков требуете умение составлять стратегию тестирования?:))
Спросите свой dev team – сиренево им, как тестер описывает баги или нет. И подумайте сколько времени потратится на выяснение содержания каждой плохо составленной баги.

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

Это тоже в мемориз. Ибо количество людей, считающих продуктом исключительно код, просто зашкаливает.

Пока вы не отвечаете мне как Клиенту или как Менеджеру Проекта в каком состоянии сейчас Продукт, мне вообще сиреневенько сколько усилий вы там куда-то потратили и насколько вы красиво описали баги. Неожиданно?

При чем тут клиент? Я говорю о приеме на работу тестера средней подготовки. Вы берете на работу тестера и он у вас сразу начинает общение с клиентом напрямую? Может вы еще и от новичков требуете умение составлять стратегию тестирования?:))
Спросите свой dev team – сиренево им, как тестер описывает баги или нет. И подумайте сколько времени потратится на выяснение содержания каждой плохо составленной баги.

Странные вопрос "при чём тут клиент" :) Вопрос про клиента я адресовал вам как менеджеру, а не вашему тестеру.

Остальные вопросы, напрямую касающиеся тему топика вы в приступе смеха решили игнорировать? :)

Я повторюсь:
Сколько в этом форуме ошибок? (Хелп дать?)
Если мы потестируем, найдём и исправим 10 ошибок (2 критикал, 3 важных и 5 тривиальненьких) - сколько ошибок осталось?
Меня как клиента волнует сколько вы нашли или сколько осталось?
Как выдумаете, меня как клиента вообще волнует как вы описываете баги?
Скажите мне, пожалуйста, после проведённого выше раунда тестирования - форум как Продукт можно выпускать в продакшн и продавать мне как клиенту?

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

Хотите я вам дам задачку, ну так - размяться немного в форуме?

Вячеслав, поделитесь, пожалуйста.
Будет разгрузка мозгов после аврала

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

Не всегда. Маерс, "Арт оф софтваре тестинг", "Тестирование - деятельность с целью обнаружения ошибок". Так оно и кочует от тестера к тестеру.

Не знаю как в русском переводе, в английском варианте написано:

Testing is the process of executing a program with the intent of finding errors.

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

Of course, you eventually want to use program testing to establish some degree of confidence that a program does what it is supposed to do and does not do what it is not supposed to do, but this purpose is best achieved by a diligent exploration for errors.

Даже в "средневековье" тестирование не имеет нахождение ошибок целью.

Наверное не дочитывают до второго абзаца :)

Сорри за оффтоп. Но не могу пройти мимо.

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

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

В идеале: бизнес-модель=функциональная модель=модель реализации=бизнес-модель

Цель тестировщика - выявить расхождения между функциональной моделью и моделью реализации (либо между бизнес-моделью и моделью реализации). Факт расхождения - баг. Все остальное вторично!

Сорри за оффтоп. Но не могу пройти мимо.

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

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

В идеале: бизнес-модель=функциональная модель=модель реализации=бизнес-модель

Цель тестировщика - выявить расхождения между функциональной моделью и моделью реализации (либо между бизнес-моделью и моделью реализации). Факт расхождения - баг. Все остальное вторично!

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

Согласен с Clauster.

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

Тебе от тестера умение проектировать и выполнить тест требуется в первую очередь или умение написать "Я кликнул, потом ввёл и получил ошибку, стэк трейс прилагается"? :)

Коллеги!

То что вы говорите - все правильно. Только это частности.

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

Все это вторично!

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

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

Уточняющий вопрос: зачем нам это нужно?

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

Уточняющий вопрос: зачем нам это нужно?

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

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

Коллеги!
Вы что, сговорились? Все задают мне наводящие и уточняющие вопросы. А сообщить что-нибудь по существу можете?

Мне кажется наше расхождение во мнениях не так уж и существенно. Наверное, дело в том, что мы работаем в компаниях разного типа. Я, например, в аутсорсинговой, а Clauster, мне кажется в продуктовой линейке (скажите потом, правильно я догадалась или нет?:) В таких компаниях тестеры выполняют больше аналитической работы. А подход как у 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

Уточняющий вопрос: зачем нам это нужно?

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

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

Коллеги!
Вы что, сговорились? Все задают мне наводящие и уточняющие вопросы. А сообщить что-нибудь по существу можете?

Сергей,

попробую по существу:

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

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

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

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

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

Нет, расхождение в мнениях с вами очень существенно. Вы так удачно слились в одном обсуждении и примазались к другому, что я даже и не знаю как вам ответить. Три месяца назад я перешел в компанию разрабатывающую свой собственный продукт. До этого работал в аутсорсинге который постепенно интегрировали + ещё был SCRUM.
По поводу разногласий с Сергеем, мне кажется их нет, если подумать, вся наша жизнь - поиск багов. Просто интересно мнение, когда человек умеет его обосновать.