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

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

А зачем?

1. Если много кастомных контролов, то ряда описанных Павлом проблем не будет никогда. Но тм возникнут другие - свои контролы, свои обработчики ивентов и свои тараканы во всем этом.
2. Есть примеры очень шустрых приложений на нем.

В остальном соглашусь. Особенно по пунктам 6, 8 9 и 11. Там можно очень много описывать примеров. Дефолтные контролы там местами написаны через пятую точку, а понятие backward compatibility у граждан из adobe более чем странное.
Ну и про дебажный плеер таки да - сильно помогает жить (хотя как показывает практика таки отличается порой от своего недебажного собрата).

С условиями фишка такая -- вы сообщили о "дефекте в условиях", и ждёте, пока его исправят.
Но пока не исправили -- работать-то всё равно надо. Поэтому приходится искать воркэраунды.

Почему ждем? Мы же решения не принимаем, так что ждать тоже смысла нет. Наша работа предоставлять информацию о рисках и проблемах. И в этом плане memory leak это точно такая же проблема и точно такой же риск как и изъяны в рабочем процессе. Проблемы с Testability могут жрать не меньше времени чем регулярно падающая установка продукта. Про игнорирование постоянно повторяющихся шаблонов дефектов и проблем порождаемых многочисленными заплатками на них я вовсе молчу. И как правило никто не будет счастлив если я заберусь в код и начну себе хуки там делать для тестирования или просто сяду и перепишу (хотя мне так уже приходилось делать я все еще не вижу в этом ничего хорошего). И я не иду править код который приводит к утечкам памяти. Точно так же не пойду делать за менеджера/аналитика/архитектора/кого-то-еще-с-красивым-названием-должности его работу.

Мы можем тестировать быстрее, но...
Мы можем тестировать более эффективно, но...
Мы можем сообщать более качественную информацию о дефектах, но...

Если все заинтересованные лица в курсе и их это устраивает, то вопросы "почему вы пропустили этот баг?" по меньшей мере странные. Если не в курсе - надо им помогать.

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

А чтобы отбрыкиваться от таких задач надо обладать опытом/знаниями, которых зачастую нет, потому как за свои 2-3-5 лет в тестировании многие просто не видели никогда в какой адочек это все может превратиться или не осознавали что за адочек творится вокруг.

А сообщать о потенциальных и очень даже актуальных проблемах и дефектах на проекте разве не наша работа?

А что мешает сообщать про условия, если мы точно знаем что в них есть дефекты? Ведь это могут быть критичные для проекта дефекты, например. Ведь в таком случае условия нужно менять.

Скорее в цену незнания. Это не обязательно должны быть ошибки.

Почему я пропустил эту ошибку?

Потому что я искал другие ошибки. Тысячи их. А когда в продукте очень много ошибок почему-то очень много времени уходит на его тестирование. Сильно меньше чем когда в продукте мало ошибок. Сильно страдает эффективность тестирования как такового. TDD, CI, Code Review (не отмазки типа "я посмотрел, вроде ок"), Testability, раннее вовлечение пользователей в работу над продуктом, отличные логи, отличный мониторинг работы продукта, никаких головняков с установками и переконфигурацией, хорошие инструменты для тестирования - это может помочь улучшить качество поставляемого на тестирование продукта, но не спасет. Чтобы лучше находить баги, чтобы их было проще диагностировать и чинить - Testability.

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

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

Пропуск ошибок это зачастую не проблема отдела тестирования. Просто очень сложно построить качественный продукт, когда нет хорошей культуры качества. Когда каждый член команды работающей над продуктом не делает все возможное чтобы сделать качественный продукт. Часто это системная проблема. Программист знал что где-то могут быть проблемы, но не посчитал нужным сообщить. Или он написал код, достаточно сложный для того чтобы при последующих изменениях в нем никто не мог понять где же оно рухнет. Или код простой, но этот простой код внутри выстраивается в такие сложные цепочки взаимодействия, что ряд изменений (обычных последнее время) надо делать долго и аккуратно, внося его всюду. И в итоге что-то забывается и код не работает. Это возникает потому что программист нерадивый или потому что над ним сидит менеджер который по самые уши напортачил с планированием или наобещал ге-то с три короба и теперь заставляет команду работать в очень сжатые сроки воспитывая парадигму вида "после нас хоть потоп". Или менеджер жрет время команды на бесполезную активность вроде отчетов которые ему на самом деле не нужны (или он не объяснил команде просто и доступно зачем они нужны и тем самым деморализует ее). Или дурацкие митинги. Или менеджер игнорирует жалобы команды разработки просто говоря что-то вроде "keep going that way"? Или тестировщики занимаются не эффективным тестированием? Может они не видят под носом шаблонов в ошибках? Не могут их хорошо диагностировать и не представляют что как работает и зачем оно нужно коду/проекту/бизнесу? Или они заняты игрой в бюрократию и пишут тонны бесполезной тестовой документации вместо того чтобы тестировать? Или это просто плохие тестировщики которые умеют только жмакать на случайные кнопочки и бить кувалдой по монитору? Или эти тестировщики просто проверили что все что написано в ТЗ продукт делает и успокоились?




