А причина всему одна...

Эти споры баг/не баг возникают потому что баг (дефект, проблема?) - понятие субъективное. И возникает оно когда ожидания одного лица отличаются от увиденного. Второе еще можно жестко зафиксировать, а первое никак, т.к. оно у разных лиц разное и, более того, еще во времени меняется. Usability баги тому отличные примеры. А дальше начинается social science woodoo со всякими Парадоксами Эрроу и другими интересными штуками, косвенно имеющими отношение к тестированию. Ну и согласно тому же social science woodoo приходится применять соответствующие примеры - контекст, ограничение влияющих лиц и т.п.


ЗЫ: Я к тому что ch_ip прав - для производителя телефонов косяки железа для одной модели это очень серьезная проблема, т.е. баг.

Жизнь у бага несколько иная, чем у железячного косяка.

Опять же - it depends. Как ни странно у железячного косяка и у бага есть много разных способов как прожить свою жизнь. iPhone4, например, ничего нигде не меняли. Мучения Symbian отдельная история того как одна маленькая, но очень замечательная ось пыталась мутировать подстраиваясь под изменившиеся требования реальности (epic fail в итоге, а в целом баги/дефекты/проблемы мешали).

Тем более странно, т.к. R это довольно мощный и гибкий инструмент для анализа прямо из коробки. И ничего толком под него писать не надо - тупо подсовывай датасеты и все.

не ерунда , увы)
на практике проверено и не единожды.)

Я к тому что:
1. В половине случаев это тестирование чужого сервера/клиента вашими письмами (как правило HTML формат и все такое).
2. В другой половине случаев это проверка интернетов.
Выполнять надо соответственно. Регистрация совсем не обязательна, достаточно письма отправлять.

Для тестирования того что ваша софтина работает корректно сама по себе достаточно локального почтового сервера (можно и без него, но тут объяснять дольше).

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

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

на моей практике была ситуация когда на почте 15 (именно 15-ое) отправленное письмо приходило через 24 часа.
проверить это можно было только создав 15,30, 45 и + ящиков на данной почте к примеру.

Это была ваша проблема или проблема чужого сервера?

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

При этом работающее приложение вам в принципе не нужно для этого, т.к. фактически вы проверяете thirdparty клиенты (имеет смысл, наверное) и сервера + как до них идет ваша почта.

Там в портфолио еще бывшие и нынешние работадатели почему-то указаны... Нет, для портфолио ок, наверное, но осадочек остается.

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

Это лишь один из возможных вариантов.

А другие какие?

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

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

ЗЫ: Overquoting FTW

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

Это лишь один из возможных вариантов.

xmind + руки (т.к. хочется часть информации из внешних источников протащить до mindmap'а автоматически)

А я и не писал, что если не могут ответить, то это хорошо. Это плохо, только вопрос в том, где оно плохо. Не факт что в архитектуре.

Как-то так: http://www.bettertes...content/?p=1438

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

Если вы делаете миллион проверок на любой чих, то медленным будет. У части приложений для тестирование извлечение свойств идет через пятую точку, так что может стать критично медленным. Одна проверка и 500 это разница. Пара секунд набежит на каждый экшен и уже совсем не очень. И у вас врятли же в GUI тесте будет "1 экшен" = "1 тест". А если вам еще сравнивать не тупо цифру/строку, а объекты, то начнется дискотека. Ну набежит пара минут на каждый тест. Ничего страшного если их несколько десятков. И если всего пара минут. А если больше?
И при этом никто вам не гарантирует что вы предусмотрели все возможные проверки свойств и все возможные экшены. Ваш тест найдет ALT, но пропустит CTRL+ALT+TAB, например. Хотите сделать все переборы? Ну ок, со странички вы можете выдрать все ивенты. Может быть. А для десктопных приложений уже не получится.

Это плохая логика проверять все, везде и сразу. Избыточные проверки это верный путь в декартов взрыв. Где-то они оправданы, но с ними надо быть аккуратным. Хардкодить эти проверки плохо и в итоге может стать дорого в плане поддержки. Делать их умными несколько дороже в плане реализации, но уже лучше. Но это дополнительные риски.

Нельзя закрыть тестами все. Более того - это не очень умно. Можно закрыть достаточно. Это утверждение верно и для мануальных тестов и для автоматики. И тут еще встает вопрос эвристик. Часть эвристик отлично работает для автоматики. Часть (визуальщина самый частый пример) слишком дорогие.

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

and even trying to automate a test for these types of issues is not just an effort in futility, I would say it is damn near insanity

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

Нет, автор просто пишет про авт. тестирования используя юнит-тесты или API.
А проверять свойство button-а это уже из области автоматического тестирования GUI.

В данных примерах он кажется вполне конкретно разбирает GUI test automation

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

Не, можно сразу взять monkey clicker и обозвать это автотестами. Ну допилить еще немного)
Без фанатизма многое ок. Дальше вопрос цены/времени встает.

