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

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

Соавтор, дополнятор и одобрятор этой записи: Ярослав Ясинский (Киев).

~ Давайте писать тест-кейсы!
~ Давайте!
~ О! А давайте писать хорошие тест-кейсы!
~ Ну да! Так давайте, давайте же их нам!
~ Ну, так — беритесь!

Ну, взялись.

Ну, и застопорились.

Ну как, как написать кейс, в котором будут учтены состояния юзера, который что-то творит на нашем сайте в пьяном и усталом залогиненном виде и в незалогиненном виде?

(далее…)

Read Full Post »

Пассаж Джеймса Бородатого Баха про определенных создателей тест-менеджментских приложений (перевод вольный, отслеживаем оригинал):

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

Как я вычисляю таких перцев? Ну, однажды я спросил сам себя, глядя на подобное приложение: «Этим ребятам хоть раз в жизни приходилось тестировать? Нужен ли был им инструмент, который в этом помог? Бьюсь об заклад, что этот инструмент утроит количество времени и энергии, которое мне придется затратить при тестировании, и я буду ненавидеть каждую минуту работы с ним«, после чего я начал подозревать, что эти парни — не такие уж любители тестирования.

Я это испытал, когда работал с Rational Test Manager в 2001 году. Мне довелось познакомиться с дизайнером этого инструмента: малыш, который едва выполз из Массачусетского технологического института безо всякого опыта в тестировании или в управлении тестированием, сообщил мне, что я, ветеран управления тестированием из Кремниевой долины, не достаточно  квалифицирован, чтобы критиковать его технологические решения».

«Этот поезд в огне,
и нам не на что больше жать...» ©

Read Full Post »

Из существующих опен-соурс тест-трекеров самым адекватным я считаю RTH — ‘Requirements and Testing Hub‘.

