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

[Oldman]

@ Rlabs, вот не пойму предыдущий Ваш пост написан серьезно или нет?

Э... а каким смайлом тут принято обозначать сарказм? Я в следующий раз поставлю, честное слово.

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

[rlabs]

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

Да куда уж серьезнее, если тестировщика приучили не считать ошибку ошибкой, если явно не указано что это ошибка. Это, и еще некоторое количество собеседований, способно вызвать ужас.

[LeshaL]

Да куда уж серьезнее, если тестировщика приучили не считать ошибку ошибкой, если явно не указано что это ошибка. Это, и еще некоторое количество собеседований, способно вызвать ужас.

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

[Yury]

Ну и где вы берете "Should be"? По моему только в спецификациях. Все остальные места для этого не подходят. И скорей всего в вас говорит желание переквалифицироваться в разработчики.

Это очень симптоматичное высказывание.
Оно хорошо иллюстрирует разницу между "factory school of testing", когда тестеры игнорируют все, что не указано в спецификации, и "exploratory school of testing", когда тестеры используют дополнительные источники информации ("Оракулы" в терминологии Cem Kaner).

[jseeker2007]

Не ожидал такого живого отклика :) А саркам от Rlabs это круто, правда не все поняли инструкцию.

И все же, попробую спасти хотя бы тех кого еще можно :D (© Max Frei)

Начнем с начала: картинка без предыстории, без документации, вообщем без нечего, И для проверки неофитов.

Вслед за LeshaL домыслим :). Рядом с setup.exe лежит README с подобным текстом: "Данный пакет есть часть ... пакета. НЕ запускайте установку в ручную. Только из ... пакета". и вот шаловливые ручки тестора-самоучки которые нашли в одном из подкаталогов setup.exe, щелкнули по нему. В результате он получил внутрисистемную ошибку и, не прочитав не слова из доки, полетел постить bug, может даже как "critical". :) Ладно, если девелопер сидит в том же зале, и после его наезда его пошлет матом, он прочитает readme и все успокоятся.

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

А теперь еще немного домыслим :). У них договор повременной и таких ляпов много - "тестер игнорирует доку". Некрасиво получиться. :(

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

В общем доки рулят. (© баш.орг)

специально для rlabs - как мы только выяснили чуть выше, это вполне может быть фича. Это на "тестировщика приучили не считать ошибку ошибкой, если явно не указано что это ошибка."

Ну и где вы берете "Should be"? По моему только в спецификациях. Все остальные места для этого не подходят. И скорей всего в вас говорит желание переквалифицироваться в разработчики.

Это очень симптоматичное высказывание.
Оно хорошо иллюстрирует разницу между "factory school of testing", когда тестеры игнорируют все, что не указано в спецификации, и "exploratory school of testing", когда тестеры используют дополнительные источники информации ("Оракулы" в терминологии Cem Kaner).

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

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

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

И откуда же такая уверенность что это дефект? Ведь доку вы читать не будете :(, это ниже вашего уровня, и ваша best practice самая бест.

Или все же попробуем выяснить, а что собственно подразумевает команда девелоперов? И в рамках их концепции?
А вот когда хорошо вьехал в их логику, что не возможно без хорошего ознакомления со спеками, тогда и можно писать "Should be".
Я кстати, об этом и писал выше: "конечно, я тоже иной раз превышаю свои полномочия, выступая аналитиком кода и оппонентом архитектора"

И если казаться примера с картинки, то такое сообщение вполне тянет на задуманное, для отладки. Вот перекореженное окно любая "best practice" натолкнет на мысль о дефекте :)

Кстати, не забываем, что мы обсуждаем возможность занесения бага в трекер по картинке БЕЗ предыстории и БЕЗ документации. И это при приеме на работу тестира.

Поэтому моя рекомендация - не годиться.

P.S. Никого не хочу обидеть, если где был резок - извините.

[LeshaL]

Привет! Давайте подискутируем.

И все же, попробую спасти хотя бы тех кого еще можно :D (© Max Frei)

О, как это благородно! Теперь я понимаю ваши мотивы :)

...Ладно, если девелопер сидит в том же зале, и после его наезда его пошлет матом, он прочитает readme и все успокоятся...

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

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

Это бывает. Зависит от планирования и приоритизации задач.

