Здравствуйте, Andrew Grega, Вы писали:

AG>Утрирую, конечно. У самих на проекте автотесты есть, но, только на серверную часть. Клиент (игровой) тестится только руками и альтернативы этому нет.
У валва нет проблем с доступом с своему собственному игровому движку, в отличие от вас.
Они могут вывесить наружу (для тестов) любую функциональность и оттестировать её. Я о рендеринге на клиенте.

Здравствуйте, Venom, Вы писали:

AG>>Утрирую, конечно. У самих на проекте автотесты есть, но, только на серверную часть. Клиент (игровой) тестится только руками и альтернативы этому нет.
V>У валва нет проблем с доступом с своему собственному игровому движку, в отличие от вас.
V>Они могут вывесить наружу (для тестов) любую функциональность и оттестировать её. Я о рендеринге на клиенте.

Смотря что ты хочешь оттестировать в рендеринге. Правильно ли нарисовалась картинка — такое автотестами не покрывается. А вот вычисления необходимые при рендеринге на раз покрываются обычными функциональными тестами

Здравствуйте, IB, Вы писали:

>>Какие есть способы, кроме упомянутого мною, которые могут значительно снизить вероятность?
IB>Я уже написал.
А что нибудь конкретное? Относящееся к сабжу? "Комплексный подход" слишком кораблекосмично. Очевидно, что если улучшить всё, то всё улучшится. Правда, никакой новой инфы нет.

>>Что сделать, чтобы стало достаточно?
IB>Опять таки, уже написал.
А почему ты решил, что этого будет достаточно? Как ты определишь, что стало достаточно?

>>Если я что-то упустил, прошу напомнить.
IB>Вся наша ветка просто наполнена примерами и иллюстрациями, показывающими, что именно вы упустили. Учитывая вашу феноменальную забывчивость еще раз это цитировать бесполезно, поэтому если вам действительно интересно — не сочтите за труд, перечитайте ветку еще раз.
Примеры были всё не в тему. Я говорю, soak tests, а мне тут "owner draw".

>>>>Во-первых, всё никогда не будет отлавливаться. Ты требуешь теоретически невозможного.
IB>>> Это не я требую, это ваша же фраза. Опять мне вас цитировать?
>>Давай.
IB>Легко: "Поэтому, чисто по построению подход отлавливает всё." (с) У вас какая-то фантастическая способность противоречить самому себе, а потом с легкостью это забывать. Я вас уже раз в четвертый, наверное, ловлю — надоело. Научитесь за свои слова отвечать уже.
Не надо выдирать фразы. "Всё" в контексте, а не "всё" вообще.

>>Ок. Хорошо. А как определить, измерить, что качество продукта приемлимо для публичного релиза?
IB>Формально? Никак. Прохождение автотестов — необходимый критерий, но недостаточный. Решение о готовности продукта в релиз с точки зрения качества — принимает QA ответственный за продукт.
Т.е. если как только QA принимает решение, так сразу качество продукта становится приемлимым? Качество продукта зависит от решения одного человека? Хороший критерий, но негодный. В сабже — тоже кто-то решение принял. И что? Приемлимости это не добавило.

>>Вот в этом и заключается наше несогласие. Я считаю, что автоматическое тестирование должно быть на первом месте. И всё остальное — требования, окружение, код, етс должно происходить с оглядкой и учётом автоматического тестирования.
IB>Вы заблуждаетесь, не надо делать из автотестов культа — они не панацея. Я даже допускаю, что такой подход может быть оправдан на ваших продуктах, но в общем случае он ведет к весьма неприятным сюрпризам.
IB>О, я кажется понял причину вашего заблуждения. Вы тут с таким апломбом рассказываете про чудеса автотестов, просто потому, что даже если похожая проблема случится у вас в продакшене, то ничего страшного все равно не произойдет, и клиенты об этом даже не узнают. В продакшене сработает алерт при уменьшении дискового лимита, саппорт инженер быстро почистит логи, чтобы сервер дальше жил, а менеджер засунет шкворень разработчикам и тестерам, и у вас таки появится новый тест на рост логов.
Ещё раз. Мне плевать на общий случай, я рассматриваю инженерную проблему, а не философскую. Я рассматриваю вполне конкретную ситуацию — сабж. Общий случай это то, что мне тут пытаются навязать. Общие случаи — не ко мне, пожалуйста.

>>И тогда ручное тестировние (кроме UX) будет не нужным, более того, эффект от него будет отрицательным — требует деньги+время, а выхлоп околонулевой.
IB>Как наивно... Мы вот как раз закончили выпуск продукта с весьма скудным UI, в котором буквально три кнопки. Так вот, попытка покрыть его автотестами заняла больше времени, чем собственно разработка и большой
пользы в итоге не принесла. Если бы там можно было обойтись автотестами — мы были бы счастливы, но увы.
Интересно разобраться почему.

>>Ты ничего не предложил вообще,
IB>И не должен был. В очередной раз напоминаю, что выработка решения проблемы яндекса — не является темой этой конкретной дискуссии. В этой ветке вы впряглись показать нам, что автотестов достаточно, для решения этой проблемы. Пока безуспешно.
Конкретных аргументов я так и не услышал. Всё что было: "в общем случае он ведет к весьма неприятным сюрпризам", "лучше положить на подоконник", "потому что owner draw" и прочий оффтоп.

IB>Решение же проблемы в общем виде — тема отдельной дискуссии.
И мне неинтересной. Но почему-то вы дискутируете именно на эту тему.

>>Да тест существует, в смысле такой подход можно использовать. Но мы не используем.
IB>Жалкая попытка, ну да ладно.
Попытка чего? Если ты перечитаешь дискуссию, я с самого начала говорил, что теста в таком виде у нас нет, не было и не надо.

>>Нет у админов своих целей. Мы задаём цели.
IB>Даже как-то странно вам это объяснять. Если это именно амдины, а не инженеры QA у которых первый приоритет тестировать качество продукта, то у них естественно есть свои цели и вы конечно же о них узнаете, но будет уже поздно.
Поживём, увидим.

>>Она и задаётся, но не в коде, а в puppet/nagios. Зачем дублировать?
IB>SRP — если одна константа служит разным целям, то рано или поздно эти цели разойдутся и для одной из задач значение константы станет неверным.
Я говорю о DRY.

Здравствуйте, Ikemefula, Вы писали:

I>>>Может. Нет противоречия. _Типичный_ exploratory это ручной. Из этого не следует, что все exploratory исключительно ручные.
"новые баги ищутся только руками" == "exploratory исключительно ручные". Разве нет?

I>·>Типичность варьируется, вещь субъективная. Может у для вас это типично, ибо традиция, низкая квалификация тестеров|разработчиков, бедность или жадность. Факт в том, что бОльшую часть можно автоматизировать.
I>Есть другой факт — ты пока еще ни раз не привел даже описание, как автотесты могут найти новый баг.
Ровно так же как и ручные, только вместо мыши используешь код.

I>>>Объясни внятно — каким образом девелопер напишет тест на ту часть, которую он упустил из рассмотрения ?
I>·>Если что-то упустили из рассмотрения, то оно и вручную не будет протестировано.
I>Неверно, QA не обязан следовать жостким процедурам. В UI зачастую QA говорит "приемлемо" и всё.
Результатом следования жестким процедурам будет абсолютоно жесткий код авто-теста. Который абсолютно жестко должен проходить.

I>>>Потому что первый вариант больше никому не нужен.
I>·>Если не нужен — удали код вместе с тестом. Останется один тест. Зачем тестировать то, что больше никому не нужно?
I>Правильно — удалить. Когда требования размыты, что норма для UI, и постоянно меняютс, ты профита от своих мега-тестов никогда не получишь.
I>Авто-тесты покрывают исключительно устоявшийся функционал.
Типичное заблуждение.

I>>>В одном месте скрипты навроде "очистить базу", в другом — UI для тестирования. И то и другое вызывается мышом.
I>·>Вот о чём и говорю. Вместо того, чтобы и то и другое вызывать кодом, вы тащите в процесс тестирования дополнительные мышевозилки.
I>Ты пока еще не привел, как же кодом найти новый баг.
Привёл. Что-то там про списки айтемов в меню было. Если ещё непонятно, представь себе как бы ты что-то делал вручную и предположи, что все эти шаги можно сделать не мышой, а кусочком кода.

I>>>Во вторых, ты забыл что надо пофиксить все красные, а не просто посмотреть
I>·>Ты вроде сказал что "посмотрев глазами станет очевидно, что всё ок".
I>Правильно — глазам я доверяю, а твоим тестам — нет. Визуально — всё в порядке. А вот тесты красные.
Потому что у вас тесты плохого качества, какой-то один чувак два года и восемь месяцев ваяет, всем остальным плевать, все тупо кодят. Мы тестам доверяем.

I>>>Во третьих, ты забыл что зеленые тоже возможно придется фиксить, потому что новый девайс == новые неучтенные кейсы.
I>·>Зелёные говорят, что работает ровно точно так же. Что может быть неучтённого?
I>Опаньки ! И ты снова утверждаешь, что тесты ловят вообще всё. Браво !
I>Например три твоих теста для кнопки показывают, что она видна, имеет координаты нужные, нажимается. А на новом девайсе у ней стиль некорректный и глазом эта кнопка вообще не видна. Глазом видно, что проблема есть.
I>И это не UX. Это ты коряво написал и тесты, и функциональность.
А конкретно? Или ты опять про общий случай? Вы там капчи пишете или тестопригодный код?

I>>>В реальных ситуациях ручное применяется в обязательном порядке. Никто не отдаёт прогу в релиз, если она прошла автоматические тесты.
I>·>Не понял. Так ручные или автоматические?
I>А ты попробуй перечитай. Если ручный — обязательные, то релиз с автоматическими без ручных состоится или нет ?
У нас во время релиза ручное тестирование не применяется.

>>>Никто и никогда, кроме отмороженых на всю голову индусо-контор.
I>·>Типа яндекса?
I>И в яндексе такого нет, не сочиняй.
Как я понял, они сказали, что одной из причиной факапа было отстранение ручных тестеров, т.к. была спешка. Я неправильно понял?

I>>>Ну вот покажи адаптацию для случая "радиобатоны -> explorer-like UI"
I>·>Тесты не адаптируют. Что показать-то??
I>Твоё скромное "тесты изменяют" в данном случае "тесты выбрасывают и пишут новые"
I>Как часто ты сможешь проделывать эти фокусы ?
Ровно так же как и любой другой код. В чём разница-то?

I>>>"измени" это значит выбросить всё и написать заново.
I>·>Иногда да, допустим. И что?
I>Не иногда, а постоянно и это норма. Это же не серверный АПИ — ожидаем логинг-пароль в таком то формате, отвечаем 200 + токен в хидере.
I>В UI будет скорее "юзер должен иметь возможность работать с персональными данными и что бы эти данные никто кроме него не видел"
А почему именно так? В чём принципиальная разница? Почему нельзя сказать "ожидаем поля имя|фамилия, их можно редактировать". А иначе и с серверным АПИ можно сказать "приложение должно иметь возможность работать с персональными данными и что бы эти данные никто кроме него не видел" и не париться.

I>>>Это небольшой набор частных случаев. Покажи мне, как IDEA сможет устранить дублирование в таком случае — есть 10 похожих методов, надо заменить тело каждого на вызов одного универсального с разными параметрами.
I>·>Да запросто — постоянно так делаю. Используешь extract|inline parameter|method|variable рефакторинги, изменение логических условий (например "a || b --> !(!a && !b)"), invert if statement и т.п. несколько раз подряд.
I>Ну то есть куча рукопашных действий. А начинал так хорошо — `IDEA всё умеет`.
I>`умеет` это вот так — выделил дублирование, IDEA сама все сделает.
Так умеет, если достаточно близкое дублирование: https://www.jetbrains.com/idea/help/replace-method-code-duplicates.html
Но это только в простых случаях и семантику оно не добавляет. Если дублирование не очень похоже (например, порядок действий может быть слегка разным). Идея не делает предположения, а другие рефакторинги это могут уточнить.

I>>>Наблюдаемое поведение — это _вызов_ метода
I>>>Место вызова — не есть поведение.
I>>>Ты хочешь не только вызов детектить, но и само место. То есть, у тебя по определению НЕ юнит тест. И никогда им не будет.
I>·>Ничего не понял.
I>"метод А коллбека будет вызван..." — поведение
I>"из метода run вызовем колбек метод А" — сравни разницу. Если ктото перенесет вызов колбека наверх, скажем после вызова run или перед вызовом, то поведение не изменится, а твой тест — упадёт, потому что мок будет ожидать вызова из метода run.
В смысле поменяется юнит? Да, конечно, тогда юнит-тест должен упасть. Ибо этим юнитом могут пользоваться другие участки кода и ожидать вызов коллбека. Или я так и не понял что ты имеешь в виду. Лучше код покажи.

