Feeds:
Posts
Comments

Archive for the ‘Неприятно’ Category

QA…

Developers…

QA vs Developers…

Если бы и QA, и Developers умели анализировать требования, и делали бы это постоянно, каждый раз ДО ТОГО, как браться за дело…

Невероятно отравляющий подход “Good enough” так “good enough” таки облегчает бизнес…

И следствие упрощения слияния функций аналитика и исполнителя в одном лице…

И это упрощение так всеобще, что обратного хода не должно быть. Надо искать другой способ. Может быть, слабое звено находится непосредственно в human approach?

Dilbert User Requirements

Read Full Post »

А давайте вот что сделаем.

Давайте мы не пойдем на очередной тренинг по тестированию методом замученного поиска в аджайл.

Никуда это от нас не денется просто потому, что это не для всех и не для каждого.

Все равно ведь “Было очень интересно; вопросы появятся после практического освоения полученого материала; но поскольку в нашей компании это будет будет невозможно внедрить, то практического освоения полученого материала не будет; поэтому вопросов нет и не будет…Фубля!

Давайте мы возьмем, купим, скачаем, нагуглим, разъяндексуем хотя бы книжицу ‘A Practitioner’s Guide to Software Test Design‘ за авторством Lee Copeland (он еще жив).

Там есть целый раздел “Black Box Testing Techniques”, и содержимое его такое:

  • Equivalence Class Testing
  • Boundary Value Testing
  • Decision Table Testing
  • Pairwise Testing
  • State-Transition Testing
  • Domain Analysis Testing
  • Use Case Testing

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

Это наша мамкина титька, если угодно.

Давайте эти главки прочитаем хотя бы по-диагонали.

И давайте сделаем это ПЕРЕД тем, как пойти на очередной тренинг по тестированию.

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

А если соображалки на “прочитать ДО того, как” традиционно не хватает, тогда мы не будем брюзжать, что “тренер просто пересказывает Коупленда“.

Пусть он нам хотя бы Коупленда пересказывает.

Давайте мы хотя бы Коупленда освоим.

Read Full Post »

Роман Савин в финале “Тестирование дот ком” (страница 301) рассказывает следующее:

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

Молодой человек отучился в колледже и на курсах тестировщиков (ни колледж, ни курсы акценту особо не помогли). В один из дней его пригласили на интервью в ту самую западную компанию. Он пришел и переговорил с менеджером отдела тестирования. После менеджера его проинтервьюировал сотрудник отдела. На следующий день молодой человек получил предложение о работе и лишь через четыре года узнал все подробности, а подробности таковы:

Выйдя из комнаты, менеджер понял, что из всего сказанного этим русским он на сто процентов понял только одну фразу “Выл ворк дэй энд найт” (“Will work day and night” — Буду работать день и ночь).

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

Сдается мне, Джим, что этот парень не совсем хорошо говорит по-английски. Но зато какое отношение к работе!!! Пойди-ка и поговори с ним на любую тему: о природе, ценах на нефть, скучает ли он по России. Самое главное, что тебе нужно выяснить: будешь ли ты в принципе понимать его.

Джим пошел и поговорил, потом пришел к менеджеру и сказал

Конечно, акцент у него будь здоров, но дело в том, что я вырос в среде русских в городе Чикаго и даже немного говорю по-русски. Так что надо брать. Этот будет работать за троих. Да и на предложенную нами зарплату сразу согласился.

Нужно сказать, что ни менеджер, ни Джим ни разу не пожалели о своем решении.

Дык вот, это безусловно хорошее отношение к делу, но это плохой пример для подражания “в лоб”.

“Выл ворк дэй энд найт” — это кислая вишенка.

  • Если она находится на сладком и красивом торте — она рулит.
  • Если она просто сама по себе, плюс положена на какое-то недоразумение под названием “праздничный пирог” — это буэ, это кисло. Это фу.

В принципе “Выл ворк дэй энд найт” — это позиция слабого. Это просительное выражение. Само по себе оно производит очень нехорошее впечатление.

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

Анадысь очередной кандидат написал этот “Выл ворк дэй энд найт” непосредственно в своем резюме.

Это вызывало ряд вопросов с тэгом “Недоумение”, и дальнейшая встреча все это недоумение зацементировало — просто начинающий тестировщик (без огонька) просто ищет просто работу, бо ему надо здесь и сейчас.

Его стало очень жалко, а когда становится жалко — предлагать работу нельзя.

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

Походу, ему было страшно.

Цель его была озвучена в таком стиле: “Готов работать днем и ночью до тех пор, пока вы не посчитаете меня профессионалом“. А потом что? Стал профессионалом и резко перешел на двухчасовой рабочий день? А если пять лет никто не будет считать тебя профессионалом?

И что за абстракция такая – быть профессионалом…

В общем, Савина продолжаем читать, но и по сторонам глядим.

Например, готовность работать день и ночь оценит менеджер общего плана, но совсем не оценит технарь…

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 »

Бывает так, что Тестировщик Прозревает: “А было бы круто, если бы программисты писали юнит-тесты. Это же круто! Это позволяет избежать следующих рисков:

  • бла,
  • бла-бла,
  • бла-бла-бла,
  • бла-бла-бла-бла…

Таким образом можно обеспечить процесс…

Типичный диалог

который следует далее:

– Вам, ребята, неплохо было бы перейти на юнит-тесты. Вы ведь знаете, что такое юнит-тесты?

Ну, наверное… Только мы и так не успеваем, а тут еще и тесты писать придется отдельно…

– Да нет же! Это не те тесты! Это те тесты, которые пишутся ПЕРЕД тем, как пишется код. Понятно?

Нет.

– Ну, блин… Вот, перед тем, как заимплементить фичу на стэйджинге*, ты лабаешь код, который будет ее проверять. Понятно?

* Юзаем спецязык, шоб не думали, что мы тут лаптем шиты; “не соло, но хлебавши” ©.

Ну, кагбэ…

– Вот! Вот! И это позволяет нам избежать следующих рисков:

  • бла,
  • бла-бла,
  • бла-бла-бла,
  • бла-бла-бла-бла,
  • дынь-дынь-дынь-дынь,
  • бул-бул-бул-бул-бул-шит…

Ну хорошо, но… Как это делать?

– Ну, я же не знаю, это же ваша область ответственности; вы и решайте.

Нда. Ладно, мы подумаем (о чем-нибудь другом).

Резюме

Юнит-тесты – это не просто хорошо.

Это иногда очень хорошо, ЕСЛИ программисты умеют это делать.

Если умеют, то и говорить не о чем.

Если не умеют, то тот, кто приносит инициативу, предварительно должен научиться эти самые юнит-тесты писать и переписывать. Иначе будет фэйл.

Я на этот фэйл когда-то отлично напоролся, повторять не рекомендую.

Будут воспринимать как неадекватного, и будут правы.

Read Full Post »

Молдавское айт-ти развивается семифутовыми прыжочками в Маракотову бездну. Уже требуются тестировщики даже в газете “Маклер”.

Хотя с оговоркой о том, что нужны “Навыки в области performance/stress/security/usability/functional/regression тестирования“. Типа, “бухгалтер со знанием итальянского языка для работы с голландским офисом“.

Но все-таки.

(more…)

Read Full Post »

В октябре James Bach посетит Румынию. А еще будет в Эстонии.

Насквозь братская Румыния для Молдовы все равно, что другая планета 😦

Read Full Post »

Older Posts »

%d bloggers like this: