Перейти к содержимому

jseeker2007

Регистрация: 21 дек 2007
Offline Активность: 01 авг 2013 20:39
-----

Мои сообщения

В теме: Пример неудачного сообщения об ошибке.

09 января 2008 - 14:03

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

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

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


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

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

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

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

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


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

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

В теме: Пример неудачного сообщения об ошибке.

06 января 2008 - 22:37

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

Я готовил очередную рабочую станцию для тестирования нашего софта. Одно из требований - .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: «Посмотрела на скриншот. Подумала: "ерунда".» - первое впечатлен было вполне разумным. :)

В теме: Пример неудачного сообщения об ошибке.

05 января 2008 - 23:56

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

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

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

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

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

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

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

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

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

В теме: Пример неудачного сообщения об ошибке.

23 декабря 2007 - 00:33

Не ожидал такого живого отклика :) А саркам от 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. Никого не хочу обидеть, если где был резок - извините.

В теме: Пример неудачного сообщения об ошибке.

21 декабря 2007 - 01:07

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

Я конечно же не гуру, но из данной картинки мне очевидно, что программа Х не должна писать, что компьютер неудовлетворяет требованиям для ее установки, только потому, что эта программа уже установлена. Обычно, нормальный инсталятор, при попытке второй раз установить прогу пишет, что-то типа "программа уже установлена, чего еще хотим? Может Remove? Или Repair?"

Увы, вы действительно не правы. Ваши домыслы "Обычно, нормальный инсталятор, при попытке второй раз установить прогу пишет, что-то типа "программа уже установлена, чего еще хотим? Может Remove? Или Repair?"" можете конечно занести как пожелание в трекер, НО то что на экране не есть issue !!! Если только не заявлено в описании иное поведение. QA-tester должен в первую очередь проверять соответствие поведения программы со спецификацией. А так вы очень рискуете нарваться на Invalid.

Ну и "Написать как должно быть - последняя 1/3." - это уже из разряда хохмы - кого вы на работу берете архитектора или тестера? :)
Нет, конечно, я тоже иной раз превышаю свои полномочия, выступая аналитиком кода и оппонентом архитектора, но это явно не входит в обязанности даже QA-инженера.

Я чаще всего так и пишу баги:
Now: blah-blah
Should be: blah-blah

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