Feeds:
Posts
Comments

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

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

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

Ну, взялись.

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

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

(more…)

Advertisements

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’. В стандартной комплектации фильтров сделать поиск по “компонентам” невозможно.

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

.
(more…)

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’. Вопрос встал такой – нафига нам эти статусы? Мы ими не пользуемся. Надо бы их прибить.

Понеслось!

(more…)

Read Full Post »

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

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

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

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

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

(more…)

Read Full Post »

Older Posts »

%d bloggers like this: