Feeds:
Записи
Комментарии

Archive for the ‘Трекеры’ Category

Я весьма нервно отношусь к тест-трекерам по достаточно внятным причинам, которые могу излагать отдельными письменами. К баг-трекерам отношусь спокойно. А к тест-трекерам — нет.

Дали нам пощупать Zephyr — The World’s Most Flexible Test Management System.

Вкратце про итоговое к ней отношение:

Bloody blast, this is up my arse!

Подробности есть.

Система очень платная (по типу ежемесячного абонемента на определенное количество аккаунтов), но, как бы, очень интегрируется с Jira, а ведь Jira — это наше всё…

Ожидания

Что Test Director и иже с ним и уйдут в небытие по причине неповоротливости, и что пришла новая эра тест-трекеров…

Ведь вон как шикарно выглядит страница логирования в Zephyr:

Загрузка портала богов

Загрузка портала богов, ей-богу...

В целом Zephyr — работает. Но местами он очень и очень недоделан…

(далее…)

Реклама

Read Full Post »

Для самомнения вердикт «Can’t reproduce» не так страшен как «Not a bug«, но — тоже неприятно.

Официальщина:

«Не могу воспроизвести» означает только то, что работник, ответственный за починку дефекта, не смог его воспроизвести на билде, указанном в описании дефекта.

Почему не смог?

  1. Из-за разницы в конфигурации компьютеров

    В веб-отрасли это бывает реже, чем в десктопных приложениях. Но бывает. Но редко.

  2. В описании бага отсутствуют какие-то шаги или нюансы

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

  3. Дефект уже починен в более новом билде, а девелопер как раз и проверяет это дело на этот самом «обновленном»

    Это самое противное и требующее рассмотрения.

Третья причина является проблемой из-за того, что входит в противоречие с официальным толкованием статуса «Не могу воспроизвести»:

Дефект проверяется на билде, указанном в описании дефекта.

Дефект, зарегистрированный в версии 1.9, отложен и принят к
рассмотрению в версии 1.12. Высока вероятность того, что в 1.12 он уже
будет как-то починен? Если рассматривать ситуацию абстрактно, то
вероятность весьма, весьма, гм, вероятна.

А если так, то является ли преступлением против системы треканья багов проверить исторический баг на новом билде, и заявить, что «не могу воспроизвести»?

Не является.

Но проверять дефект на обновленном билде, как правило — на текущем — это потенциальная брешь и проблема. Предположим, не воспроизводится. А ну как он, зараза, снова всплывет? Мы точно знаем, почему этот гадёныш не воспроизводится?

Единственно верное решение:

Поставить билд 1.9, воспроизвести, понять, отчего это произошло, и убедиться в том, что в билде 1.12 эта проблема несомненно решена. Убеждаться — в коде.

И если дефект при проверке уже считается недействительным, нужно ставить ему статус «Fixed» с указанием билда, в котором баг считается починенным.

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

Вышеизложенное написано в поисках уточнения: баг, который не воспроизводится на обновленном билде — он все-таки «Fixed», или «Can’t reproduce»?

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

Read Full Post »

Заголовок бага:

Link to ‘enabled’ is not disabled

Read Full Post »

Даже в Jira есть мелкие огрехи:

РедакАтируем профили

РедакАтируем профили

Read Full Post »

В любой wiki-системе.

Например, в TWiki или в MediaWiki (это реклама open-source разработок; мне реально нравится TWiki).

Если вы уже прошли стадию «работа в Excel», и она вас РЕАЛЬНО не
устраивает (проблемы с распределенностью и одновременной работой), если у вас вообще есть куча тест-кейсов, которые НАДО сделать доступными для распределенной сети коллег, то переходите на wiki, не стесняйтесь и не ограничивайтесь уже «готовыми» системами типа TestLink, RTH, TestDirector. Их вроде бы много, но это только видимость выбора, ей-богу.

Не надо искать «волшебную» систему, которая все умеет делать «как надо». Она уже найдена. Начните с организации документов в любой wiki, потом поговорим…

Любая wiki-система сделает вашу работу с тест-кейсами лёгкой и приятной просто потому, что вы сами организуете документы наилучшим для вас образом, согласно вашей логике и вашим нуждам. Беда всех систем хранения тест-кейсов в том, что они сделаны «для всех», и у каждой есть собственная логика «внутреннего порядка», к которой нужно не то чтобы привыкать, а вообще ее понимать, принимать, «подгонять» под свои нужды.

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

  • Парни, а какой хоткей отвечает в пятом Мегасоздателесайтов Про за вставку тэга noindex?
  • А он в крякнутой версии не вставляется…
  • Как, неужели не вставляется в пятом через хоткей?
  • Да, придется тебе ждать шестую версию…

Саму wiki надо поставить на сервер, который «под столом» стоит, чтобы все «летало».

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

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

Только не надо на wiki злоупотреблять «заливанием Excel-файлов»…

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

Отдельное мнение на эту тему от Ainars Galvans. Тождественно с моим, но другой опыт применения.

Read Full Post »

В багтрекере появился баг №666 — за моей подписью.

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

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

И приписали мне: » ISSUE 666 — НЕ БАГ!»

Issue — CLOSED. 😦

Надо было написать в трекере, что «Воспроизведение этого бага гарантированно отформатирует вам винт…»

Read Full Post »

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

Коллега Olga пишет правильное замечание:

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

За баги, не являющиеся багами никто тестировщика не похвалит (это мягко сказано).

Комментарий сопровожден весьма внятным обоснованием.

А окопный товарищ zmei верно указывает на то, что псевдобаги в трекере никому кроме «медсестер» пользы не принесут.

«Не баги» вообще не приносят пользы разработчикам 🙂 Это внутренняя кухня тестировщиков. К тому же, это зависит от каждого тестировщика в отдельности. Я их приемлю. Другие нет.

(далее…)

Read Full Post »

« Newer Posts - Older Posts »

%d такие блоггеры, как: