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

Archive for the ‘Инструменты’ Category

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

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

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

Я это испытал, когда работал с 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 »

Анадысь давеча случилось мне тестировать систему, которая отвечает за обработку товаров на складе.

Система не так, чтобы замороченная, но с нюансами.

Человеки на складе работают в нескольких областях — один обрабатывает все полученные заказы, второй берет эту сводку и ходит между стеллажами с ручным сканером (как на кассе в магазинах), третий собирает принесенные с полок товары в посылки.

(далее…)

Read Full Post »

26 февраля 2011 года в славном городе Киеве тренинг-центр XP Injection возьмет да и проведёт Selenium Camp — первую в Европе конференцию, целиком посвященную рулезной штуковине для тестирования web-приложений, которая называется Selenium.

Собираемся все те, кто так или иначе использует Selenium в своей работе.

Небеса подсказывают. что Selenium лучше всего использовать так, а не иначе 🙂

Selenium Camp — это вам не то! Это вам вот что:

  • отличная стартовая точка для тех, кто только задумывается о применении Selenium;
  • отличная стартовая запятая для профессионалов, использующих его долгое время;
  • множество троеточий и докладов, разнообразных мастер-классов и практических отчетов о применении Selenium для тестирования приложений, написанных на различных языках программирования (Java, .NET, PHP, Ruby, Python и т.д.).

Также ожидаются доклады, посвященные интеграции Selenium с другими инструментами для тестирования (Fitnesse, Cucumber, Tellurium и т.д.) и написанию собственных доменных языков.

Алексей Баранцев будет делать мастер-класс на тему «Selenium без тормозов»

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

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

(далее…)

Read Full Post »

Текст слегка дополнен всем тем, о чем я хотел сказать,

но по причине скудности эфирного времени не успел.

Вместо картинок слайдов использую заголовки.

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

Для прояснения антуража уточняю, что я — тестировщик из Кишинева.

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

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

Например, я сейчас работаю над интернет-магазином, которым пользуются только жители США — и оплата и доставка заточены именно под их регион.

У нас нет огромных компаний, как это бывает в Москве или Киеве, в которых можно прожить всю свою карьерную и биологическую жизнь.

Обычный кишиневский айтишник большую часть жизни:

  1. мечтает стать программистом,
  2. проводит время в маленьких компаниях,
  3. поддерживает зарубежные долгосрочные проекты,
  4. работает в окружении малочисленного коллектива, большую часть которого составляют вечно приходящие и уходящие «студенты».

Затем обычный кишиневский айтишник как следует учит Java, английский вперемешку с французским и навсегда уезжает в Канаду.

(далее…)

Read Full Post »

« Newer Posts - Older Posts »

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