I>>>Простой для кого ? Для тебя, для джуниора который будет фиксить, для новчика в проекте, который пришел совсем из другой области, для человека, у которого в 10 раз больше опыта чем у тебя ?
I>·>Ну, допустим, простой для значительной части команды. Т.е. в любое время можно найти кого-то, для кого этот код кажется простым.
I>Если код простой для значительной части команды, значит команда занимается делом ниже своей квалификации, т.е. "художник работает маляром".
Система — сложная, код — простой. Код должен быть простым, иначе это плохой код. Писать сложно — просто, писать просто — сложно.

I>>>Нет никакой разницы между "девелопер забыл добавить кнопку" и "написал не тот стиль и кнопка не видна"
I>·>"Кнопка не видна" проверяется через isDisplayed в selenium.
I>а ты поинтересуйся, как это реализуется в селениуме.
Я знаю. Проверкой стилей. Никаких "неизвестных артифактов". Я понимаю, что можно наворотить кода, который обманет селениум. Но тут всё просто — не надо так делать.

I>>>БОлее того, "кнопка ничего не делает" и "у кнопки не тот стиль" это абсолютно одно и то же — ФУНКЦИОНАЛ НЕ РАБОТАЕТ
I>·>И это элементарно детектится selenium-ом.
I>Селениум детектит только кое какие свойства. Он не может сказать "форм выглядит не так, как должна".
Ты уж реши, вначале "ФУНКЦИОНАЛ", а потом вдруг "выглядит". Ты уж определись.

I>>>Скажем, у тебя вылазит такая проблема — UI подмораживается на секундочку во время тайпа.
I>·>Типичный UX, функция работает, но пользоваться ей неприятно.
I>У тебя все неудобное это UX.

The User Experience is everything that happens to your users when they interact with your business or organisation via your website, application or online communications. It includes everything they see, hear and do as well as their emotional reactions.

Если неудобно|неприятно это считается "ФУНКЦИОНАЛ НЕ РАБОТАЕТ", а не эмоциональные реакции, то я сдаюсь. Считай, что я слил.

I>>>Или такая — апликачка на старте иногда получает белый скрин или черный.
I>·>Но кнопки нажимаются? Это как?
I>Легко. Движок кривой. Покажи тест.
Самый простой вариант. Как часто меняется стартовый скрин? Раз в месяц? Сделай снапшот и сравнивай (возможно частично). Когда кто-то будет опять менять стартовый скрин — сделает скриншот опять, займёт 1 минуту.
Или у тебя там опять проблемы с 3rd party, owner-draw, win32?

I>>>Ты по моему нихрена не читаешь
I>>> БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.
I>·>Вот допустим, "иногда получает белый скрин или черный." Вы это обнаружили, пофиксили, скажем, race condition в инициализации синглтонов. Сделали авто-тест, который что?
I>Ты мне расскажи, что это за тест будет. Я ведь именно этот вопрос и задаю.
Так вроде ты о регрессии говоришь. или данный случай не "В ОСНОВНОМ"?

I>>>Ну то есть все пишут без ошибок и ваши тесты ловят вообще всё. Я так и думал.
I>·>Реопен это регрессия. У вас же "РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ." Откуда тогда у вас реопены? Да ещё в статистически значимых количествах, что можно принимать решения о квалификации разработчика?
I>Реопен потому, что работу девелопера проверяет другой человек, иногда — несколько.


I>>>Успокойся. Речь о том, как найти новые кейсы, которые не предусмотрены тестами.
I>·>Да как угодно. Мы ищем обычно используя инфраструктуру поддержки авто-тестов.
I> Покажи уже эту пульку.
Вот например, этот тест тестирует два разных UI (в одном меняются настройки, в другом используются) и один API:

    @Test
    public void shouldSetCurrentLanguage()
    {
        registrationAPI.createUser("vasya", "language: ENGLISH");
        clientPortalUI.login("vasya");
        clientPortalAPI.login("vasya");

        clientPortalUI.settings.verifyUserSettings("language: en");
        clientPortalUI.settings.setUserSettings("language: de");
        clientPortalUI.settings.verifyUserSettings("language: de");
        clientPortalAPI.settings.verifyUserSettings("language: de");

        tradingUI.login("vasya");
        tradingUI.verifyContactLabelsCorrectForLanguage("GERMAN");
    }

Для exploratory testing можно варьировать код, поставить точки останова, етс, скажем, что будет если попытаться установить неподдерживаемый язык?

I>·>Речь же должна идти к тому, как можно избавляться от кейсов, которые не предусматриваются тестами.
I>Это легко — астрономическое число тестов, а лучше даже бесконечное, решит эту проблему.
Не бОльшее чем ручных.

>>А судя по тому, что ты рассказываешь, у вас процесс обратный — сервера тестируете через UI, счётчики визуализируете для упрощения ручного тестирования...
I>Я говорю исключительно про клиентские проблемы, а тебе мерещится сервер.
Ты сказал, что UI-тест выявил что сервер возвращает неверный ответ.
Ты сказал, что для контроля диска вы визуализируете счётчики, чтобы юзеры могли проверять во время ручных тестов.
Что мне померещилось?

I>>>·>пиши в сеть, сохраняй на терабайтный винт.
I>>>Не надо ни сети, ни терабайтных винтов. Есть решения проще, дешевле и надёжнее.
I>·>Какие?
I>В зависимости от приложения. Иногда можно просто в файл писать напрямую. Иногда подключается готовый сервис на устройстве. И тд.
Ты только что жаловался, что это непредсказуемо влияет на тестируемый UI...

I>>>Не смешно. Проблемы которые вылезут здесь, совсем необязательно вылезут в штатном режиме. А вот с большой вероятностью вылезут проблемы, например, из за неуёмного свопа.
I>·>Опять ты как-то странно считаешь. С 4-байтным пикселем это всего 800мег. Откуда своп?
I>В самом деле, одной транзакцией откусить 20% всей памяти на девайсе или 40-60 от свободной на том же девайсе.
Опять общий случай рассматриваешь, или на свою жизнь жалуешься. У меня 24GB оперативы, на серверах в несколько раз больше. Так что сильно меньше 20%

I>В самом деле, откуда своп ? А представь, фрейм надо рисовать не менее 10-20 раз в секунду и собирать его из 5-10 битмапин того же разрешения ?
А если представить, что не надо?

I>в 32х разрядах даже в десять раз меньшие цифры дают OutOfMemory, а 64 бита — жесточайший своп.
А может быть и нет. Не суди других по себе.

>>Вообще 20к*10к это не что-то сверхестественное. Попсовый IMAX это 10k*7k, что всего лишь в 3 раза меньше моих от балды названных цифр. Так что пока тут только ты на порядки ошибаешься.
I>Для UI винды и андроида это более чем сверхестественное. Ты в курсе, что оптимизациями не только ты занимаешься ?
А я что-то об андроиде говорил?

I>>>Я — о тестах, а ты, судя по битмапам 20к на 10к, о сферических конях в вакууме.
I>·>Не важно. Ты хочешь сказать, что для UI не делают тесты, которые человеку сложнее проанализировать, чем компьютеру? Или ты можешь гарантировать, что никто никогда в мире не рендерил картинки 20к*10к?
I>Рендеринг картинок и UI это две большие разницы. UI оптимизирован по самые `не хочу`. Это значит, что кейсы которые не встречаются в реале, могут быть сколь угодно медленными, если реализация позволяет ускорить основные.
Конечно. Всё от конкретной ситуации зависит.

I>>>·>Компьютер ничего не умеет. Что скажешь, то и будет делать.
I>>>В сотый раз повторяю — покажи тест, который находит ранее неизвестный кейс, последовательность и тд.
I>·>Покажи такой мануальный тест вначале.
I>обычный exploratory. Если ты не в курсе, для этих тестов нет заранее заготовленой последвательности.
Ну вот. Замени теперь мышь на код — будет теперь и компьютер уметь.

I>>>Итак — ответа нет. Ты хорошо понимаешь, что тесты UI на радиобатонах все до одного надо выбросить, а новые писать с нуля ?
I>·>Собственно как и сам код — код радиобатонов придётся выбросить, написать новый. Чем тесты хуже кода, они священно-коровны?
I>Ничем. Требований почти нет да и те меняются постоянно. Отсюда ясно, что автотесты нужны только для устоявшегося функционала.
Автотесты в первую очередь для кода. А там уж всё просто — код устоявшийся, тесты устоявшиеся. Код не устаявшийся, тесты не устоявшиеся.

I>>>На самом деле не всем — челы вроде тебя будут до посинения защищать свои тесты: "не трогайте, не надо, придумайте другой выход, я писал тесты два года и восемь месяцев и только-толко начал подходить к концу"
I>·>Так у вас code ownership? Отучайтесь. Тогда понятия "мои тесты" не будет. Тест это инструмент разработки, а не средство самовыражения.
I>У нас нет овнершипа кода, твоя телепатия не работает.
А как тогда получается, что один чел пишет код два года и восемь месяцев?

I>·>Да ещё и тесты пишете постфактум.
I>Твоя телепатия снова не работает.
Вывод по высказываниям выше, а не телепатия.

I>·>Используете самые корявые практики, не удивительно, что так всё плохо.
I>И здесь твоя телепатия не работает.
Неужели удивительно?


I>>>Ты так и не показал тест, который находит неучтенный кейс.
I>·>А я и не обещал.
I>Ты зато постоянно повторяешь "автотестами это легко"
Показывать ничего не обещал. Да и ты конкретно не написал что ты хочешь увидеть. А "покажи то, не знаю что", я, конечно, не смогу.

I>>>И это отстой, потому что кастомер как правило хочет увидеть результат сразу. Старые тесты никому не нужны. А результат нужен сразу, что бы решить, продлжать или не продолжать.
I>·>Как он может увидеть сразу, если новую форму надо делать, скажем, два месяца?
I>Если не делать из тестов священную корову, то все получается, хоть каждый день показывай.
И причём тут тесты?

I>>>А уже потом — новые тесты.
I>·>Ещё раз. Тесты пишутся одновременно с кодом.
I>Это только когда требования наперёд известны. Когда такого нет, можно использовать только юнит-тесты и то не для любого кода.
Не только. Только когда желание есть.

I>>>"Да, пожалуйста" — а чуть раньше ты сказал "а давайте не будем менять вот так вот радикально".
I>·>И? Выбрасываем старое, только когда новое полностью готово. Эволюция, а не революция.
I>Это не эволюция, это стояние на месте. UI нужен только тогда, когда им ктото пользуется. Новая версия означает, что старый UI больше не нужен. Потому делается по быстрому затычка, что бы QA могли тестировать новые возможности приложения, а уже потом затычка меняется на полноценный UI.
Воот.. Опять специально всё мануалите. Возможности приложения можно и без UI тестировать.

I>>>Элементарно. json подходит по схеме, но не подходит по содержанию. Вот и всё. Теперь смотрим, что ушло на сервер и что пришло. Если клиент А отослал валидные данные,а сервер клиенту Б дал невалидные — проблема в сервере. и тд.
I>>>Вот так работают тестировщики.
I>·>А как же формальные модели?
I>Формальные модели для разработчиков. И вообще, я про клиент, а не сервер. Ты уже который раз хочешь словить меня на том, что апи сервера тестируется руками.
Я ловлю на том, что ты говоришь "проблема в сервере". У которого UI-то никакого нет, но тестируете руками.

>>>Это просто один из возможных случаев. Есть вагон таких же. Например, операционая система решит удалить временные файлы и тд и тд.
I>·>Опять пошли какие-то неизвестные артефакты. Возможных случаев не так много.
I>Это норма. В твоём случае ты проблему качества переложил на админов CI.
"неизвестные артефакты" это не норма. Это отсутствие опыта или невежество.

I>>>Я привел пример для веб. Селениум так селениум. Покажи на этом селениуме как найти автотестами пропущенный девелопером кейс.
I>·>А автотесты кем написаны? Надеюсь, что тестером, который по кейсам нарисовал автотесты.
I>Правильно, по спеке. Только я уже говорил — спека кривая донельзя и в ней только правильный путь юзера. Это у вас область, где спекой можно всё закрыть. Представь, в других областях может быть иначе.
Так пусть тестер напишет тесты какие он считает нужно проверить и какие бы он проверил, если бы тестировал вручную.

Здравствуйте, ·, Вы писали:

I>>>>Может. Нет противоречия. _Типичный_ exploratory это ручной. Из этого не следует, что все exploratory исключительно ручные.
·>"новые баги ищутся только руками" == "exploratory исключительно ручные". Разве нет?

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

I>>Есть другой факт — ты пока еще ни раз не привел даже описание, как автотесты могут найти новый баг.
·>Ровно так же как и ручные, только вместо мыши используешь код.

Идея очень плохая — искать баги кодом. В типичном UI проекте слишком часто баги не воспроизводятся как было описано.
Кликая мышом можно за пару минут сотню непредусмотреных кейсов прощелкать. Это практически мгновенный результат. В автотестами тебе нужен разгон с понедельника.

I>>Неверно, QA не обязан следовать жостким процедурам. В UI зачастую QA говорит "приемлемо" и всё.
·>Результатом следования жестким процедурам будет абсолютоно жесткий код авто-теста. Который абсолютно жестко должен проходить.

И потому такие тесты не нужны, потому что, как я говорил, 90% UI это или 3rd party и никакого контроля, или другой уровень пермишнов и снова никакого контроля.

I>>Авто-тесты покрывают исключительно устоявшийся функционал.
·>Типичное заблуждение.

Пока ты будешь писать тест "открыть приложение-закрыть приложение" UI может сменить не только морду, но и движок

I>>Ты пока еще не привел, как же кодом найти новый баг.
·>Привёл. Что-то там про списки айтемов в меню было. Если ещё непонятно, представь себе как бы ты что-то делал вручную и предположи, что все эти шаги можно сделать не мышой, а кусочком кода.

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

I>>Правильно — глазам я доверяю, а твоим тестам — нет. Визуально — всё в порядке. А вот тесты красные.
·>Потому что у вас тесты плохого качества, какой-то один чувак два года и восемь месяцев ваяет, всем остальным плевать, все тупо кодят. Мы тестам доверяем.

Потому что у вас UI по факту сильно второстепенная вещь. Пудозреваю, на него уходит от силы 1-2% бюджета. Потому и можно придумать сколь угодно неэффектинвный процесс, всё равно на сроки не повлияет.

I>>И это не UX. Это ты коряво написал и тесты, и функциональность.
·>А конкретно? Или ты опять про общий случай? Вы там капчи пишете или тестопригодный код?

Объясняю в последний раз, баги нужно квалифицировать не по причине происхождения, а по степени влияния на юзера

1. юзер совершает невынужденные ошибки — зевки, усталость
2. функционал недоступен
3. юзер совершает вынужденные ошибки, например результаты некорректные и юзер принимает неверные решения
4. юзеру причиняется прямой или косвенный ущерб

Теперь самое страшное — п.1..3 могут быть результатом одного единственного некорректного CSS стиля. А у тебя все ошибки из за css это UX.

I>>А ты попробуй перечитай. Если ручный — обязательные, то релиз с автоматическими без ручных состоится или нет ?
·>У нас во время релиза ручное тестирование не применяется.

Не гони, в качестве ручных тестеров у вас бетатестеры и эксперты со стороны заказчика.

I>>И в яндексе такого нет, не сочиняй.
·>Как я понял, они сказали, что одной из причиной факапа было отстранение ручных тестеров, т.к. была спешка. Я неправильно понял?

Ну так автотесты это совсем необязательно те фокусы, которые вы у себя изобрёли

I>>Как часто ты сможешь проделывать эти фокусы ?
·>Ровно так же как и любой другой код. В чём разница-то?

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


I>>В UI будет скорее "юзер должен иметь возможность работать с персональными данными и что бы эти данные никто кроме него не видел"
·>А почему именно так? В чём принципиальная разница?

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

I>>"метод А коллбека будет вызван..." — поведение
I>>"из метода run вызовем колбек метод А" — сравни разницу. Если ктото перенесет вызов колбека наверх, скажем после вызова run или перед вызовом, то поведение не изменится, а твой тест — упадёт, потому что мок будет ожидать вызова из метода run.
·>В смысле поменяется юнит? Да, конечно, тогда юнит-тест должен упасть. Ибо этим юнитом могут пользоваться другие участки кода и ожидать вызов коллбека.

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

I>>Если код простой для значительной части команды, значит команда занимается делом ниже своей квалификации, т.е. "художник работает маляром".
·>Система — сложная, код — простой. Код должен быть простым, иначе это плохой код. Писать сложно — просто, писать просто — сложно.

А откуда сложность в системе если её код простой ?

I>>а ты поинтересуйся, как это реализуется в селениуме.
·>Я знаю. Проверкой стилей. Никаких "неизвестных артифактов". Я понимаю, что можно наворотить кода, который обманет селениум. Но тут всё просто — не надо так делать.

Ценность таких советов уже давно ниже нуля.

I>>Селениум детектит только кое какие свойства. Он не может сказать "форм выглядит не так, как должна".
·>Ты уж реши, вначале "ФУНКЦИОНАЛ", а потом вдруг "выглядит". Ты уж определись.

Я везде говорю про юзера, а ты смотришь со стороны реализации. Если ты ошибся в вычислении и показал баланс счета 10000 вмест 1.0, или накорябал кривые стили и у тебя сдвинулся контент и юзер видит 10000 вместо 1.0, это ровно одна и та же ошибка и называется "некорректный баланс". Последствия одинаковы — юзер примет неверное решение.
Здесь нет двух случаев, UX и функционал, здесь ровно один баг — "некорректный баланс".

I>>У тебя все неудобное это UX.
·>

The User Experience is everything that happens to your users when they interact with your business or organisation via your website, application or online communications. It includes everything they see, hear and do as well as their emotional reactions.

·>Если неудобно|неприятно это считается "ФУНКЦИОНАЛ НЕ РАБОТАЕТ", а не эмоциональные реакции, то я сдаюсь. Считай, что я слил.

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


I>>Легко. Движок кривой. Покажи тест.
·>Самый простой вариант. Как часто меняется стартовый скрин? Раз в месяц? Сделай снапшот и сравнивай (возможно частично). Когда кто-то будет опять менять стартовый скрин — сделает скриншот опять, займёт 1 минуту.
·>Или у тебя там опять проблемы с 3rd party, owner-draw, win32?

С такими вещами буквально весной возился около месяца. Смысла нет фиксить кроме как перед релизом.

I>>Ты мне расскажи, что это за тест будет. Я ведь именно этот вопрос и задаю.
·>Так вроде ты о регрессии говоришь. или данный случай не "В ОСНОВНОМ"?

Я вот без понятия, как это качественно задетектить. Видео что ли записывать и анализировать ?

·>Для exploratory testing можно варьировать код, поставить точки останова, етс, скажем, что будет если попытаться установить неподдерживаемый язык?

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

I>>Это легко — астрономическое число тестов, а лучше даже бесконечное, решит эту проблему.
·>Не бОльшее чем ручных.

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

I>>Я говорю исключительно про клиентские проблемы, а тебе мерещится сервер.
·>Ты сказал, что UI-тест выявил что сервер возвращает неверный ответ.
·>Ты сказал, что для контроля диска вы визуализируете счётчики, чтобы юзеры могли проверять во время ручных тестов.
·>Что мне померещилось?

Практически всё. Тесты на сервере не гарантируют отсутствие ошибок. Как выяснить, кто из игроков в цепочке ошибся — исходный клиент, сервер или конечный клиент ? На сервер ушли корректные данные — исходный клиент в порядке, на его команду никаких багов не ассайним. На конечный клиент ушел некорректный ответ — виноват сервер, тикет ассайнится на сервер. Вот примерно так.
Самое интересно, баги такого сорта воспроизводятся с огромным трудом. Их даже тестеры повторить не всегда могут в разумное время.

I>>В зависимости от приложения. Иногда можно просто в файл писать напрямую. Иногда подключается готовый сервис на устройстве. И тд.
·>Ты только что жаловался, что это непредсказуемо влияет на тестируемый UI...

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

I>>В самом деле, одной транзакцией откусить 20% всей памяти на девайсе или 40-60 от свободной на том же девайсе.
·>Опять общий случай рассматриваешь, или на свою жизнь жалуешься. У меня 24GB оперативы, на серверах в несколько раз больше. Так что сильно меньше 20%

Тесты в идеальных условиях показывают, что апликачка может работать в идеальных условиях.
Тестировать нужно там же, где и работать у юзера. Вот есть ipad air 2 — там всего 2гб памяти. Типичный виндовый ноутбук — 4-8гб да без SSD.

I>>В самом деле, откуда своп ? А представь, фрейм надо рисовать не менее 10-20 раз в секунду и собирать его из 5-10 битмапин того же разрешения ?
·>А если представить, что не надо?

Я тебе вполне реальный кейс привел. Если не надо, то твоё конское разрешение вообще ни о чем, ты будешь тестировать операционную систему, а не софтину. Если она не умеет твоё разрешение, то всё, приехали.

I>>в 32х разрядах даже в десять раз меньшие цифры дают OutOfMemory, а 64 бита — жесточайший своп.
·>А может быть и нет. Не суди других по себе.

Вообще то это факты. Только в вырожденных условиях у тебя может получиться чтото навроде 1 к 1 коммит.

I>>Для UI винды и андроида это более чем сверхестественное. Ты в курсе, что оптимизациями не только ты занимаешься ?
·>А я что-то об андроиде говорил?

Не важно. Твои цифры касательно UI это экзотика для любой OS.

I>>обычный exploratory. Если ты не в курсе, для этих тестов нет заранее заготовленой последвательности.
·>Ну вот. Замени теперь мышь на код — будет теперь и компьютер уметь.

И каким образом комп будет выдавать сотню уникальных тестов каждые несколько часов ? Максимум — одну рандомизированую "кликнем сюда, в другой раз туда, в третий раз пропустим клик" и тд.
Это совсем не то, чего можно добиться с помощью живого юзера.

Кроме того, в UI практически норма ловить кейсы, которые сами же тестеры плохо воспроизводят.

I>>У нас нет овнершипа кода, твоя телепатия не работает.
·>А как тогда получается, что один чел пишет код два года и восемь месяцев?

Это я смоделировал твой случай Шоб тебе понятнее было.

I>>·>Используете самые корявые практики, не удивительно, что так всё плохо.
I>>И здесь твоя телепатия не работает.
·>Неужели удивительно?

Нет, а что, телепатия должна работать ?

I>>Ты зато постоянно повторяешь "автотестами это легко"
·>Показывать ничего не обещал. Да и ты конкретно не написал что ты хочешь увидеть. А "покажи то, не знаю что", я, конечно, не смогу.

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

I>>·>Как он может увидеть сразу, если новую форму надо делать, скажем, два месяца?
I>>Если не делать из тестов священную корову, то все получается, хоть каждый день показывай.
·>И причём тут тесты?

Тесты это сбор информации, требуют времени и денег. Отдаляют представление о результате.

I>>Это только когда требования наперёд известны. Когда такого нет, можно использовать только юнит-тесты и то не для любого кода.
·>Не только. Только когда желание есть.

Когда желание есть то и 300 вёрст за водкой не крюк.

·>Воот.. Опять специально всё мануалите. Возможности приложения можно и без UI тестировать.

UI — в обязательном порядке вручную, остальное — по возможности. Есть возможность покрыть — QA покрывает автотестами. Нет возможности — не покрывают, им виднее.

I>>Формальные модели для разработчиков. И вообще, я про клиент, а не сервер. Ты уже который раз хочешь словить меня на том, что апи сервера тестируется руками.
·>Я ловлю на том, что ты говоришь "проблема в сервере". У которого UI-то никакого нет, но тестируете руками.

Ошибки на клиенте часто являются следствием проблем на сервере. Тестер обязан внятно обозначить подсистему — какой из клиентов, какой из серверов и тд и тд.

I>>Это норма. В твоём случае ты проблему качества переложил на админов CI.
·>"неизвестные артефакты" это не норма. Это отсутствие опыта или невежество.

Ты снова хочешь сказать, что у вас 100% покрытие автотестами и гарантия отсутствия багов

I>>Правильно, по спеке. Только я уже говорил — спека кривая донельзя и в ней только правильный путь юзера. Это у вас область, где спекой можно всё закрыть. Представь, в других областях может быть иначе.
·>Так пусть тестер напишет тесты какие он считает нужно проверить и какие бы он проверил, если бы тестировал вручную.

Во первых, такое изобрели и без тебя лет наверное 15 назад
Во вторых, не все ошибочные кейсы легко воспроизвести
В третьих, если продолжить, ты снова начнешь намекать что у вас всё классно и есть гарантия отсутствия багов

И самое важное — "пусть тестер напишет тесты какие он считает нужно" — эта формула исключает exploratory, принципиально.
Можешь заранее описать тест == scripted тест и никак не exploratory.

Здравствуйте, ·, Вы писали:

>А что нибудь конкретное? Относящееся к сабжу?
Это конкретно и напрямую относится к "сабжу".

>А почему ты решил, что этого будет достаточно?
Потому что практика и здравый смысл.

>Примеры были всё не в тему.
примеры были как раз весьма в тему, но я не виноват, что они вам не нравятся.

>Не надо выдирать фразы. "Всё" в контексте, а не "всё" вообще.
Друг мой, вы задолбали отпираться от своих же слов. Сначала вы же сами написали "все", потом наехали на меня за это "все", а когда я ткнул вас в это носом, оказалось, что это "все" выдрано из контекста. У вас блестяще получается спорить самому с собой, поэтому у меня нет никакого желания принимать в этом участие.

>Т.е. если как только QA принимает решение, так сразу качество продукта становится приемлимым?
Нет. QA лишь фиксирует состояние продукта.

> В сабже — тоже кто-то решение принял. И что? Приемлимости это не добавило.
Если вы почитаете внимательно, что в Яндексе решение о качестве принял не QA, а менеджмент.

>Ещё раз. Мне плевать на общий случай, я рассматриваю инженерную проблему, а не философскую.
Вы рассматриваете инженерную проблему через замочную скважину, подсвечивая себе лазерной указкой.

> Я рассматриваю вполне конкретную ситуацию — сабж.
И в этом "сабже" вы видете только ту часть проблемы, которую умеете решать, а потом делаете вид, что на этом проблема исчерпана. "когда в руках молоток, то все остальное кажется гвоздями" (с)

> Общий случай это то, что мне тут пытаются навязать. Общие случаи — не ко мне, пожалуйста.
Тогда что вы тут делаете? Конкретно с яндексом все просто как рельс — при нормально поставленном процессе разработки, дело бы даже не дошло до тестов, и не о чем было бы разговаривать.

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

>Попытка чего?
Попытка отмазаться от своих же слов.

Здравствуйте, IB, Вы писали:

>>А что нибудь конкретное? Относящееся к сабжу?
IB>Это конкретно и напрямую относится к "сабжу".
UI — не относится. А больше ничего и не было.

>>А почему ты решил, что этого будет достаточно?
IB>Потому что практика и здравый смысл.
У каждого разная практика и понимание здравости смысла. Короче, так и говори "тебе так кажется", "мамой клянусь".

>>Не надо выдирать фразы. "Всё" в контексте, а не "всё" вообще.
IB>Друг мой, вы задолбали отпираться от своих же слов. Сначала вы же сами написали "все", потом наехали на меня за это "все", а когда я ткнул вас в это носом, оказалось, что это "все" выдрано из контекста. У вас блестяще получается спорить самому с собой, поэтому у меня нет никакого желания принимать в этом участие.
Я сказал, что если есть спека, и по ней аккуратно сделать авто-тесты, то будет проверяться всё что есть в спеке, с минимальной вероятностью сабжа. Что помещается в спеку — это основные требования, т.е. бизнес-критические. Ты говоришь, что всё не будет проверяться. Ну да. Логично, я и не обещал "всё вообще", а только то что решено бизнесом, как критические требования. В чём я отпираюсь? Или ты считаешь, что работать на девайсе клиента пару часов — не критическое требование?

>>Т.е. если как только QA принимает решение, так сразу качество продукта становится приемлимым?
IB>Нет. QA лишь фиксирует состояние продукта.
На основании чего?

>> В сабже — тоже кто-то решение принял. И что? Приемлимости это не добавило.
IB>Если вы почитаете внимательно, что в Яндексе решение о качестве принял не QA, а менеджмент.
Роль QA это богом данная привилегия? Если её станет выполнять другой, то что-то должно поломаться? Почему "QA Вася" может принять решение и качество продукта станет хорошим, а если решение принимает "ВРИО QA глубокоуважаемый Григорий Петрович", то уже не сработает?

>> Я рассматриваю вполне конкретную ситуацию — сабж.
IB>И в этом "сабже" вы видете только ту часть проблемы, которую умеете решать, а потом делаете вид, что на этом проблема исчерпана. "когда в руках молоток, то все остальное кажется гвоздями" (с)
Я не делаю вид, что проблема тестирования всего исчерпана. Я предложил решение конкретной проблемы — утечка ресурсов. Меня раскритиковали, но ничего конретного никто не предложил, "нужен комплексный подход", "грамотно выстроить весь цикл" — это не решения, а термины из буллшит-бинго, речь не инженера, а менеджера на пятичасовом митигне, такое можно говорить на любую тему.
Q: Как запустить марсоход?
A: Нужен комплексный подход, грамотно выстроить весь цикл.
Q: Как заработать миллион долларов за неделю?
A: Нужен комплексный подход, грамотно выстроить весь цикл.

>> Общий случай это то, что мне тут пытаются навязать. Общие случаи — не ко мне, пожалуйста.
IB>Тогда что вы тут делаете? Конкретно с яндексом все просто как рельс — при нормально поставленном процессе разработки, дело бы даже не дошло до тестов, и не о чем было бы разговаривать.
Так что конкретно у них ненормально?

>>Интересно разобраться почему.
IB>Там нечего разбираться, и так все понятно. Такого рода продукты автотестами в принципе не покроешь, что забавно, у нас таких большинство... Поэтому рассуждения о том, что достаточно настроить автотесты и такой-то класс проблем уйдет — смотрятся весьма наивно.
"Такого рода продукты автотестами в принципе не покроешь" — звучит по-ламерски. Зачем думать, прыгать надо, ведь даже с длинной лестницей не любой банан достанешь.

Здравствуйте, Ikemefula, Вы писали:

I>>>>>Может. Нет противоречия. _Типичный_ exploratory это ручной. Из этого не следует, что все exploratory исключительно ручные.
I>·>"новые баги ищутся только руками" == "exploratory исключительно ручные". Разве нет?
I>И да, и нет. Тестеру нужно сто раз кликнуть, что бы найти новый ошибочный кейс. Тебе придется на те же сто кликов написать сто тестов, скомпилить, отладить, отдать на ci и после прогона узнаешь, что один тест нашел ошибку, а может и не нашел.
I>Следующий раз тестер сделает еще сто кликов, непохожих на предыдущие, а тебе снова придется повторять эпопею с билдами.
Ты исходишь из неверного предположения. Авто-тесты — обычный код. Можно запускать локально, из IDE, подключаться отладчиком, етс. Коммитить и отдавать на CI нужно только что-то ценное, а не локальные эксперименты.

I>>>Есть другой факт — ты пока еще ни раз не привел даже описание, как автотесты могут найти новый баг.
I>·>Ровно так же как и ручные, только вместо мыши используешь код.
I>Идея очень плохая — искать баги кодом. В типичном UI проекте слишком часто баги не воспроизводятся как было описано.
I>Кликая мышом можно за пару минут сотню непредусмотреных кейсов прощелкать. Это практически мгновенный результат. В автотестами тебе нужен разгон с понедельника.
У тебя какие-то странные автотесты. То они запускаются только на CI, то они пишутся два года и восемь месяцев одним человеком, то они ВНЕЗАПНО падают пачками... В общем да, в таком случае уж лучше их вообще не использовать, с таким качеством лучше вообще код не писать, а отдать квалифицированной компании.

I>>>Неверно, QA не обязан следовать жостким процедурам. В UI зачастую QA говорит "приемлемо" и всё.
I>·>Результатом следования жестким процедурам будет абсолютоно жесткий код авто-теста. Который абсолютно жестко должен проходить.
I>И потому такие тесты не нужны, потому что, как я говорил, 90% UI это или 3rd party и никакого контроля, или другой уровень пермишнов и снова никакого контроля.
Так надо писать контролируемый код.

I>>>Авто-тесты покрывают исключительно устоявшийся функционал.
I>·>Типичное заблуждение.
I>Пока ты будешь писать тест "открыть приложение-закрыть приложение" UI может сменить не только морду, но и движок
Просто "тест" не пишется. Пишется авто-тестируемый код.

I>>>Ты пока еще не привел, как же кодом найти новый баг.
I>·>Привёл. Что-то там про списки айтемов в меню было. Если ещё непонятно, представь себе как бы ты что-то делал вручную и предположи, что все эти шаги можно сделать не мышой, а кусочком кода.
I>Не знаю, у меня каждый раз новые последовательности, уникальные и неповторимые.
Так пиши новые кусочки кода, уникальные и неповторимые.

I>>>Правильно — глазам я доверяю, а твоим тестам — нет. Визуально — всё в порядке. А вот тесты красные.
I>·>Потому что у вас тесты плохого качества, какой-то один чувак два года и восемь месяцев ваяет, всем остальным плевать, все тупо кодят. Мы тестам доверяем.
I>Потому что у вас UI по факту сильно второстепенная вещь. Пудозреваю, на него уходит от силы 1-2% бюджета. Потому и можно придумать сколь угодно неэффектинвный процесс, всё равно на сроки не повлияет.
Скорее у нас немного другая ситуация. Тестировать UI отдельно от API у нас практически невозможно. Поэтому у нас только два выхода — автоматизировать тестирование UI или мануализировать тестирование API. Первое — эффективнее (как минимум — в большом проекте). Вы, как я понял, идёте по второму пути.

I>>>И это не UX. Это ты коряво написал и тесты, и функциональность.
I>·>А конкретно? Или ты опять про общий случай? Вы там капчи пишете или тестопригодный код?
I>Объясняю в последний раз, баги нужно квалифицировать не по причине происхождения, а по степени влияния на юзера
Причём тут баги вообще. Если вы пишете такой код, что он плохо поддаётся тестированию — это не авто-тесты плохие, это код плохой. Зачем использовать вычурные css-конструкции, которые потом никак не протестировать? Если изначально ставить вопрос "вот мы делаем так, а как мы это протестировать сможем?", то уродцы типа css content: "your balance is £42" в принципе рождаться не будут.

I>1. юзер совершает невынужденные ошибки — зевки, усталость
I>2. функционал недоступен
I>3. юзер совершает вынужденные ошибки, например результаты некорректные и юзер принимает неверные решения
I>4. юзеру причиняется прямой или косвенный ущерб

I>Теперь самое страшное — п.1..3 могут быть результатом одного единственного некорректного CSS стиля. А у тебя все ошибки из за css это UX.
Да, бывает. Тут выход один — набираемся опыта и используем CSS осторожно.

I>>>А ты попробуй перечитай. Если ручный — обязательные, то релиз с автоматическими без ручных состоится или нет ?
I>·>У нас во время релиза ручное тестирование не применяется.
I>Не гони, в качестве ручных тестеров у вас бетатестеры и эксперты со стороны заказчика.
Не во время релиза, а во время разработки фичи.

I>>>И в яндексе такого нет, не сочиняй.
I>·>Как я понял, они сказали, что одной из причиной факапа было отстранение ручных тестеров, т.к. была спешка. Я неправильно понял?
I>Ну так автотесты это совсем необязательно те фокусы, которые вы у себя изобрёли
Не понял возражение. Причём тут автотесты?
Ты написал, "В реальных ситуациях ручное применяется в обязательном порядке. ... Никто и никогда, кроме отмороженых на всю голову индусо-контор.". Судя по статье, "причиной факапа было отстранение ручных тестеров".
Делаем нехитрый вывод: Яндекс — отмороженная на всю голову индусо-контора. Что не так?

I>>>Как часто ты сможешь проделывать эти фокусы ?
I>·>Ровно так же как и любой другой код. В чём разница-то?
I>В стоимости разработки. Эксплоратори тесты это огромное количество уникальных кейсов с мгновенными результатами.
I>Твои автотесты требуют майнтенанса, написания, отладки, билдования, инфраструктуры и тд и тд.
I>Более того — уникальными они будут только на первом прогоне, а на надо — на каждом
Ручные тесты требуют не меньше.

I>>>В UI будет скорее "юзер должен иметь возможность работать с персональными данными и что бы эти данные никто кроме него не видел"
I>·>А почему именно так? В чём принципиальная разница?
I>Вот бы узнать. В UI, особенно в энтерпрайзе, большей части приходят задачи навроде "сходи туда не знаю куда принеси то не знаю что" или "давайте попробуем а там будет видно" или "войны не объявлять мира не подписывать армию распустить".
I>Покрыват тестами имеет смысл только когда функционал устаканился или же требования четкие и простые.
Но код же как-то ты умудряешься писать? Раз можешь написать код, то и тест тоже возможно, т.к. это тоже код. (Мы не говорим о проектах-прототипах, надеюсь?).

I>>>"метод А коллбека будет вызван..." — поведение
I>>>"из метода run вызовем колбек метод А" — сравни разницу. Если ктото перенесет вызов колбека наверх, скажем после вызова run или перед вызовом, то поведение не изменится, а твой тест — упадёт, потому что мок будет ожидать вызова из метода run.
I>·>В смысле поменяется юнит? Да, конечно, тогда юнит-тест должен упасть. Ибо этим юнитом могут пользоваться другие участки кода и ожидать вызов коллбека.
I>И это неверный дизайн, нарушена инкапсуляция, т.к. юниты кроме поведения обладают знаниями о том, какой метод чего вызывает.
Я не понял. Юнит перестал посылать коллбэк, значит поменялось поведение — код использующий этот юнит должен быть в курсе. Изменения.
Короче, давай код в студию, иначе я плохо понимаю что ты имеешь в виду.

I>>>Если код простой для значительной части команды, значит команда занимается делом ниже своей квалификации, т.е. "художник работает маляром".
I>·>Система — сложная, код — простой. Код должен быть простым, иначе это плохой код. Писать сложно — просто, писать просто — сложно.
I>А откуда сложность в системе если её код простой ?
Теорема Ферма — записывается элементарно. А вот доказательсто — хм...

I>>>Селениум детектит только кое какие свойства. Он не может сказать "форм выглядит не так, как должна".
I>·>Ты уж реши, вначале "ФУНКЦИОНАЛ", а потом вдруг "выглядит". Ты уж определись.
I>Я везде говорю про юзера, а ты смотришь со стороны реализации. Если ты ошибся в вычислении и показал баланс счета 10000 вмест 1.0, или накорябал кривые стили и у тебя сдвинулся контент и юзер видит 10000 вместо 1.0, это ровно одна и та же ошибка и называется "некорректный баланс". Последствия одинаковы — юзер примет неверное решение.
I>Здесь нет двух случаев, UX и функционал, здесь ровно один баг — "некорректный баланс".
Можно более менее реальный пример, когда вдруг из-за css 1.0 нарисовалось как 10000?

I>·>

The User Experience is everything that happens to your users when they interact with your business or organisation via your website, application or online communications. It includes everything they see, hear and do as well as their emotional reactions.
I>·>

I>·>Если неудобно|неприятно это считается "ФУНКЦИОНАЛ НЕ РАБОТАЕТ", а не эмоциональные реакции, то я сдаюсь. Считай, что я слил.
I>В цитате — вообще вся интерактивность, все что юзер видит, слышит, делает, включая эмоциональные реакции.
I>Скажем, если тебе нужно срочно вызвать скорую а диал-пад потерял стили и копки теперь вразнобой, сильно вряд ли ты согласишься, что баг минорный
Опять ядерный реактор™.

I>>>Легко. Движок кривой. Покажи тест.
I>·>Самый простой вариант. Как часто меняется стартовый скрин? Раз в месяц? Сделай снапшот и сравнивай (возможно частично). Когда кто-то будет опять менять стартовый скрин — сделает скриншот опять, займёт 1 минуту.
I>·>Или у тебя там опять проблемы с 3rd party, owner-draw, win32?
I>С такими вещами буквально весной возился около месяца. Смысла нет фиксить кроме как перед релизом.
"Смысла нет фиксить кроме как перед релизом." в копилку.

I>>>Ты мне расскажи, что это за тест будет. Я ведь именно этот вопрос и задаю.
I>·>Так вроде ты о регрессии говоришь. или данный случай не "В ОСНОВНОМ"?
I>Я вот без понятия, как это качественно задетектить. Видео что ли записывать и анализировать ?
Попробуй. Начни просто со скриншота, с нечётким сравнением например. Отличить "чёрный экран" от "образец формы" — легко.

I>·>Для exploratory testing можно варьировать код, поставить точки останова, етс, скажем, что будет если попытаться установить неподдерживаемый язык?
I>Качественные эксплорейшн тесты это не просто варьировать, это постоянно новые уникальные кейсы. Не просто набор "сто рандомизированых модификаций базового теста" а именно уникальных кейсов.
Это код. Или ты хочешь сказать, что любой код это сто рандомизированных модификаций hello world?

I>>>Это легко — астрономическое число тестов, а лучше даже бесконечное, решит эту проблему.
I>·>Не бОльшее чем ручных.
I>С ручными все просто — тестеру ничего не стоит за 5 минут выдумать и получить результаты по десятку и даже сотне последовательностей. И так каждый раз. А у тебя шансов совсем мало -кодить, кодить, кодить
С кодом я могу за 5 минут написать выполненить миллионы последовательностей. Сотня последовательностей за 5 минут — нереально. 3 секунды на последовательность? Не верю.

I>>>Я говорю исключительно про клиентские проблемы, а тебе мерещится сервер.
I>·>Ты сказал, что UI-тест выявил что сервер возвращает неверный ответ.
I>·>Ты сказал, что для контроля диска вы визуализируете счётчики, чтобы юзеры могли проверять во время ручных тестов.
I>·>Что мне померещилось?
I>Практически всё. Тесты на сервере не гарантируют отсутствие ошибок. Как выяснить, кто из игроков в цепочке ошибся — исходный клиент, сервер или конечный клиент ? На сервер ушли корректные данные — исходный клиент в порядке, на его команду никаких багов не ассайним. На конечный клиент ушел некорректный ответ — виноват сервер, тикет ассайнится на сервер. Вот примерно так.
I>Самое интересно, баги такого сорта воспроизводятся с огромным трудом. Их даже тестеры повторить не всегда могут в разумное время.
Баг-то где фиксили? Если на клиенте, значит просто неправильно ассайн сделали.

I>>>В зависимости от приложения. Иногда можно просто в файл писать напрямую. Иногда подключается готовый сервис на устройстве. И тд.
I>·>Ты только что жаловался, что это непредсказуемо влияет на тестируемый UI...
I>Может влиять. Вот совсем недавно — работало год и вдруг вылез кейс, что в одном из случаев устройство дохнет. Оказалось из за ротации логов.
Раз в год — можно и потерпеть. Это не повод отказываться от авто-тестов.

I>>>В самом деле, одной транзакцией откусить 20% всей памяти на девайсе или 40-60 от свободной на том же девайсе.
I>·>Опять общий случай рассматриваешь, или на свою жизнь жалуешься. У меня 24GB оперативы, на серверах в несколько раз больше. Так что сильно меньше 20%
I> Тесты в идеальных условиях показывают, что апликачка может работать в идеальных условиях.
I>Тестировать нужно там же, где и работать у юзера. Вот есть ipad air 2 — там всего 2гб памяти. Типичный виндовый ноутбук — 4-8гб да без SSD.
Я тебя сразу спросил "не мобильные ли девайсы". Нет чтоб сразу сказать "да", споришь чего-то.

I>>>В самом деле, откуда своп ? А представь, фрейм надо рисовать не менее 10-20 раз в секунду и собирать его из 5-10 битмапин того же разрешения ?
I>·>А если представить, что не надо?
I>Я тебе вполне реальный кейс привел. Если не надо, то твоё конское разрешение вообще ни о чем, ты будешь тестировать операционную систему, а не софтину. Если она не умеет твоё разрешение, то всё, приехали.
Бывает и софтину тоже — можно тестировать переполнение, например.

I>>>в 32х разрядах даже в десять раз меньшие цифры дают OutOfMemory, а 64 бита — жесточайший своп.
I>·>А может быть и нет. Не суди других по себе.
I>Вообще то это факты. Только в вырожденных условиях у тебя может получиться чтото навроде 1 к 1 коммит.
Для мобильных устройств? Да. У каждого свои "факты". Своп вообще можно отключать. Нафиг на серваке с 256GB памяти своп?

I>>>обычный exploratory. Если ты не в курсе, для этих тестов нет заранее заготовленой последвательности.
I>·>Ну вот. Замени теперь мышь на код — будет теперь и компьютер уметь.
I>И каким образом комп будет выдавать сотню уникальных тестов каждые несколько часов ? Максимум — одну рандомизированую "кликнем сюда, в другой раз туда, в третий раз пропустим клик" и тд.
I>Это совсем не то, чего можно добиться с помощью живого юзера.
Добиться можно не меньше, если живой юзер умеет писать код.

I>>>У нас нет овнершипа кода, твоя телепатия не работает.
I>·>А как тогда получается, что один чел пишет код два года и восемь месяцев?
I>Это я смоделировал твой случай Шоб тебе понятнее было.
Какой мой случай?

I>>>Ты зато постоянно повторяешь "автотестами это легко"
I>·>Показывать ничего не обещал. Да и ты конкретно не написал что ты хочешь увидеть. А "покажи то, не знаю что", я, конечно, не смогу.
I> В том то и дело. "покажи не знаю что" это норма в UI. Когда функционал устаканился, хорошо работают тесты для регрессии. Но это никак не отменяет ручных тестов.
I>Они принципиально дополняют друг друга, ибо находят принципиально разные ошибки. автотесты найдут регрессию, тестер найдет новые ранее неизвестные.
Регрессию находят тесты закоммиченные в репозиторий. А новые можно искать локально, создавая новые скрипты автотестов, коммитить — ценные.

I>>>·>Как он может увидеть сразу, если новую форму надо делать, скажем, два месяца?
I>>>Если не делать из тестов священную корову, то все получается, хоть каждый день показывай.
I>·>И причём тут тесты?
I>Тесты это сбор информации, требуют времени и денег. Отдаляют представление о результате.
Тесты по сути формальная спека требований. Процесс разработки и заключается чтобы неформальную спеку "войны не объявлять мира" выразить формальным языком.

I>·>Воот.. Опять специально всё мануалите. Возможности приложения можно и без UI тестировать.
I>UI — в обязательном порядке вручную, остальное — по возможности. Есть возможность покрыть — QA покрывает автотестами. Нет возможности — не покрывают, им виднее.
Главный вопрос, который должен быть поставлен "если нет возможности, что сделать чтобы возможность появилась".

I>>>Это норма. В твоём случае ты проблему качества переложил на админов CI.
I>·>"неизвестные артефакты" это не норма. Это отсутствие опыта или невежество.
I>Ты снова хочешь сказать, что у вас 100% покрытие автотестами и гарантия отсутствия багов
Нет, хочу сказать, что для нас "неизвестные артефакты" — большая проблема, с которой идёт постоянная борьба.

I>>>Правильно, по спеке. Только я уже говорил — спека кривая донельзя и в ней только правильный путь юзера. Это у вас область, где спекой можно всё закрыть. Представь, в других областях может быть иначе.
I>·>Так пусть тестер напишет тесты какие он считает нужно проверить и какие бы он проверил, если бы тестировал вручную.
I>Во первых, такое изобрели и без тебя лет наверное 15 назад
Я и не говорил, что это моё изобретение.

I>Во вторых, не все ошибочные кейсы легко воспроизвести
Если не легко — значит что-то неправильно. И с этим надо что-то делать.

I>В третьих, если продолжить, ты снова начнешь намекать что у вас всё классно и есть гарантия отсутствия багов

I>И самое важное — "пусть тестер напишет тесты какие он считает нужно" — эта формула исключает exploratory, принципиально.
I>Можешь заранее описать тест == scripted тест и никак не exploratory.
Процесс написания теста — и есть exploratory testing. Только результат не тикет в баг-трекере, а исполняемый код. Если "не легко", то тестер может поработать в паре с девом|бизнес-аналистом|етс до тех пор пока не станет легко.

Здравствуйте, ·, Вы писали:

I>>И да, и нет. Тестеру нужно сто раз кликнуть, что бы найти новый ошибочный кейс. Тебе придется на те же сто кликов написать сто тестов, скомпилить, отладить, отдать на ci и после прогона узнаешь, что один тест нашел ошибку, а может и не нашел.
I>>Следующий раз тестер сделает еще сто кликов, непохожих на предыдущие, а тебе снова придется повторять эпопею с билдами.
·>Ты исходишь из неверного предположения. Авто-тесты — обычный код. Можно запускать локально, из IDE, подключаться отладчиком, етс. Коммитить и отдавать на CI нужно только что-то ценное, а не локальные эксперименты.

Мы ведь про эксплоратори ? Один раз написал — сто раз будет проверять одно и то же. Опаньки ! А надо на каждом прогоне _новые_ кейсы.

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

Вот давай на 100$ — у вас куча тестеров/девелоперов регулярно пускает единичные тесты против энвайрмента, скажем, через JMeter или аналогичный тул. Опаньки ! Где мои 100$ ?

I>>Кликая мышом можно за пару минут сотню непредусмотреных кейсов прощелкать. Это практически мгновенный результат. В автотестами тебе нужен разгон с понедельника.
·>У тебя какие-то странные автотесты.

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

I>>И потому такие тесты не нужны, потому что, как я говорил, 90% UI это или 3rd party и никакого контроля, или другой уровень пермишнов и снова никакого контроля.
·>Так надо писать контролируемый код

Сообщи эту блестящую мысль вендорам OS, браузеров, библиотек, фремворков и тд.

I>>·>Типичное заблуждение.
I>>Пока ты будешь писать тест "открыть приложение-закрыть приложение" UI может сменить не только морду, но и движок
·>Просто "тест" не пишется. Пишется авто-тестируемый код.

Не надо слов — покажи это на примере эксплоратори теста.

I>>Не знаю, у меня каждый раз новые последовательности, уникальные и неповторимые.
·>Так пиши новые кусочки кода, уникальные и неповторимые.

Твои кусочки кода уникальны до первого прогона. Дальше они уже никакие не уникальные. А надо что бы КАЖДЫЙ прогон был из уникальных.

I>>Потому что у вас UI по факту сильно второстепенная вещь. Пудозреваю, на него уходит от силы 1-2% бюджета. Потому и можно придумать сколь угодно неэффектинвный процесс, всё равно на сроки не повлияет.
·>Скорее у нас немного другая ситуация. Тестировать UI отдельно от API у нас практически невозможно. Поэтому у нас только два выхода — автоматизировать тестирование UI или мануализировать тестирование API. Первое — эффективнее (как минимум — в большом проекте). Вы, как я понял, идёте по второму пути.

Ты чего то себе фантазируешь. Я вроде как сказал противоположное — у нас есть и автоматизаторы, и мануальщики.
Они решают разные задачи. Мануальщики находят новые кейсы, автоматизаторы создают тесты для регрессии.
У вас UI примитивный, потому легко автоматизируется. Скорее всего ваш UI 1 в 1 отражает некоторые данные в базе.

I>>Объясняю в последний раз, баги нужно квалифицировать не по причине происхождения, а по степени влияния на юзера
·>Причём тут баги вообще. Если вы пишете такой код, что он плохо поддаётся тестированию — это не авто-тесты плохие, это код плохой.

Скучно, раз пять или шесть объяснил. Ну и твоя телепатия уже утомляет.

I>>Теперь самое страшное — п.1..3 могут быть результатом одного единственного некорректного CSS стиля. А у тебя все ошибки из за css это UX.
·>Да, бывает. Тут выход один — набираемся опыта и используем CSS осторожно.