К сожалению, проект застыл в нынешнем состоянии с прошлого года, и совершенно не лишен следующих недостатков:

  1. Невозможно централизовано скопировать все тесты из одного проекта в другой. Однако есть возможность скопировать каждый тест по-отдельности…
  2. При экспорте в другой проект содержимое тест-кейса сохраняется полностью, а вот некоторые атрибуты иногда исчезают. Явный баг.
  3. На странице Test Library можно экспортировать в Excel только список отображаемых тестов. Ожидал экспорт их содержимого.
  4. Невозможно экспортировать в Excel все тесты с их содержимым. Можно экспортировать тесты по-одному.
  5. После орфографического редактирования Test Area в настройках проекта изменения не отображаются автоматически в свойствах тест-кейсов. При открытии свойств тест-кейса в поле Test Area отображается первая же по алфавиту область.
  6. Невозможно экспортировать список Requirement Area Covered в раздел  Test Area, а ведь это родственные большей частью области. Его же следовало бы экспортировать в раздел Defect Category.
  7. Если назвать Test Area в таком стиле: ‘Product > Small pages’, то фильтрация по такому значению на странице Test Library становится невозможной. Если же назвать Test Area в стиле: ‘Product — Small pages’, то фильтрация работает адекватно.
  8. Архитектура RTH вызывает ряд вопросов при попытке поднять RTH на https и обращаться к нему посредством сверки сертификата безопасности. Все доступно, а вот содержимое полей для записи тест-кейсов недоступно — оно отображается строго по http. Проблема в том, что поля для ввода представляют собой <iframe width=»100%» height=»149″ frameborder=»no» src=»fckblank.html» name=»eEditorArea» id=»eEditorArea»>
  9. На странице добавления теста отображается три фрейма, из которых два — required. Если ввел что нужно в первое поле, но забыл тронуть второе, то при сохранении: 1) выводится сообщение о том, что пропущено обязательное поле, 2) содержимое первого поля исчезает… ко всем ебеням просто исчезает.
  10. В окне редактирования шагов тест-кейса переключение между текстовыми фреймами клавишей Tab в направлении «вперед» работает. Переключение в обратное направление (shift+Tab) не работает.
  11. Невозможно изменять размеры фреймов, в которых нужно вписывать текст. В какой-то момент поля ощущаются как «невысокие, блин».
  12. RTH не умеет работать с вкладками бразуера. Например, во вкладке №1 открываю тест-кейс №1. Во вкладке №2 открываю тест-кейс №2.  Возвращаюсь во вкладку №1 и открываю свойства тест-кейса на редактирование. В полях открытой формы (surprise!) отображаются все данные кейса №2. Решение: перед тем, как открыть кейс №1 на редактирование, следует обновить страницу. Но ведь так нельзя…
  13. В каждом сохраненном требовании можно вести дискуссию относительно его содержимого — линк ‘Discussions’. Но если я не знаю, что у требования есть комментарий, то я его не увижу — ничего на странице комментария не подсказывает, что кто-то написал к нему вопрос.
  14. Traceability Matrix отображает тест, привязанный к требованию даже в том случае, если я явно удаляю тест-кейс. В матрице он все равно отображается, и даже полностью доступен, словно никто его не удалял. Его даже можно удалить повторно…
  15. Есть сложности с кодировкой. Русский язык отображается повсюду адекватно (utf-8), но при экспорте тест-кейса в Excel вместо русских букв видим кракозябры.
  16. Удаляю пользователя и завожу нового с тем же емайлом — система ругается и запрещает, мол, такой юзер уже есть. Решение: сперва следует юзеру емайл почикать, затем можно удалять и нового заводить. Хотя можно прямо в базе грохнуть мерзавца.
  17. Из профиля пользователя не удаляется строка проекта, который был удален, и в списке проектов больше нигде не присутствует. Можно даже проставить галочки настроек для удаленного проекта… Исчезает только после внятно проставленной галочки ‘Remove’ (находится в крайней правой стороне).
  18. На странице связки требований с тест-кейсами не работает фильтрация таблицы существующих кейсов по ID.
  19. Невозможно добавлять категории, тест-ареа и прочие сущности на лету, в процессе редактирования тест-кейсов или требований.
  20. Раздражает стиль линка на отдельный тест-кейс: http://rth-server//test_detail_page.php?test_id=140&project_id=4. Если убрать параметр проекта, то получаем «ERROR: The project you wanted to view, does not exist«.
  21. Раздражает стиль линка на отдельное требование: http://rth-server//requirement_detail_page.php?req_id=00052&req_version_id=62. Если убрать параметр req_version, то требование отображается нормально, самая последняя версия.
  22. Невозможно линковать тест-кейсы между собой, примерно как связку «требование + тест-кейс».
  23. При создании тест-кейса можно назначить тест-кейс на определённого тестировщика (поле ‘Assigned To’). Но на странице списка тестов по этому полю фильтровать невозможно, доступно только поле ‘Tester’.
  24. Невозможно использовать содержимое тест-кейса (или требования) как шаблон для создания другого тест-кейса (или требования).
  25. Бля. Поля типа «Test Set Name» ограничены по вместимости 20-ью символами (в БД та же херня).  Пример: <input type=»text» maxlength=»20″ name=»testset_name_required» size=»30″ value=»»>. Лечится руками в коде. Плюс в БД надо увеличить лимит символов. Список этих файлов:
    • build_edit_page.php
    • build_page.php
    • news_edit_page.php
    • release_page.php
    • release_edit_page.php
  26. На странице добавления тест-кейсов в тест-сет (testset_edit_page.php) не отображаются статусы тест-кейсов. Запросто можно добавить в тест-сет тест-кейс, который еще не переведен в статус ‘Completed’…
  27. В разделе «Test Results» на странице списка тест-сетов, которые назначены для определенного билда, список невозможно сортировать по заголовкам колонок. И экспортировать в Excel невозможно. И вообще тест-сеты в Excel не экспортируются.
  28. Непонятка с «Estimated Time to Complete» (при создании каждого тест-кейса есть поле «Duration» с минутами; в итоге сумма значений этих полей показывает примерное время, которое понадобится для прохождения определенного тест-сета). Это значение доступно только на странице тест-сета, который я намерен прогнать, и только в отдельном окне после клика по отдельному линку. Эту информацию следовало бы выносить еще на экран составления тест-сетов, и постоянно светить во всех таблицах.
  29. Можно добавить в настройках проекта новую TestArea. Данные летят в таблицу ‘testarea’, и сразу же доступны в форме создания новых тест-кейсов. Редактирую имя добавленной TestArea, но на состоянии тест-кейсов это изменение не распространяется. Теперь чтобы отредактировать название TestArea (да так, чтобы изменения автоматически распространились на уже существующие тест-кейсы), следует использовать SQL REPLACE в таблице ‘testsuite’ для колонки ‘AreaTested’. Ну и нафига нам тогда дадена таблица ‘testarea’?
  30. Явный баг: на странице Test library > открыть нужный тест-кейс > Supporting docs можно приложить к тест-кейсу файл. Там же есть поле File type, которое может помочь когда-нибудь разобраться с типом прилагаемых файлов. Содержимое поля File type настраивается (СУРПРИЗЪ для логики!) в Manage > выбрать нужный проект > Tests > Test type > Add new test type… В итоге файл отображается с FileType не по слову, который был выбран раздраженным венцом природы, а как иконка.
  31. Список недостатков дополняется по ходу раздражения.
