Публикации OVA

#99519 узнать отзывы всех линок на странице + узнать размер страницы + отчёт

Отправлено автор: OVA 12 января 2012 - 08:15 в Свободное общение

Файербаг можно честно научить складывать все куда-нибудь на диск.
Но вообще странные измерения, т.к. от workflow может изменяться и скорость загрузки/размер страниц. Есть это такой performance testing, то лучше так не делать. Это плохая стратегия для performance тестов.

#87497 Фриланс тестинг и все что с ним связано

Отправлено автор: OVA 26 апреля 2011 - 02:28 в Личный рост, карьера, развитие

В какую, если не секрет?

Торговля наркотиками, оружием и прочая работорговля. Говорят там гешефт сейчас самый большой.

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

А вышло так потому что IT в этой стране это по большей части отрасль программистов для программистов. И рудименты этой странной мутации мы можем воочию наблюдать практически везде.

#96233 Ученик QA-джедая (бесплатно научим и денег дадим)

Отправлено автор: OVA 26 октября 2011 - 10:20 в Работа/Росcия

В каком городе Академгородок? :)

Там в теме написано

#100603 Уровень абстракции тестов

Отправлено автор: OVA 07 февраля 2012 - 06:40 в Автоматизированное тестирование

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

Нет ничего что всегда оправдано.

Писать полноценную машину это долго, но запчасти для таких роботов можно писать относительно просто, а профита с них много. Сколько у вас времени займет написание скрипта, который будет случайным образом наполнять корзину интернет-магазина и проверять что все ок? Сколько времени займет перевод скрипта на контролируемый ввод? Сколько времени займет построение графа состояний корзины (для дизайна же делается, чего уж там)? Сколько времени займет генератор сценариев из этого графа для вашего скрипта с контролируемым вводом?
Скрипт на тестирование автоподсказок в bing'е у Harry Robinson'а составил всего 40 (кажется) строк кода. А профита с него было много.

Есть частично готовые решения (не очень хорошо заточенные именно под workflow, но зато отлично работающие в плане покрытия графа состояний): http://crawljax.com/plugins/
Можно начать писать с простого набора автоматизированных оракулов (искать и читать на тему Oracle Based Test Automation).
В общем поле для творчества весьма богатое, да и много времени много там далеко не все кушает, особенно если слона не целиком кушать.

#100500 Уровень абстракции тестов

Отправлено автор: OVA 06 февраля 2012 - 04:10 в Автоматизированное тестирование

№2 еще бы допилить, чтобы ассерты были только в одном тесте, ну и в идеале - один ассерт = один тест.

#100518 Уровень абстракции тестов

Отправлено автор: OVA 06 февраля 2012 - 09:13 в Автоматизированное тестирование

Зачем? Зачем я буду следовать синтетическому ограничению, которое в основном советуют люди, которые пишут книги, а не тесты?
Возможно (хотя я не верю) в "настоящих" юнит тестах такое ограничение имеет смысл. Но у меня же UI тесты имитирующие действия пользователя.

Я не предлагаю следовать. Идеал он для того чтобы к нему стремиться. Мой опыт подсказывает что много ассертов в тесте зачастую хорошая эвристика для определения тестов на рефакторинг. Как правило такие тесты первые кандидаты в очереди на редизайн. Но мой опыт на то и мой, что не ваш.

Более того, далее стоит задача покрывать сценарии, описанные в спеке, т.е. там сделал действие, проверил, сделал, проверил итд в одном тесте.

А откуда такая задача? Это в принципе очень непродуктивный подход к дизайну автоматических тестов.

#100601 Уровень абстракции тестов

Отправлено автор: OVA 07 февраля 2012 - 05:42 в Автоматизированное тестирование

В принципе, автоматизированно каждый шаг можно проверить и по отдельности. Однако, много раз встречал ситуацию, когда отдельно все работает, а вместе почему-то нет.
Если продолжать филосовствовать дальше, то можно сказать, что это своего рода системный тест на базе случаев использования (use cases), в то время как отдельные тесты - это аналог модульных тестов.
Такого рода сценарии мы называем end-2-end тестами и проводим их при каждой выдаче приложения в тест. Получается, что это автоматизированный Acceptance testing.