Какие выходы — дело десятое. Важно, что важность бага не зависит от того, в CSS он, или в базе, или в логике.

I>>Не гони, в качестве ручных тестеров у вас бетатестеры и эксперты со стороны заказчика.
·>Не во время релиза, а во время разработки фичи.

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

I>>Ну так автотесты это совсем необязательно те фокусы, которые вы у себя изобрёли
·>Не понял возражение. Причём тут автотесты?
·>Ты написал, "В реальных ситуациях ручное применяется в обязательном порядке. ... Никто и никогда, кроме отмороженых на всю голову индусо-контор.". Судя по статье, "причиной факапа было отстранение ручных тестеров".
·>Делаем нехитрый вывод: Яндекс — отмороженная на всю голову индусо-контора. Что не так?

С третьего раза у тебя всё получилось.

I>>Твои автотесты требуют майнтенанса, написания, отладки, билдования, инфраструктуры и тд и тд.
I>>Более того — уникальными они будут только на первом прогоне, а на надо — на каждом
·>Ручные тесты требуют не меньше.

Не ври. Ручные не надо отлаживать, билдить, не нужен клауд для них и тд и тд.

I>>Покрыват тестами имеет смысл только когда функционал устаканился или же требования четкие и простые.
·>Но код же как-то ты умудряешься писать? Раз можешь написать код, то и тест тоже возможно, т.к. это тоже код. (Мы не говорим о проектах-прототипах, надеюсь?).

"возможно" — это никому не интересно. Экономику уже отменили ? Сочувствую. Тесты имеют стоимость. Одноразовые тесты на одноразовый код это деньги на ветер. В разработке UI очень много одноразовых вещей. Многие вещи рождаются и тут же дохнут.
Пудозреваю, у вас или примитивнейший UI, фактически маппинг БД на экран, или у тебя есть машина времени.

I>>И это неверный дизайн, нарушена инкапсуляция, т.к. юниты кроме поведения обладают знаниями о том, какой метод чего вызывает.
·>Я не понял. Юнит перестал посылать коллбэк, значит поменялось поведение — код использующий этот юнит должен быть в курсе. Изменения.

Юнит — не перестал. Перестал один из методов юнита — run.

·>Короче, давай код в студию, иначе я плохо понимаю что ты имеешь в виду.

Я уже дал весь необходимый код. Вот еще раз

x.run() // вызываем колбек унутре

стало

x.run();
x.callback();

Теперь ответь внятно — что делать с тестом метода run в котором ты присособил мок ?

I>>А откуда сложность в системе если её код простой ?
·>Теорема Ферма — записывается элементарно. А вот доказательсто — хм...

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

I>>Здесь нет двух случаев, UX и функционал, здесь ровно один баг — "некорректный баланс".
·>Можно более менее реальный пример, когда вдруг из-за css 1.0 нарисовалось как 10000?

Бесконечное количество вариантов — сдвиг контента, z-index, левый контрол, наложение и тд и тд и тд

I>>Скажем, если тебе нужно срочно вызвать скорую а диал-пад потерял стили и копки теперь вразнобой, сильно вряд ли ты согласишься, что баг минорный
·>Опять ядерный реактор™.

Где ты видишь реактор если речь про диал-пад ? У тебя в телефоне диалпада нет ? Сочувствую.

I>>С такими вещами буквально весной возился около месяца. Смысла нет фиксить кроме как перед релизом.
·>"Смысла нет фиксить кроме как перед релизом." в копилку.

Именно. Минорный приортитет именно так и фиксита. Хотя, в вашей конторе может и наоборот, сначала минорные, а уже если хватит времени, за блокеры берётесь.

I>>Я вот без понятия, как это качественно задетектить. Видео что ли записывать и анализировать ?
·>Попробуй. Начни просто со скриншота, с нечётким сравнением например. Отличить "чёрный экран" от "образец формы" — легко.

Да, я помню твои идеи — отключить все фичи, зафиксировать окружение, пару тысяч параметров что влияют на отрисовки и всё получится.
Ты уже сходит за Нобелевкой ?

I>>Качественные эксплорейшн тесты это не просто варьировать, это постоянно новые уникальные кейсы. Не просто набор "сто рандомизированых модификаций базового теста" а именно уникальных кейсов.
·>Это код. Или ты хочешь сказать, что любой код это сто рандомизированных модификаций hello world?

Любой, повторно вызываемый код это scripted. Любой scripted != exploratory.

I>>С ручными все просто — тестеру ничего не стоит за 5 минут выдумать и получить результаты по десятку и даже сотне последовательностей. И так каждый раз. А у тебя шансов совсем мало -кодить, кодить, кодить
·>С кодом я могу за 5 минут написать выполненить миллионы последовательностей. Сотня последовательностей за 5 минут — нереально. 3 секунды на последовательность? Не верю.

Хоть миллиарды. Повторный прогон будет обычным scripted.

I>>Практически всё. Тесты на сервере не гарантируют отсутствие ошибок. Как выяснить, кто из игроков в цепочке ошибся — исходный клиент, сервер или конечный клиент ? На сервер ушли корректные данные — исходный клиент в порядке, на его команду никаких багов не ассайним. На конечный клиент ушел некорректный ответ — виноват сервер, тикет ассайнится на сервер. Вот примерно так.
I>>Самое интересно, баги такого сорта воспроизводятся с огромным трудом. Их даже тестеры повторить не всегда могут в разумное время.
·>Баг-то где фиксили? Если на клиенте, значит просто неправильно ассайн сделали.

Нигде ничего не фиксили, а воспроизводится сильно по разному в одном и том же окружении. Это нормально. Почему это нормально, уже объяснил раз 5 или больше.

I>>Может влиять. Вот совсем недавно — работало год и вдруг вылез кейс, что в одном из случаев устройство дохнет. Оказалось из за ротации логов.
·>Раз в год — можно и потерпеть. Это не повод отказываться от авто-тестов.

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


I>>>>В самом деле, одной транзакцией откусить 20% всей памяти на девайсе или 40-60 от свободной на том же девайсе.
I>>·>Опять общий случай рассматриваешь, или на свою жизнь жалуешься. У меня 24GB оперативы, на серверах в несколько раз больше. Так что сильно меньше 20%
I>> Тесты в идеальных условиях показывают, что апликачка может работать в идеальных условиях.
I>>Тестировать нужно там же, где и работать у юзера. Вот есть ipad air 2 — там всего 2гб памяти. Типичный виндовый ноутбук — 4-8гб да без SSD.
·> Я тебя сразу спросил "не мобильные ли девайсы". Нет чтоб сразу сказать "да", споришь чего-то.

I>>>>В самом деле, откуда своп ? А представь, фрейм надо рисовать не менее 10-20 раз в секунду и собирать его из 5-10 битмапин того же разрешения ?
I>>·>А если представить, что не надо?
I>>Я тебе вполне реальный кейс привел. Если не надо, то твоё конское разрешение вообще ни о чем, ты будешь тестировать операционную систему, а не софтину. Если она не умеет твоё разрешение, то всё, приехали.
·>Бывает и софтину тоже — можно тестировать переполнение, например.

I>>>>в 32х разрядах даже в десять раз меньшие цифры дают OutOfMemory, а 64 бита — жесточайший своп.
I>>·>А может быть и нет. Не суди других по себе.
I>>Вообще то это факты. Только в вырожденных условиях у тебя может получиться чтото навроде 1 к 1 коммит.
·>Для мобильных устройств? Да. У каждого свои "факты". Своп вообще можно отключать. Нафиг на серваке с 256GB памяти своп?

I>>>>обычный exploratory. Если ты не в курсе, для этих тестов нет заранее заготовленой последвательности.
I>>·>Ну вот. Замени теперь мышь на код — будет теперь и компьютер уметь.
I>>И каким образом комп будет выдавать сотню уникальных тестов каждые несколько часов ? Максимум — одну рандомизированую "кликнем сюда, в другой раз туда, в третий раз пропустим клик" и тд.
I>>Это совсем не то, чего можно добиться с помощью живого юзера.
·>Добиться можно не меньше, если живой юзер умеет писать код.

I>>>>У нас нет овнершипа кода, твоя телепатия не работает.
I>>·>А как тогда получается, что один чел пишет код два года и восемь месяцев?
I>>Это я смоделировал твой случай Шоб тебе понятнее было.
·>Какой мой случай?

I>>>>Ты зато постоянно повторяешь "автотестами это легко"
I>>·>Показывать ничего не обещал. Да и ты конкретно не написал что ты хочешь увидеть. А "покажи то, не знаю что", я, конечно, не смогу.
I>> В том то и дело. "покажи не знаю что" это норма в UI. Когда функционал устаканился, хорошо работают тесты для регрессии. Но это никак не отменяет ручных тестов.
I>>Они принципиально дополняют друг друга, ибо находят принципиально разные ошибки. автотесты найдут регрессию, тестер найдет новые ранее неизвестные.
·>Регрессию находят тесты закоммиченные в репозиторий. А новые можно искать локально, создавая новые скрипты автотестов, коммитить — ценные.

I>>>>·>Как он может увидеть сразу, если новую форму надо делать, скажем, два месяца?
I>>>>Если не делать из тестов священную корову, то все получается, хоть каждый день показывай.
I>>·>И причём тут тесты?
I>>Тесты это сбор информации, требуют времени и денег. Отдаляют представление о результате.
·>Тесты по сути формальная спека требований. Процесс разработки и заключается чтобы неформальную спеку "войны не объявлять мира" выразить формальным языком.

Это примерно как "хорошее лучше плохого". На серверный АПИ как правило приходит четкое, однозначное описание — форматы, диаграмы, схемы данных, последовательность и тд.
Покрыть тестами проще простого.
Когда взаимодействуют разные системы, в т.ч. разнесенные между разными континентами-конторами, уже гораздо сложнее, ибо появляется целая куча неявных кейсов, недокументирвоаных особенностей и тд
А вот взаимодействие человек-компьютер вообще слабо поддаётся внятной формализации. Более того, требования мало того, что туманные, так и меняются _постоянно_.

I>>·>Воот.. Опять специально всё мануалите. Возможности приложения можно и без UI тестировать.
I>>UI — в обязательном порядке вручную, остальное — по возможности. Есть возможность покрыть — QA покрывает автотестами. Нет возможности — не покрывают, им виднее.
·>Главный вопрос, который должен быть поставлен "если нет возможности, что сделать чтобы возможность появилась".

Спасибо, капитан. Не знали, что ты подскажешь это в 2015, потому додумались сами, еще в самых нулевых.

I>>>>Это норма. В твоём случае ты проблему качества переложил на админов CI.
I>>·>"неизвестные артефакты" это не норма. Это отсутствие опыта или невежество.
I>>Ты снова хочешь сказать, что у вас 100% покрытие автотестами и гарантия отсутствия багов
·>Нет, хочу сказать, что для нас "неизвестные артефакты" — большая проблема, с которой идёт постоянная борьба.

Твои слова — "неизвестные артефакты" это не норма. Это отсутствие опыта или невежество."
Стало быть, согласно твоим словам, опыта у вас нет и полное невежество процветает ?

На самом деле "неизвестные артефакты" это следствие того, что "ничто не даёт гарантии отсутствия багов".
Напиши это у себя на мониторе

I>>Во вторых, не все ошибочные кейсы легко воспроизвести
·>Если не легко — значит что-то неправильно. И с этим надо что-то делать.

Спасибо, капитан !


I>>И самое важное — "пусть тестер напишет тесты какие он считает нужно" — эта формула исключает exploratory, принципиально.
I>>Можешь заранее описать тест == scripted тест и никак не exploratory.
·>Процесс написания теста — и есть exploratory testing. Только результат не тикет в баг-трекере, а исполняемый код. Если "не легко", то тестер может поработать в паре с девом|бизнес-аналистом|етс до тех пор пока не станет легко.

Чушь. Это эксплоратори только на первом прогоне. На втором это обычный scripted.

Здравствуйте, RonWilson, Вы писали:

RW>Здравствуйте, consign, Вы писали:

RW>ну обосрались, с кем не бывает, что такого-то
Тебе уже ответ написали в топике

Здравствуйте, Ikemefula, Вы писали:

I>>>И да, и нет. Тестеру нужно сто раз кликнуть, что бы найти новый ошибочный кейс. Тебе придется на те же сто кликов написать сто тестов, скомпилить, отладить, отдать на ci и после прогона узнаешь, что один тест нашел ошибку, а может и не нашел.
Кстати, про "сто раз кликнуть". Может у тебя другой опыт, но я обычно наблюдал, что из этих ста кликов 95 — некий стандартный setUp начальных условий. А только 5 остальных — варьируется и собственно является exploratory частью теста. В случае наличия кода — этот setUp уже обычно берётся готовый, из других тестов, варьируется какой-то небольшой участок кода.

I>>>Следующий раз тестер сделает еще сто кликов, непохожих на предыдущие, а тебе снова придется повторять эпопею с билдами.
I>·>Ты исходишь из неверного предположения. Авто-тесты — обычный код. Можно запускать локально, из IDE, подключаться отладчиком, етс. Коммитить и отдавать на CI нужно только что-то ценное, а не локальные эксперименты.
I>Мы ведь про эксплоратори ? Один раз написал — сто раз будет проверять одно и то же. Опаньки ! А надо на каждом прогоне _новые_ кейсы.
Я могу написать сто разных кусочков кода и запустить каждый по одному разу.

