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

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 назад
Во вторых, не все ошибочные кейсы легко воспроизвести
В третьих, если продолжить, ты снова начнешь намекать что у вас всё классно и есть гарантия отсутствия багов

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

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.