Если покрыть все функции довольно плотно, то шансов на то что вместе оно не работает будет мало.
Да, согласен, риски еще останутся, но статичный сценарий для автоматических тестов их никуда не уберет. Мы просто прочертим себе дорожку по минному полю, где мины будут находиться легко и просто.
Я ничего не имею против простых сценариев. Т.к. они простые - они быстро выполняются и их проще поддерживать/дописывать/мониторить покрытие. В ряде случаев достаточно простые сценарии это очень дешевый способ отскочить. Но с усложнением сценария все эти бонусы начинают теряться.
Т.е. в вашем сценарии сразу можно выкинуть логин и всю навигацию - лучше проверять их отдельно, а остальные тесты делать без них.
Потом сделать пачки тестов для манипуляций с корзиной (небольшие, легковесные, легко рандомизируемые).
Потом сделать пачки тестов для оплаты разных корзин (нам же не обязателен UI чтобы получить точно такую же корзину?).
Это будет дешево и сердито. И придется постараться чтобы оправдать чем-то кроме паранойи наличие теста в котором будет производиться склейка всего вышеприведенного. Если вы боитесь что там в куки валится мусор - лучше проверять их. Это быстрее, дешевле и проще интерпретировать. Если боитесь что в разных ситуациях в базу пишутся разные вещи - улучшайте проверки в существующих тестах, сценарий тут не сильно поможет.
Собственно это я и имею ввиду утверждая, что автоматические тесты лучше дизайнить отдельно. Оправдание паранойи развесистыми сценарными тестами это очень дорогостоящее удовольствие. Иногда необходимое, но зачастую служащее как оправдание того, что кому-то лень заниматься Failure Model.

ЗЫ: А про Acceptance Testing есть старенькая и очень хорошая презентация от Болтона, кстати. В случае с автоматизацией ко всем бедам можно просто пририсовать, что приемочный тест будучи автоматизированным тупеет на глазах. Тем самым используя, например, всякие BDD фреймы (да и просто большие наборы приемочных тестов) стоит очень хорошо понимать с чем связались.

#100533 Уровень абстракции тестов

Отправлено автор: OVA 06 февраля 2012 - 10:50 в Автоматизированное тестирование

Оппа... И чем же он не продуктивен? Как вы собираетесь писать скрипт на проверку некоевого сценария состоящего допустим из 7-8 шагов (а иногда и 10-15)?

Давайте начнем с простых вопросов.
Вам точно нужно проверять именно этот сценарий? Если да, то почему. Ответ "мне так начальник сказал" это плохой ответ.
Что происходит в ходе теста?
Что бы вы хотели узнать в ходе теста?
Точно ваш сценарий это самый простой и удобный способ получить ответы на предыдущие два вопроса?

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

#96000 Тренажеры для тестировщиков

Отправлено автор: OVA 23 октября 2011 - 16:35 в Обучение тестировщиков ПО

Целенаправленное, это только целенаправленно копать. Для этого достаточно подружиться с гуглем, например. Ну или у граждан тренеров (и не очень) на прямую попросить.

#95972 Тренажеры для тестировщиков

Отправлено автор: OVA 22 октября 2011 - 17:23 в Обучение тестировщиков ПО

Всякие Бахи, Болтоны и прочие @testertested часто так или иначе публикуют прикольные ништячки, начиная от программок и заканчивая просто ребусами. Порой оно в живую проходит прямо онлайн (в твитторах, например) - подключайся-нихачу. Если уж совсем припрет - тематические форумы буржуинов, скайпы, мейл рассылки, личная почта любого из тренеров. Если совсем ерунды и агрессивной ереси не пороть - все будет.

#100453 Тестирование сервисов

Отправлено автор: OVA 03 февраля 2012 - 17:16 в JMeter - Тестирование производительности

А что такое xml-запрос? *trollface.jpg*

#96587 Тестирование приложения с консольным интерфейсом

Отправлено автор: OVA 03 ноября 2011 - 10:42 в Автоматизированное тестирование

А что мешает в том же питоне на основе Pyunit наколбасить тестов? Ну прикрутить хелперов, которые выход будут разбирать, прикрутить хелперов которые будут вход собирать и вуаля. Почти те же юнит тесты в плане писанины.

#96617 Тестирование приложения с консольным интерфейсом

Отправлено автор: OVA 04 ноября 2011 - 04:57 в Автоматизированное тестирование

Это будет нормальный конструктор, не более того. При этом если вам внезапно не понадобится более сложная логика чем вдувание predefined input'ов и сравнение с predefined-же output'ами, то никаких привязанностей толком не будет и будет очень даже компактно + еще получите всю xUnit инфраструктуру нашару. А если понадобится, то там и так и так придется громоздить.

ЗЫ: А вообще я не очень понимаю зачем питон, если делать как вы делаете. Почему не шелл скриптик сразу?