I>На всякий, еще раз — ручные и автотесты решают принципиально разные классы задач, непересекающиеся между собой.
I>Нужно использовать и то и другое, а ты хочешь исключить ручное полностью, да еще привираешь, что у вас ничего такого нет.
Ты почему-то поставил знак равенства между "ручной" и "exloratory".

I>Вот давай на 100$ — у вас куча тестеров/девелоперов регулярно пускает единичные тесты против энвайрмента, скажем, через JMeter или аналогичный тул. Опаньки ! Где мои 100$ ?
Я же уже приводил код, который у нас тестеры/девелоперы пишут/пускают (см. пример с переключением языка). Это _код_, а не тулы. Так что $100 — мои.

I>>>Кликая мышом можно за пару минут сотню непредусмотреных кейсов прощелкать. Это практически мгновенный результат. В автотестами тебе нужен разгон с понедельника.
I>·>У тебя какие-то странные автотесты.
I>У тебя. Ты утверждаешь, что эксплоратори в лёгкую реализуются автотестами. Покажи уже эту мульку, не надо словоблудия, просто покажи эксплоратори тест в виде автотеста.
Пишешь кусочек кода — запускаешь, смотришь как работает.

I>>>И потому такие тесты не нужны, потому что, как я говорил, 90% UI это или 3rd party и никакого контроля, или другой уровень пермишнов и снова никакого контроля.
I>·>Так надо писать контролируемый код
I>Сообщи эту блестящую мысль вендорам OS, браузеров, библиотек, фремворков и тд.
Некоторые в курсе, и не плачутся, а автоматизируют.

I>>>·>Типичное заблуждение.
I>>>Пока ты будешь писать тест "открыть приложение-закрыть приложение" UI может сменить не только морду, но и движок
I>·>Просто "тест" не пишется. Пишется авто-тестируемый код.
I>Не надо слов — покажи это на примере эксплоратори теста.
Да что показать-то? Представь себе ручной эксплоратори тест и мысленно замени действия производимые мышой, клавой, етс на действия производимые командами ЯП.

I>>>Не знаю, у меня каждый раз новые последовательности, уникальные и неповторимые.
I>·>Так пиши новые кусочки кода, уникальные и неповторимые.
I>Твои кусочки кода уникальны до первого прогона. Дальше они уже никакие не уникальные. А надо что бы КАЖДЫЙ прогон был из уникальных.
Пиши новые кусочки КАЖДЫЙ раз если так хочется.

I>·>Скорее у нас немного другая ситуация. Тестировать UI отдельно от API у нас практически невозможно. Поэтому у нас только два выхода — автоматизировать тестирование UI или мануализировать тестирование API. Первое — эффективнее (как минимум — в большом проекте). Вы, как я понял, идёте по второму пути.
I>Ты чего то себе фантазируешь. Я вроде как сказал противоположное — у нас есть и автоматизаторы, и мануальщики.
I>Они решают разные задачи. Мануальщики находят новые кейсы, автоматизаторы создают тесты для регрессии.
I>У вас UI примитивный, потому легко автоматизируется. Скорее всего ваш UI 1 в 1 отражает некоторые данные в базе.
А мы не делаем этого деления. У нас просто тестеры, которые занимаются exploratory, используя код.
Насчёт примитивности... хз. Всё относительно. До MS Word далеко, конечно, но и не vasya pupkin homepage.

I>>>Объясняю в последний раз, баги нужно квалифицировать не по причине происхождения, а по степени влияния на юзера
I>·>Причём тут баги вообще. Если вы пишете такой код, что он плохо поддаётся тестированию — это не авто-тесты плохие, это код плохой.
I>Скучно, раз пять или шесть объяснил. Ну и твоя телепатия уже утомляет.
А зачем тогда счётчики? Зачем запуск sql вручную? Зачем класть на подоконник (типичный exploratory test, ничего не скажешь)?

I>>>Теперь самое страшное — п.1..3 могут быть результатом одного единственного некорректного CSS стиля. А у тебя все ошибки из за css это UX.
I>·>Да, бывает. Тут выход один — набираемся опыта и используем CSS осторожно.
I>Какие выходы — дело десятое. Важно, что важность бага не зависит от того, в CSS он, или в базе, или в логике.
Важность — не зависит. Зависит простота авто-тестирования.

I>>>Не гони, в качестве ручных тестеров у вас бетатестеры и эксперты со стороны заказчика.
I>·>Не во время релиза, а во время разработки фичи.
I>Никому не интересно. Просто специфика вашей области такая. Важно что принципиальных отличий нет, только цена ошибки больше, а значит и масштабы ручной работы выше. Отсюда ясно, что кроме как вовлечь в тестирование широкие массы юзеров у вас нет выбора.
Я не очень понимаю какое тестирование ты тут подразумеваешь. Это не регрессионное, не exploratory, а приёмочные тесты в процессе разработки — вносимые изменения проверяются на адекватность — фича выглядит так, как хочет заказчик. Релизы тут не причём. Опять всё мешаешь в одну кучу и делаешь глобальные выводы.

I>·>Не понял возражение. Причём тут автотесты?
I>·>Ты написал, "В реальных ситуациях ручное применяется в обязательном порядке. ... Никто и никогда, кроме отмороженых на всю голову индусо-контор.". Судя по статье, "причиной факапа было отстранение ручных тестеров".
I>·>Делаем нехитрый вывод: Яндекс — отмороженная на всю голову индусо-контора. Что не так?
I>С третьего раза у тебя всё получилось.
Что получилось? Найти противоречия в твоих словах?

I>>>Твои автотесты требуют майнтенанса, написания, отладки, билдования, инфраструктуры и тд и тд.
I>>>Более того — уникальными они будут только на первом прогоне, а на надо — на каждом
I>·>Ручные тесты требуют не меньше.
I>Не ври. Ручные не надо отлаживать, билдить, не нужен клауд для них и тд и тд.
Зато нужен найм людей, обучение, составление горы документации, описания чего и как тестировать, трекинг прогресса, ведение отчётов, гигабайты емейлов/тикетов со скриншотами, совещания и тд и тд.

I>>>Покрыват тестами имеет смысл только когда функционал устаканился или же требования четкие и простые.
I>·>Но код же как-то ты умудряешься писать? Раз можешь написать код, то и тест тоже возможно, т.к. это тоже код. (Мы не говорим о проектах-прототипах, надеюсь?).
I>"возможно" — это никому не интересно. Экономику уже отменили ? Сочувствую. Тесты имеют стоимость. Одноразовые тесты на одноразовый код это деньги на ветер. В разработке UI очень много одноразовых вещей. Многие вещи рождаются и тут же дохнут.
Ах.. я понял. У вас тестеры бесплатно работают. Повезло.

I>Пудозреваю, у вас или примитивнейший UI, фактически маппинг БД на экран, или у тебя есть машина времени.
WUI, говорю же, не owner draw, слава богу. Его тривиально тестировать с selenium.

I>·>Я не понял. Юнит перестал посылать коллбэк, значит поменялось поведение — код использующий этот юнит должен быть в курсе. Изменения.
I>Юнит — не перестал. Перестал один из методов юнита — run.
I>·>Короче, давай код в студию, иначе я плохо понимаю что ты имеешь в виду.
I>Я уже дал весь необходимый код. Вот еще раз
...
I>Теперь ответь внятно — что делать с тестом метода run в котором ты присособил мок ?
Ты же изменил поведение публичного метода. Поэтому ровно то же, что и с любым другим кодом, который раньше вызывал run().
А вообще, зачем ты внёс это изменение? Что ты хотел добиться? Где тест, который это изменение тестирует?

I>>>А откуда сложность в системе если её код простой ?
I>·>Теорема Ферма — записывается элементарно. А вот доказательсто — хм...
I>Вот-вот, подумай над этим. Если каждая функция предельно простая, ниоткуда не следует, что вся система будет простой в понимании. Фактически реализация и есть доказательство, что идея может работать.
Я и говорю, код у нас простой, система — сложная.

I>>>Здесь нет двух случаев, UX и функционал, здесь ровно один баг — "некорректный баланс".
I>·>Можно более менее реальный пример, когда вдруг из-за css 1.0 нарисовалось как 10000?
I>Бесконечное количество вариантов — сдвиг контента, z-index, левый контрол, наложение и тд и тд и тд
Ок, соглашусь. Теоретически такое может случиться. Но мне ни разу в жизни не попадалось.

I>>>Скажем, если тебе нужно срочно вызвать скорую а диал-пад потерял стили и копки теперь вразнобой, сильно вряд ли ты согласишься, что баг минорный
I>·>Опять ядерный реактор™.
I>Где ты видишь реактор если речь про диал-пад ? У тебя в телефоне диалпада нет ? Сочувствую.
"вызвать скорую" и внезапно стили пропали. В общем что-то из области фантастики.

I>>>С такими вещами буквально весной возился около месяца. Смысла нет фиксить кроме как перед релизом.
I>·>"Смысла нет фиксить кроме как перед релизом." в копилку.
I>Именно. Минорный приортитет именно так и фиксита. Хотя, в вашей конторе может и наоборот, сначала минорные, а уже если хватит времени, за блокеры берётесь.
Надо фиксить не перед релизом, а перед тем как заявить, что фича готова к релизу, когда будет релиз — не важно. Тогда не важно, блокеры/неблокеры.

I>>>Я вот без понятия, как это качественно задетектить. Видео что ли записывать и анализировать ?
I>·>Попробуй. Начни просто со скриншота, с нечётким сравнением например. Отличить "чёрный экран" от "образец формы" — легко.
I>Да, я помню твои идеи — отключить все фичи, зафиксировать окружение, пару тысяч параметров что влияют на отрисовки и всё получится.
I>Ты уже сходит за Нобелевкой ?
Опять. Почему — когда авто-тестируем, ничего фиксировать нельзя, тестеры внезапно тестируют все эти окружения и пару тысяч параметров, да ещё перед каждым релизом?

I>>>Качественные эксплорейшн тесты это не просто варьировать, это постоянно новые уникальные кейсы. Не просто набор "сто рандомизированых модификаций базового теста" а именно уникальных кейсов.
I>·>Это код. Или ты хочешь сказать, что любой код это сто рандомизированных модификаций hello world?
I>Любой, повторно вызываемый код это scripted. Любой scripted != exploratory.
Любой повторно испонляемый вручную тест это scripted. Читай: https://en.wikipedia.org/wiki/Test_script и не упоминай больше scripted, это ортогонально manual vs automatic.

I>>>С ручными все просто — тестеру ничего не стоит за 5 минут выдумать и получить результаты по десятку и даже сотне последовательностей. И так каждый раз. А у тебя шансов совсем мало -кодить, кодить, кодить
I>·>С кодом я могу за 5 минут написать выполненить миллионы последовательностей. Сотня последовательностей за 5 минут — нереально. 3 секунды на последовательность? Не верю.
I>Хоть миллиарды. Повторный прогон будет обычным scripted.
Допустим. И что?

I>>>Практически всё. Тесты на сервере не гарантируют отсутствие ошибок. Как выяснить, кто из игроков в цепочке ошибся — исходный клиент, сервер или конечный клиент ? На сервер ушли корректные данные — исходный клиент в порядке, на его команду никаких багов не ассайним. На конечный клиент ушел некорректный ответ — виноват сервер, тикет ассайнится на сервер. Вот примерно так.
I>>>Самое интересно, баги такого сорта воспроизводятся с огромным трудом. Их даже тестеры повторить не всегда могут в разумное время.
I>·>Баг-то где фиксили? Если на клиенте, значит просто неправильно ассайн сделали.
I>Нигде ничего не фиксили, а воспроизводится сильно по разному в одном и том же окружении. Это нормально. Почему это нормально, уже объяснил раз 5 или больше.
Ничего не понял. Кто-то ошибся, что-то сломалсь, но ничего не фиксили.

I>>>Может влиять. Вот совсем недавно — работало год и вдруг вылез кейс, что в одном из случаев устройство дохнет. Оказалось из за ротации логов.
I>·>Раз в год — можно и потерпеть. Это не повод отказываться от авто-тестов.
I>Ты себе внушил непойми чего. Всё что я хочу донести до тебя — ручные и автотесты решают принципиально разные задачи, непересекающиеся между собой.
Задачи одни, средства и способы решения разные. У тебя просто мешанина с терминологией. То manual приравниваешь к exploratory, то automatic приравниваешь к scripted, то релиз продукта путаешь с реализацией фич, то event и handler путаешь.

I>Это примерно как "хорошее лучше плохого". На серверный АПИ как правило приходит четкое, однозначное описание — форматы, диаграмы, схемы данных, последовательность и тд.
I>Покрыть тестами проще простого.
I>Когда взаимодействуют разные системы, в т.ч. разнесенные между разными континентами-конторами, уже гораздо сложнее, ибо появляется целая куча неявных кейсов, недокументирвоаных особенностей и тд
I>А вот взаимодействие человек-компьютер вообще слабо поддаётся внятной формализации. Более того, требования мало того, что туманные, так и меняются _постоянно_.
Слабо, но поддаётся. Стоит отделить функциональные требования и UX, и внезапно всё становится чуток проще.