Или все же попробуем выяснить, а что собственно подразумевает команда девелоперов? И в рамках их концепции?
А вот когда хорошо вьехал в их логику, что не возможно без хорошего ознакомления со спеками, тогда и можно писать "Should be".
Я кстати, об этом и писал выше: "конечно, я тоже иной раз превышаю свои полномочия, выступая аналитиком кода и оппонентом архитектора"

Я предпочитаю работать с думающими людьми, а не с конечными автоматами. Мне не надо, чтобы человек сидел и проверял, что 2х2=5, если так написано в какой-то спеке. Надо, чтобы инженер по обеспечению качества, сначала убедился в правильности того, что написано в спеке (если есть сомнения), а потом проверил бы на соответствие.
И еще, мир не идеален - на все спецификаций не напишешь. Вот скажите, у вас где-нибудь есть требование №XYZ в котором написано, что в программе не должно быть spelling ошибок? Думаю, что нету. Но если вы наткнетесь на опечатку где-нибудь - занесете ли вы ее в дефект-трэкер? Думаю да. А если это не просто опечатка, а неправильно сотавленое предложение английского языка? Неужели вы не опишите в баге, то как должно быть?

И откуда же такая уверенность что это дефект? Ведь доку вы читать не будете :(, это ниже вашего уровня, и ваша best practice самая бест.

А я и не говорил, что доки читать не буду :) Очень даже буду, т.к. обычно это один из наших самых приоритетных тестов - тестирование документации, поставляемой с продуктом.
Я писал, что использую секцию should be, практически всегда. Откуда берется там информация - я перечислил несколько источников, в том числе требования и спеки. Более того, в нашем дефект-трэкере, для этого есть специальное поле.
И учтите, что каждая из приведенных мной третей важна по своему. Кто-то все-равно будет это делать:
1. Если вы не найдете баг или закроете на него глаза, потому что а) мы тестируем сейчас другую фичу; б) в спеке не написано, что это неправильно; с) в прошлой версии так же работало итд. В этом случае баг найдет кто-то другой, и хорошо если это не пользователь.
2. Если вы не напишите в дефект, что вы ожидаете в результате фикса:
- вы усложняете верификацию бага
- вы заставляете девелопера, штудировать спеки\доки\гайдлайны и пр. - это потеря времени. Раз вы думаете, что это баг этому есть основания и ожидаемое правильное поведене, в момент написания дефекта. Не вижу причин, не написать эту информацию в трэкер.
3. Если вы не провели investigation - то это будет делать человек, кто фиксит баг - не факт, что он в своем "правильно" настроеном окружении сможет вообще это сделать.

И если казаться примера с картинки, то такое сообщение вполне тянет на задуманное, для отладки. Вот перекореженное окно любая "best practice" натолкнет на мысль о дефекте :)

Кстати, не забываем, что мы обсуждаем возможность занесения бага в трекер по картинке БЕЗ предыстории и БЕЗ документации. И это при приеме на работу тестира.

Если, задуманное для отладки сообщение попало в конечный продукт, то кое-кто не досмотрел, а кое-кто ошибся. Баг однозначно!
И мы обсуждаем проверку знаний кандидата на собеседовании. А не просим, человека пришедшего на собеседование, занести баг в наш дефект-трэкер :)

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

Я тут уже писал: задача собеседования проверить как умеет кандидат мыслить. В результате дискуссии я продвину свою мысль - для кандидата с малым опытом, обрисовать ситуацию должен интервьювер. А вот для опытного перца, условия задачи будут другими:
Дано: вот картинка, на ней баг(аксиома!). Все действия приводящие к этому вы в праве выбирать сами.
Надо: описать баг, так как будто вы его нашли и хотите занести в дефект трэкер.
Если он при такой постановке задачи "пошлет работодателя в дальнее путешествие" - то кандидат весьма странен. Можно на большинство вопросов на собеседовании так отреагировать: "Чего, мол, пристали - к вам же Я пришел, Работать хочу, а вы меня тут спрашиваете чего-то..."

Поэтому моя рекомендация - не годиться.

Очень даже годится :) Почему? Да потому что ситуация обтекаемая. Вы сами придумали интересный сценарий как такое может произойти (отладочное сообщение в релизе).

[rlabs]

Не ожидал такого живого отклика :) А саркам от Rlabs это круто, правда не все поняли инструкцию.