Это не спора ради, это я так, дополнить)

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

Я тоже очень хочу чтобы я такой сидел и мне все делали хорошо забесплатно. Но так не бывает.
Большая часть готовых коробочных изделий отлично работает ровно до тех пор пока нет потребности или желания за рамки этой коробки выбраться (а оно возникает, если вы собираетесь серьезно заниматься своей работой, а не отчеты красивые рисовать). А дальше *ВНЕЗАПНО* начинается опять же то же что вы написали. И это в лучшем случае. Потому что обработку сырых данных написать достаточно один раз. Скрипты на R тоже не сильно сложно, если разобраться что и как там работает. Сборка любой метрики так же пишется ровно один раз. А если это все еще и не нужно прикручивать к уже существующему решению с закрытым кодом и/или уродским API, то занимает оно не так уж и много времени.
Генерацию графиков и прочее на R писать не надо. Оно само отлично с рядом задач справляется.

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

А что нужно заменить? Генератор нагрузки не устраивает? Или работа с данными? Raw Data + R сильно лучше средне-бесполезных свистелок.

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

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

По Армору 2nd Order Of Ignorance предполагает что есть достаточно эффективный способ устранить незнание о незнании. То есть когда мы можем задавать вопросы и получать в ответ чуть более хорошие вопросы (или ответы сразу, если уж совсем повезло). А когда способа нет, это уже 3-й и мы скорее всего в полной заднице.

Но в принципе не суть важно, т.к. вся статья вокруг 2 и 3 крутится.

Вообще очень хорошо что такие вещи обсуждаются) Жаль что не смог доехать.

Прогон 100 GUI тестов занимает примерно 40 минут.

Это мнооооого). Это значит что на 1000 тестов нам надо минимум 10 агентов чтобы прогонять тесты. Притянуто за уши, но логика, я думаю, понятна.

Андрей, кстати, было бы круто если бы кто-нибудь (например ты %)) собрал все эти материалы в одном месте и еще чтобы с камментами, картинками, линкой на то чтобы скачать лунапарк и все такое)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уже не хватает=)
Группировка запросов уже идет, и проблема возникает в пределах группы. Мне видится проблема близкая к "не смешивать в одну кучу запросы в секунду и количество работающих пользователей" - в том плане, что есть тенденция к разделению оценки запроса и бизнес-действия. Мухи отдельно, котлеты отдельно.
Использование квантилей наиболее адекватное решение на текущий момент, но тупо сложное для восприятия(да и сравнения) - навороченная табличка получится.
Хотя понимаю. что желаю получить формулу дял вычисления числа, поисывающее всё и вся :D

Боюсь тут чем-то придется жертвовать. У меня, слава б-гу, нет пока надобности рисовать красоту и понятность для менеджмента и заниматься аналогичной ерундой, так что мне тут трудно что-то советовать. То есть те же квантили в табличку лучше не пихать - будет не очень наглядно и красиво. Зато графики с ними можно сделать отличные. Как-то так, наверное.

Ну и вообще вопрос представления данных и их обработки довольно интересный и местами сильно упирается во вкусы. При этом регулярно надо балансировать между тем чтобы захламлять себе голову лишней (читай "не очень актуальной для анализа") информацией и полезностью картинки. То есть можно взять две крайности - логи и "график среднего отклика по серверу". Первое явно лучше для того чтобы понять "ZOMG WTF!?!?!?!?", но очень медленно, особенно если перебирать все глазками (утрирую, конечно, но иногда и такое приходится). Второе удобно для локализации проблемы. Отсюда и начнем - надо накручивать ровно то, что, как вы считаете, может вам помочь в локализации проблемы, при этом чтобы ваши таблички/графики не скатились к логам. Кидать все метрики бездумно в кучу вредно. Вы ничего не поймете.