I>>>·>Воот.. Опять специально всё мануалите. Возможности приложения можно и без UI тестировать.
I>>>UI — в обязательном порядке вручную, остальное — по возможности. Есть возможность покрыть — QA покрывает автотестами. Нет возможности — не покрывают, им виднее.
I>·>Главный вопрос, который должен быть поставлен "если нет возможности, что сделать чтобы возможность появилась".
I>Спасибо, капитан. Не знали, что ты подскажешь это в 2015, потому додумались сами, еще в самых нулевых.
А зачем тогда счётчики и mouse-driven SQL?

I>>>·>"неизвестные артефакты" это не норма. Это отсутствие опыта или невежество.
I>>>Ты снова хочешь сказать, что у вас 100% покрытие автотестами и гарантия отсутствия багов
I>·>Нет, хочу сказать, что для нас "неизвестные артефакты" — большая проблема, с которой идёт постоянная борьба.
I>Твои слова — "неизвестные артефакты" это не норма. Это отсутствие опыта или невежество."
I>Стало быть, согласно твоим словам, опыта у вас нет и полное невежество процветает ?
Не путай "и/или". Да, опыт копится постоянно, его всегда мало.

I>На самом деле "неизвестные артефакты" это следствие того, что "ничто не даёт гарантии отсутствия багов".
I>Напиши это у себя на мониторе
О. Клёво. А раз ничто не даёт — ручное тестирование фтопку! ЧТД

I>>>И самое важное — "пусть тестер напишет тесты какие он считает нужно" — эта формула исключает exploratory, принципиально.
I>>>Можешь заранее описать тест == scripted тест и никак не exploratory.
I>·>Процесс написания теста — и есть exploratory testing. Только результат не тикет в баг-трекере, а исполняемый код. Если "не легко", то тестер может поработать в паре с девом|бизнес-аналистом|етс до тех пор пока не станет легко.
I>Чушь. Это эксплоратори только на первом прогоне. На втором это обычный scripted.
Ура. Ты согласился, что хотя бы один прогон авто-теста является эксплоратори. Делаем вывод — эксплоратори тестинг можно делать и с использованием авто-тестов. ЧТД.

Здравствуйте, ·, Вы писали:

I>>·>Так надо писать контролируемый код
I>>Сообщи эту блестящую мысль вендорам OS, браузеров, библиотек, фремворков и тд.
·>Некоторые в курсе, и не плачутся, а автоматизируют.

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

I>>Твои кусочки кода уникальны до первого прогона. Дальше они уже никакие не уникальные. А надо что бы КАЖДЫЙ прогон был из уникальных.
·>Пиши новые кусочки КАЖДЫЙ раз если так хочется.

Ну вот, ты долго стеснялся и наконец сказал
1 — для поиска новых багов надо писать новые тесты
2 — это не автоматизируется, ибо как только перестанешь писать тесты, сразу перестанешь находить новые баги

Что интересно, 99% таких тестов целиком и полностью одноразовые.
Гораздо эффективнее разделить работу
1 один кликает и фиксирует только ошибки. Т.е. условно "придумал и прокликал 100500 последовательностей, нашел 5 багов"
2 второй готовые ошибки автоматизирует "для 5 найденых багов написал 15 авто-тестов, потому что есть похожие случаи"

I>>У вас UI примитивный, потому легко автоматизируется. Скорее всего ваш UI 1 в 1 отражает некоторые данные в базе.
·>А мы не делаем этого деления. У нас просто тестеры, которые занимаются exploratory, используя код.

Да, вы вместо одного клика мышом, вы пишете несколько строчек кода и называете это "поиск новых багов".

I>>Скучно, раз пять или шесть объяснил. Ну и твоя телепатия уже утомляет.
·>А зачем тогда счётчики? Зачем запуск sql вручную? Зачем класть на подоконник (типичный exploratory test, ничего не скажешь)?

Затем, что
1 определенный класс задач крайне плохо поддаётся автоматизации — повторять не хочу в десятый раз
2 поиск новых багов принципиально не автоматизируется

I>>Какие выходы — дело десятое. Важно, что важность бага не зависит от того, в CSS он, или в базе, или в логике.
·>Важность — не зависит. Зависит простота авто-тестирования.

Главное, что твоим "это — UX" можно смело игнорировать.

·>Я не очень понимаю какое тестирование ты тут подразумеваешь. Это не регрессионное, не exploratory, а приёмочные тесты в процессе разработки — вносимые изменения проверяются на адекватность — фича выглядит так, как хочет заказчик. Релизы тут не причём. Опять всё мешаешь в одну кучу и делаешь глобальные выводы.

Это всего лишь специфика вашего бизнеса.

I>>·>Делаем нехитрый вывод: Яндекс — отмороженная на всю голову индусо-контора. Что не так?
I>>С третьего раза у тебя всё получилось.
·>Что получилось? Найти противоречия в твоих словах?

Прочитать именно то, что я и хотел сообщить тебе.

I>>Не ври. Ручные не надо отлаживать, билдить, не нужен клауд для них и тд и тд.
·>Зато нужен найм людей, обучение, составление горы документации, описания чего и как тестировать, трекинг прогресса, ведение отчётов, гигабайты емейлов/тикетов со скриншотами, совещания и тд и тд.

Автоматизаторов надо полагать ни нанимать, ни учить не надо ? И документация им не нужна, и знание процессов им по барабану как и всё прочее.

I>>"возможно" — это никому не интересно. Экономику уже отменили ? Сочувствую. Тесты имеют стоимость. Одноразовые тесты на одноразовый код это деньги на ветер. В разработке UI очень много одноразовых вещей. Многие вещи рождаются и тут же дохнут.
·>Ах.. я понял. У вас тестеры бесплатно работают. Повезло.

1 новый клик всегда дешевле кода который делает тоже самое. Сам подумай — сколько раз тебе надо надавить на клавиатуру, что бы в итоге родился тест, который сделает один уникальный клик ?
А если тебе надо эмулировать юзера в течение 8 часов, сколько строчек кода тебе придется написать ?

I>>Пудозреваю, у вас или примитивнейший UI, фактически маппинг БД на экран, или у тебя есть машина времени.
·>WUI, говорю же, не owner draw, слава богу. Его тривиально тестировать с selenium.

Я не сильно знаю, что за WUI, какая структура, сколько динамики, какие контролы, сколько их ? Есть ли сложные кейсы навроде "здесь кликнем, полистаем, вернёмся, откроем новую форму, установим галку и тогда у юзера васи появится новая кликабельная форма 'текущие операции'"

I>>Теперь ответь внятно — что делать с тестом метода run в котором ты присособил мок ?
·>Ты же изменил поведение публичного метода. Поэтому ровно то же, что и с любым другим кодом, который раньше вызывал run().
·>А вообще, зачем ты внёс это изменение? Что ты хотел добиться? Где тест, который это изменение тестирует?

Я изменил реализацию, а не поведение, клиенты как работали, так и работают. Где тест — дело десятое. Главное что твой тест никому теперь не нужен.
Клиентам нужен всего лишь факт вызова, а не место откуда делался вызов. Им по барабану, откуда пошел вызов — run или чтото еще.

I>>Вот-вот, подумай над этим. Если каждая функция предельно простая, ниоткуда не следует, что вся система будет простой в понимании. Фактически реализация и есть доказательство, что идея может работать.
·>Я и говорю, код у нас простой, система — сложная.

Пудозреваю, "код простой" означает "каждая функция в отдельности простая" а "система сложная" означает "код целиком понимают только те два старпёра, что 15 лет на проекте"

I>>Где ты видишь реактор если речь про диал-пад ? У тебя в телефоне диалпада нет ? Сочувствую.
·>"вызвать скорую" и внезапно стили пропали. В общем что-то из области фантастики.

См разницу "вследствие" и "впоследствии".

I>>Именно. Минорный приортитет именно так и фиксита. Хотя, в вашей конторе может и наоборот, сначала минорные, а уже если хватит времени, за блокеры берётесь.
·>Надо фиксить не перед релизом, а перед тем как заявить, что фича готова к релизу, когда будет релиз — не важно. Тогда не важно, блокеры/неблокеры.

Это и есть "перед релизом".

I>>Ты уже сходит за Нобелевкой ?
·>Опять. Почему — когда авто-тестируем, ничего фиксировать нельзя, тестеры внезапно тестируют все эти окружения и пару тысяч параметров, да ещё перед каждым релизом?

Можно, вопрос в стоимости. Уже объяснял.

I>>Любой, повторно вызываемый код это scripted. Любой scripted != exploratory.
·>Любой повторно испонляемый вручную тест это scripted. Читай: https://en.wikipedia.org/wiki/Test_script и не упоминай больше scripted, это ортогонально manual vs automatic.

Именно. При этом повторяемые тесты в manual просто так не ценятся. А вот новые да уникальные — ценятся крайне высоко.

I>>Хоть миллиарды. Повторный прогон будет обычным scripted.
·>Допустим. И что?

И всё. Поток новых багов иссяк. Хочешь новые — продолжай писать новые тесты. Пока пишешь — есть шанс.
Только надо помнить, что мануальщик справится быстрее тебя.

I>>Нигде ничего не фиксили, а воспроизводится сильно по разному в одном и том же окружении. Это нормально. Почему это нормально, уже объяснил раз 5 или больше.
·>Ничего не понял. Кто-то ошибся, что-то сломалсь, но ничего не фиксили.

Кликаешь на кнопку, появляется срака. Зовёшь девелопера, кликаешь еще раз — никакой сраки. Девелопер уходит, кликаешь на кнопку — снова срака. Снова зовёшь — обратно никакой сраки.
Чудеса ? Нисколько.

·>Задачи одни, средства и способы решения разные. У тебя просто мешанина с терминологией. То manual приравниваешь к exploratory, то automatic приравниваешь к scripted, то релиз продукта путаешь с реализацией фич, то event и handler путаешь.

1 мануал ради повторяемых тестов не айс, см следствие в п3
2 мануал ради новых да уникальных — айс.
3 повторяемые надо автоматизировать. Как раз потому, что п1

I>>А вот взаимодействие человек-компьютер вообще слабо поддаётся внятной формализации. Более того, требования мало того, что туманные, так и меняются _постоянно_.
·>Слабо, но поддаётся. Стоит отделить функциональные требования и UX, и внезапно всё становится чуток проще.

Я уже понял — когда диалпад отвалится, ты заведёшь минорный баг "UX не той системы", а надо заводить "отвалился диалпад"

I>>Спасибо, капитан. Не знали, что ты подскажешь это в 2015, потому додумались сами, еще в самых нулевых.
·>А зачем тогда счётчики и mouse-driven SQL?

Для исследования системы, на предмет наличния принципиально новых, неизвестных и потенциальных багов.

I>>На самом деле "неизвестные артефакты" это следствие того, что "ничто не даёт гарантии отсутствия багов".
I>>Напиши это у себя на мониторе
·>О. Клёво. А раз ничто не даёт — ручное тестирование фтопку! ЧТД

Не "в топку", а надо "заниматься исследованием качества системы".
Я так понял, вы исследования целиком автоматизировали, осталось автоматизировать написание нового кода для новых фич.

I>>Чушь. Это эксплоратори только на первом прогоне. На втором это обычный scripted.
·>Ура. Ты согласился, что хотя бы один прогон авто-теста является эксплоратори. Делаем вывод — эксплоратори тестинг можно делать и с использованием авто-тестов. ЧТД.

Я тебе это сто раз повторил, что всего лишь один. А надо — постоянно новые уникальные ранее неизвестные тесты-кейсы-баги.

Здравствуйте, ·, Вы писали:

>UI — не относится. А больше ничего и не было.
Как я уже говорил, у вас удивительная способность игнорировать вещи, которые вас не устраивают.

>У каждого разная практика и понимание здравости смысла.
Конечно разная. Только в данном вопросе других объективных факторов нет, особенно если вы игнорируете аргументы, которые вам не нравятся.

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

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

> Почему "QA Вася" может принять решение и качество продукта станет хорошим, а если решение принимает "ВРИО QA глубокоуважаемый Григорий Петрович", то уже не сработает?
Потому что QA обладает заведомо большией информацией о состоянии продукта, чем менеджмент.

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

> Меня раскритиковали, но ничего конретного никто не предложил,
А ни кто и не должен был ничего конкретного предлагать, в десятый раз вам уже говорю. Вы тут впряглись предложить решение и никто другой.
Для инженера у вас слишком короткая память и плохая способность концентрироваться на сути.

>Так что конкретно у них ненормально?
Можно начать с того, что разработка продукта велась на отладочной ветке библиотеки.

>"Такого рода продукты автотестами в принципе не покроешь" — звучит по-ламерски.
По ламерски, друг мой, звучат ваши обвинения в ламерстве оппонентов. Равно как и опрометчивое позиционирование автотестов, как способа решения проблем полной информацией о которых вы не обладаете.