#96624 Тестирование приложения с консольным интерфейсом

Отправлено автор: OVA 04 ноября 2011 - 10:21 в Автоматизированное тестирование

Плохо читаете.

The Python unit testing framework, sometimes referred to as “PyUnit”

Вроде же одназначно написано.

Хэлпер это не про питон вообще. Это так, например: http://web.cs.wpi.ed...ng-helpers.html

#96619 Тестирование приложения с консольным интерфейсом

Отправлено автор: OVA 04 ноября 2011 - 08:28 в Автоматизированное тестирование

А вы внимательно прочитайте первые пару абзацев по каждой из приведенных вами линок - тогда поймете. :victory:

#87929 Тест на битые ссылки

Отправлено автор: OVA 06 мая 2011 - 03:40 в Selenium - Functional Testing

Crawljax взять и не париться, если уж так хардкорно хочется. Все равно тот же WebDriver, а вся логика на обход урлов и прочего там уже вшита.

#87879 Стесняетесь Ли Вы Назвать Знакомым Свою Профессию?

Отправлено автор: OVA 05 мая 2011 - 09:26 в Свободное общение

Нет. Правда я иногда теряюсь как называть свою деятельность в привычной для всех системе координат.

#95976 Русский тег для тестирования в твиттере?

Отправлено автор: OVA 23 октября 2011 - 10:19 в Про тестирование обо всём подряд

Есть мнение, что это не та штука о которой стоит договариваться на форумах.

#95971 Русский тег для тестирования в твиттере?

Отправлено автор: OVA 22 октября 2011 - 17:17 в Про тестирование обо всём подряд

А зачем?

#86887 Расчет трудозатрат тестировщиком

Отправлено автор: OVA 11 апреля 2011 - 10:05 в Тест-дизайн и ручное тестирование

По хорошему, этим должен заниматься руководитель тестирования.

У нас руководителей нет, так что оцениваем сами :( Это не трудно, надо только привыкнуть.

#86929 Расчет трудозатрат тестировщиком

Отправлено автор: OVA 12 апреля 2011 - 05:40 в Тест-дизайн и ручное тестирование

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

Легко и непринужденно. Просто чуть больше заложится на риски. И вы не поверите - оценивать можно даже Research задачки.

#97498 Распараллеливание тестов(Selenium+PHPUnit)

Отправлено автор: OVA 22 ноября 2011 - 16:28 в Автоматизированное тестирование

После каждого коммита можно все, если нужно.

На почитать по теме:
http://codeascraft.e...ide-and-concur/

Линки на их перепилы того же PHPUnit на гитхабе инклюдед. Если что, им можно писать и они охотно отвечают на вопросы.

#96866 Разновидности тестирования.

Отправлено автор: OVA 10 ноября 2011 - 11:40 в Про тестирование обо всём подряд

Виды контроля качества должны выбираться исходя не из типа ПО, а в первую очередь из уровня культуры разработки в компании. Во вторую очередь исходя из заранее заданных требований к атрибутам качества ПО. А веб там или не веб - дело 100500-ое. "Там где моют руки - там все нормально."

Я боюсь все еще сложнее и волшебный ответ как всегда - "there is no silver bullet for this problem".
Опять же - "контроль качества" это странная фикция, просто потому что "Там где моют руки - там все нормально", например. С другой стороны, "качество" это субъективное понятие и активность тестировщика по выявлению нужных субъектов и выявлению их же нужд она +/- всегда нужна. Опять же - опеределение атрибутов качества которые нас интересуют вопрос зачастую вполне обсуждаемый: http://thetesteye.co...acteristics.pdf

#96890 Разновидности тестирования.

Отправлено автор: OVA 10 ноября 2011 - 16:05 в Про тестирование обо всём подряд

Это уже BDD какой-то получается. В любом случае и те и те проверки стоит скорее называть "rejection checks" а не "acceptance tests", как это принято. По смыслу корректнее получится. И в любом случае это все еще недостаточные процедуры.

#96860 Разновидности тестирования.

Отправлено автор: OVA 10 ноября 2011 - 11:28 в Про тестирование обо всём подряд

ручное нагрузочное тестирование
Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.
Я жажду подробностей этого извращения.
http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php

Это где-то очнь далеко от тестирования. Но вообще можно и как фб делать - нагрузки сразу на живых пользователях проверять.
Главное чтобы мозг рака вот до такого не добрался (а необремененный знаниями и перенасыщенный терминами мозг может): http://loadstorm.com.../happy-new-year