Ну и в контексте топика все равно упираемся в вопрос:
- а какие же наши цели?
- какие тесты хотим писать?
- куда в конечном итоге хотим прийти?

Эти вопросы к выбору языка отношения не имеют (хотя сами по себе полезные, да).

Если коротко по выбору языка, то:
1. Выбирать надо то что лучше знаешь.
2. Если ничего не знаешь, то выбирать то, что проще учить (python/ruby, имхо).

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

В остальном все такие метания и топики это наглядная демонстрация Парадокса Эрроу. Другими словами - пустая трата времени.

Робинсон навеял пару идей, хоть и довольно тривиальных:

Робинсон вообще классный и у него есть чего еще на сайте пошарить. В принципе все что вы тут про графы написали у него там есть и даже больше :). И что самое примечательное, то большая часть "умных" тестов по моему личному опыту довольно простые и в техническом плане и идея сама (хотя идея очень часто не очевидна, тут ньюанс, да).

Я, наверное, больше занимался построением систем автотестирования, чем непосредственно написанием умных автотестов (у нас еще тупые не все написаны). Поэтому и описывал то, что интереснее с точки зрения создания системы/процесса, чем автоматизации проверок как таковых.
Ну и для больших сложных систем я верю в статистику как тестовый оракул, чем в фиксированные проверки, а статистику кроме как с пользователей и бетатестеров больше собирать не с кого. Да и приоритет бага, который ни один пользователь при нормальном использовании системы не воспроизведет, куда ниже, чем того, в который вляпается каждый второй за первые 10 секунд работы с системой.

Ну просто далеко не все могут позволить себе собирать такую статистику с пользователей/бета-тестеров. Просто потому что их еще нет, например, а риски выпустить не очень хороший билд даже в бету довольно серьезные. Но это обычно узкоспециализированный софт или всякие карты/поиски и т.п. как у Робинсона (хотя это уже вопрос тестирования UX скорее).
Опять же - поведение разных юзеров может сильно отличаться. Бывает что то что делают бетатестеры совсем не похоже на то что в итоге они будут делать с релизной версией. Да, баги они найдут. Может буть. Но оценить их полезность бывает весьма сложно, потому что "эндюзер хочет странного от продукта".
Ну и для десктопных приложений зачастую довольно затруднительно собирать статистику, поскольку прямого подключения у вас нет, а любой честный буржуй от таких предложений обычно начинает сильно параноить.

UPD: Заодно и Леше ответил)

Угу. Очень ок.

Для начала спасибо. Flexible File Writer как минимум
Ну и вопросы:
Raw Data Source?

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

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

Ну давай про автоматизацию exploratory тестов, чо

Ненене. Я про всякие oracle based тесты и прочее. Как у Робинсона про тестирование карт и подсказок поиска.

Есть еще нормальная тема про тестирование верстки и автоматизацию UX тестов. Harthy недавно очень годный доклад на эту тему читал про то как они на ибее это запилили.

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

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

Html5 тоже решаемо для кроулеров.
Ну и обычный кроулер делает не базовое тестирование верстки (даже не по чеклисту, кроулеры нынче умные и некоторые даже JS пускать могут по поводу и без), а тупое сравнение DOM (до и после), а это совсем не торт.

Про робинсона и Harthy вот например:
http://www.harryrobi...mation-CAST.pdf
http://blog.betterso...ttachment_id=24

UPD: А вообще оба предложения от вас в этом топике пока сводятся к записи за бета-тестерами. Меня это несколько настораживает.

Не соглашусь. 10+ лет назад я начинал работать тестером в компании Тугезерсофт. Делали UML/CASE тул (кстати никто еще лучше так и не сделал). В программе был специальный механизм для отсылки фидбека, если выскочил java exception.
Присылали и много. Мой коллега даже написал автосабмитер таких багов, который конечно дупликаты умел находить. Фиксили их кстати тоже, а не забивали.
Причем иногда до интересного доходило, разработчик видя стэк-трейс мог рассказать как баг воспроизвести можно. А иногда никто не понимал почему программа вырабатывала исключение в месте, где его не ожидалось.

Ну это немного не то). Такое есть и в общем-то практически повсеместно. Сами похожее используем (даже какую-то логику накрутили чтобы оно автоматом сотни дубликатов не плодило в багтрекере). Но статистику толком так собрать не получится. И опять же:
1. Unhandled Exception'ы такие штуки не ловят. То есть если мы где-то что-то недозавернули, то мы об этом можем никогда и не узнать, а у пользователя случится ой и он будет ругаться в саппорт.
2. Мы так можем получить только баги которые явно приводят к ошибке. Косяки бизнес-логики когда приложение ошибок не выдает, но работает некорректно мы так отловить не сможем.
3. Мы себя ограничиваем сильно по компонентам программы. Для инстоллера придется писать свою, да и то врятли получится. Если компонент куча, то не всегда есть возможность собирать со всех информацию в кучу, а баг случается на взаимодействии часто.
4. Это все же не статистика. Это какая-то довольно странная выборка, хоть и в определенном смысле интересная.