Плюсы из разряда неочевидных:
  1. Ввиду сравнимой с Mantis простоты представления страниц, автоматизировать работу с RTH через Selenium IDE очень легко.
  2. Баг-трекер по RTH существует

Read Full Post »

Снова работаю с Jira (и унылым Zephyr).

Фильтры в ней мощные, но тоже не без греха.

Например, в нашем проекте несколько разделов, все они указываются при заведении новых задачах в перечне ‘Components’. В стандартной комплектации фильтров сделать поиск по «компонентам» невозможно.

А в нестандартной — можно.

.
(далее…)

Read Full Post »

Из интервью с Максимом Крамаренко — руководителем команды разработки TrackStudio, иерархической системы управления задачами

Маленькая команда и большой продукт: каким образом осуществляется тестирование TrackStudio и его саппорт?

У нас нет своей команды тестировщиков. Перед выпуском бета-версии мы инсталлируем новую версию системы на свой сервер и активно используем несколько недель. Параллельно разработчики занимаются тестированием с применением средств покрытия кода (code coverage), мы устраиваем соревнования «кто быстрее достигнет заданного уровня покрытия».

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

Особенность нашей ситуации в том, что

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

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

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

Саппортом и общением с клиентами обычно занимаюсь я сам, это позволяет лучше понимать запросы пользователей. Технически у нас ничего интересного нет – форум, e-mail, телефон. Прямой доступ в нашу TrackStudio мы пользователям не даем по идейным соображениям.

ТDD и автотесты?

Нет, автоматические тесты не применяем. Пробовали, но ничего хорошего из этого не вышло. Причины такие:

Разные части TrackStudio очень сильно сильно взаимосвязаны. Например, работа правил оповещения по e-mail сильно зависит от работы фильтров, настроек правил доступа, пользовательских скриптов. Ситуации когда что-то перестает работать «совсем» у нас возникают редко (т.к. даже обычное создание задачи затрагивает работу значительной части кода TrackStudio), а вот проблемы только на какой-то конкретной конфигурации пользователя бывают часто. Моделировать такие ситуации в тестах довольно трудно, а поддерживать эти тесты в актуальном состоянии – еще труднее.

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

Read Full Post »

Во-первых, под словом «Workflow» в Mantis подразумевается «Переходы состояний процесса». Но мне проще сказать «воркфлоу», нежели «переходы состояний».

Во-вторых, у нас Mantis говорит на английском языке, поэтому все дальнейшие указания я буду делать по английской версии.

Хотя там есть даже язык «волапюк»…

В третьих, нужно покопаться в коде приложения.

Залогинившись под административным аккаунтом, переходим на страницу «manage > Manage Configuration > Workflow Transitions»

По-русски: «управление > Управление конфигурацией > Переходы состояний процесса«.

По-простому: http://вашMantis/manage_config_workflow_page.php

По-умолчанию в Mantis присутствуют следующие статусы:

  • new
  • feedback
  • acknowledged
  • confirmed
  • assigned
  • resolved
  • closed

Есть еще связанный статус ‘reopened’, но рассматривать его пока незачем.

Логика связей между статусами очень грамотная и продуманная, но подходит не всем и не всегда.

В частности, в нашем офисе разработчикам понадобился новый статус задач ‘Active’, для того, чтобы быстро узнавать, кто и чем у них занят прямо сейчас.

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

Но добавить новый статус и дальновиднее, и интереснее 🙂

По причинам удобства, хотелось, чтобы статус ‘active’ можно было устанавливать наиболее быстро и просто, без постоянного развертывания выпадающего списка статусов…

Блин, это сделать даже быстрее, чем разъяснить.

Также встал вопрос про статусы ‘acknowledged’ и ‘confirmed’. Вопрос встал такой — нафига нам эти статусы? Мы ими не пользуемся. Надо бы их прибить.

Понеслось!

(далее…)

Read Full Post »

Обращение к нации

Дорогой разработчик,

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

Для этого используются системы управления дефектами вроде «Mantis».

  • Да, можно называть дефекты багами. Главное не в названии, главное в том, что их надо чинить.

(далее…)

Read Full Post »

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

Дали нам пощупать 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 »

Значение…

Цитата:

Если стоит флажок «Сохранять параметр», то при введении значения в ячейку, настроенную на параметр, где стоит этот флажок, значение этой ячейки во время сохранения значений заменит собой значение этого параметра на число, указанное в настройках этого параметра на эту ячейку. Если же флажок не стоит, то замена значения во время сохранения значений параметров происходить не будет.

Было время, когда я вчитывался в эту цитату минут по пять в день и казалось что вот-вот пойму, что же, черт возьми, все это значит…

http://it4business.ru

Read Full Post »

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