И все же, попробую спасти хотя бы тех кого еще можно :D (© Max Frei)

Начнем с начала: картинка без предыстории, без документации, вообщем без нечего, И для проверки неофитов.

Собственно говоря, тут можно было бы еще о чем-то спорить, но большого смысла в этом нет, поэтому ограничусь парой аксиом.

Аксиома номер 1: на приведенной выше картинке изображена проблема. В качестве чего она будет фигурировать в дальнейшем - как ошибка проектирования, ошибка документации или ошибка в ДНК - не суть важно. Важно то, что любая проблема может и должна быть описана.

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

Кстати, я так и не понял, как, по вашему, правильно: "тестор" или "тестир"?

[SALar]

Предыстория и документация:

Я готовил очередную рабочую станцию для тестирования нашего софта. Одно из требований - .Net 3.0.
Иду на http://www.microsoft...;displayLang=en
следую ИНСТРУКЦИИ на этой странице. Получаю вышеприведенное сообщение.

Контекст окружения:

Естественно, что фреймворк уже был установлен.

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

[natEn]

Посмотрела на скриншот. Подумала: "ерунда".
Почитала комментарии.
По ним чётко выделила людей, которых отсеила бы на собеседовании сразу же.

И впрямь суперский тестик, SALar, respect :)

[natEn]

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

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

[jseeker2007]

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

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

Ой спасибки, на добром слове :)))

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

natEn: сорри за прямоту, но к вам я не пойду, у вас какая-то странная философия, оторванная от жизни. И у меня сложилось впечатление, что у вас сложилось не правильное впечатление о том что у меня не правильное впечатление, что тестировщик - это автоматический скрипт с заданными входными параметрами. Да и к тому же вы путаете QA-тестера с QA-инженером :) Это вообще-то разные профессии, и у них разные задачи, а то что вы описали, тянет на среднее между QA-аналитиком, постановщиком задачи и немного инженера. Да, совсем забыл, и конечно немного архитектора проекта. И как пишут на баш.орг , за 10 руб./час

то rlabs: как раз у нас таких проблем нет, чему подтверждение - "благодарственное письмо".

то SALar: вот только после приведенных документов и предыстории и можно обсуждать эту картинку как пример для проверки, раньше ну никак не тянет.

то Maks590: а вам зачет, вы правильно ставите проблему.

PS ну и на последок, я занимаю только posix системами, и уже 15 лет :))), так что к вам natEn точно не подойду.

[jseeker2007]

Предыстория и документация:

Я готовил очередную рабочую станцию для тестирования нашего софта. Одно из требований - .Net 3.0.
Иду на http://www.microsoft...;displayLang=en
следую ИНСТРУКЦИИ на этой странице. Получаю вышеприведенное сообщение.

Контекст окружения:

Естественно, что фреймворк уже был установлен.

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

Оп ля! Как я был прав, нужна ИНСТРУКЦИЯ, ИНСТРУКЦИЯ и еще раз ИНСТРУКЦИЯ:

Примечание Для получения наилучших результатов следует устанавливать платформу на компьютере, на котором не установлены предварительные версии платформы .NET Framework 3.0. Если на компьютере установлена предварительная версия платформы, ее необходимо правильно удалить, чтобы удаление было выполнено полностью. Следуйте инструкциям по удалению, чтобы удалить компоненты предварительных сборок перед установкой этой сборки. Кроме того, обратитесь к разделу 2.8 этой страницы, чтобы получить дополнительные сведения о системе с предварительными версиями платформы Framework.

Вы уверены что ваша версия была не "предварительная"??? И далее:

2.7 Возможные проблемы при обновлении предварительной версии платформы .NET Framework 3.0 (ранее WinFX 3.0)

В этом разделе описаны проблемы, которые могут возникнуть, если ранее была установлена предварительная версия (CTP или Beta) платформы .NET Framework 3.0, и нужно удалить ее и обновить до версии RTM.

Запустите средство удаления
Средство удаления платформы .NET Framework 3.0 доступно по адресу http://www.microsoft...9F-E85AA9E66146. Эта программа решает многие проблемы с удалением и является лучшим средством для решения проблем с удалением и повторной установкой. Подробности использования программы приведены на странице загрузки.

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

Примечание. Такие проблемы с установкой возникают только если до установки версии RTM в системе была установлена предварительная версия платформы .NET Framework 3.0. Проблемы, вызывающие такие последствия, были решены в последних предварительных версиях платформы .NET Framework 3.0.

боюсь такой баг будет инвалид, если вы не докажете что их версии совпали, т.к. такое поведение, согласно ИНСТРУКЦИИ, ожидаемо.

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

PPS natEn: «Посмотрела на скриншот. Подумала: "ерунда".» - первое впечатлен было вполне разумным. :)

[SALar]

Приводя этот пример я не думал, что возникнут такие проблемы с идентификацией проблемы. Если они все же возникают, можно направить кандидата, добавив деталей. Идентификация идентификацией - но это не самый важный навык тестера. Я предлагал эту задачу для проверки навыка выражения результатов работы в письменном виде. Существует множество способов записи этого дефекта. Одни из них лучше, другие хуже. На мой взгляд, описание Oldman можно еще немного улучшить. Собственно именно это и может стать прекрасной темой для беседы с кандидатом.
* Какие еще атрибуты добавить?
* А можно ли что либо убрать?
* А для каких типов проектов данное описание будет оптимальным?
* Не оптимальным?
* Имеет ли смысл варьировать подробность описания в зависимости от уровня команды? Каким образом?

2 jseeker2007. Я полагаю, что в требованиях к продукту (не к программе, а именно к продукту) вполне может быть раздел "Требования к пользовательскому интерфейсу".
Может быть даже, там будет запись: "Удобством использования продукта жертвуем ради скорости разработки". Но такой подход характерен скорее для прототипа, а не для массового продукта. Для массового же продукта отход от стандарта проектирования пользовательского интерфейса, пусть всего лишь инсталлятора, - это дефект.

А то, что вы привели:

Примечание Для получения наилучших результатов следует устанавливать платформу на компьютере, на котором не установлены предварительные версии платформы .NET Framework 3.0. Если на компьютере установлена предварительная версия платформы, ее необходимо правильно удалить, чтобы удаление было выполнено полностью. Следуйте инструкциям по удалению, чтобы удалить компоненты предварительных сборок перед установкой этой сборки. Кроме того, обратитесь к разделу 2.8 этой страницы, чтобы получить дополнительные сведения о системе с предварительными версиями платформы Framework.

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

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

[Oldman]

... На мой взгляд, описание Oldman можно еще немного улучшить. Собственно именно это и может стать прекрасной темой для беседы с кандидатом.
* Какие еще атрибуты добавить?
* А можно ли что либо убрать?
* А для каких типов проектов данное описание будет оптимальным?
* Не оптимальным?
* Имеет ли смысл варьировать подробность описания в зависимости от уровня команды? Каким образом?
...

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

Далее вопросы хорошие и нужные.

Но, что такое типы проектов? Есть какая-то общая классификация?

@jseeker2007
C моей точки зрения у Вас очень узкий взгляд на проблему

[jseeker2007]

2 jseeker2007. Я полагаю, что в требованиях к продукту (не к программе, а именно к продукту) вполне может быть раздел "Требования к пользовательскому интерфейсу".
Может быть даже, там будет запись: "Удобством использования продукта жертвуем ради скорости разработки". Но такой подход характерен скорее для прототипа, а не для массового продукта. Для массового же продукта отход от стандарта проектирования пользовательского интерфейса, пусть всего лишь инсталлятора, - это дефект.

А то, что вы привели:

Примечание Для получения наилучших результатов следует устанавливать платформу на компьютере, на котором не установлены предварительные версии платформы .NET Framework 3.0. Если на компьютере установлена предварительная версия платформы, ее необходимо правильно удалить, чтобы удаление было выполнено полностью. Следуйте инструкциям по удалению, чтобы удалить компоненты предварительных сборок перед установкой этой сборки. Кроме того, обратитесь к разделу 2.8 этой страницы, чтобы получить дополнительные сведения о системе с предварительными версиями платформы Framework.

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

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

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

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

Так что пример действительно очень НЕ удачный. Лучше поищите более разумный.

Oldman: C моей точки зрения у Вас очень узкий взгляд на проблему

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

[Maks590]

то Maks590: а вам зачет, вы правильно ставите проблему.

Большое спасибо за оценку моих способностей!!!

[Балабол]

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