Мне было лень писать многабуков.

А про вопрос, там же есть не только правильный ответ 64к, но и неправильные рядомлежащие 1500, 1372. И вокруг всего этого можно порассуждать.

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

Как вы измерите качество ПО приходящего в тестирование? Критерии приемки могут быть только формальные типа "проект собран на дженкинсе, результат в артифактори".
1) Вам нужны метрики и статистика чтобы измерять проблему и видеть динамику.
2) Внедрять тестирование требований. Уже даже ответ на вопрос как мы проверим что требование выполняется выявляет много ньюансов. И разработчику отдавать с описанием "как мы это проверим"

3) Все через джиру. того что не внесено в джиру не существует.

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

 

 

 

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

 

А вы не пробовали сменить работодателя?)

 

да вот уже подумываю))) хотела получить луч надежды, что таки есть места, где работа налажена)))

 

В вашем случае не с процессами проблема, а с мудаками. Процессами это не лечится.

С одной стороны это вроде бы звучит как справедливое требование - ведт  тестировщик на тои тестировщик, чтобы находить несоответствия

 

несоответствия чего с чем?
Если ожидаемый результат тестировщик должен доставать из заказчика - значит аналитик филонил.

 Ага, без контекста это помидор в форме апельсина

Хорошая школа https://www.m2p.education/ но это не про игры.
Больше чем с половиной команды я вместе работал и преподавал во внутренней школе  Grid Dynamics. И с выпускниками школы потом тоже работал.

А указано какую заглушку, куда и как надо поставить?

Там, думаю, полезно сходить по ссылке с доступными командами
100%  там будут COUNT и GROUP BY

 Варианты ответов есть.

используй Хуки.
https://www.baeldung...-cucumber-hooks

Я писал тестовый клиент. 
но в нагрузочном тестировании таких сервисов стоит помнить, что они очень хорошо поддаются кешированиюи очень часто доставляют контент через CDN.

Там в описании процедуры апдейта БД еще есть "WARNING: if you are using a table prefix replace prefix with your prefix"

Автоматизатор - Это программист со знанием нескольких специфических библиотек и феймворков. Такой специалист способен автоматизировать составленные кем-то тесты.
Чтобы быть независимым - нужно мочь в тест дизайн.
 

Хорошее начальное обучение - это
https://online-learn...science?delta=0
говорят есть на русском

интересно, как скоро мы дойдем до машинного анализа цифрового следа и выявления "зачисток" :)
У меня оооооочень развесистая цифровая история. И я не очень помню чтобы мне за какие-то мои интересы было стыдно.

А еще я умею удалять пассажи, за которые могут попросить пояснить, до того как отправлю сообщение.

Пока не пришел Сергей с матом.

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

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

Таки я с вами категорически не согласен! Не перестали.

Топикстартеру.
У вас есть опыт. проблема в том, что он:
1) специфичен.
2) не поименован терминами принятыми в обществе.

Соответственно:
глоссарий istqb и классификация по нему того, что вы делали.
собеседования и проработка непонятных вам требований.

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

Я года два назад МТС уронил.

Саппорт примерно неделю отвечал что приносят свои извинения, у них глобальная авария. Потом еще дня 3 конкретно с моим номером разбирались. А всего-то попытался перенести услугу общего доступа с одного номера на другой.

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

"мы делали регресс быстрее и за счет этого релизились чаще;

мы больше не сокращали объем регресса — улучшилось качество.

выпускать релизы как можно чаще

сокращению времени регресс-тестирования в 2 раза

"

 

Все это, конечно, прикольно но как это оценил бизнес ? Поднял зп в 2 раза ?

Вы будете смеятся, но в обязанности менеджера входит улучшение показателей процесса. и один из них time to market. скорость доставки фич от идеи до прода. Это то. за что он получает зарплату.
Хороший бизнес за достижение целей благодарит. иногда премиями, заранее оговоренными, за достижение целей бизнеса в срок и в рамках бюджета

На самом деле, про селениюм и хром я ничего не знаю.

про цифры - это ближние значимые числа шестнадцатеричной и двоичной систем. 0xFFFh 0x1000h, вокруг них любят собираться дефекты, тем более что 12 бит (3 hex - символа) опять же может быть значимым числом для base64.

Если бы передо мной стояла такая задача то я
1) спросил бы Баранцева, а вдруг он уже знает ответ.

2) погуглил бы на предмет настройки размера буффера кадра для скриншота
3) попробовал бы взять скриншот не base64 возможно это сработает
4) попробовал бы поставить высоту 16384+ особенно если моя догадка про пролегание границы на 8191-8192 подтвердится. вполне возможно что дефект ограничен диапозоном 8192-16383

на самом деле вопроса 2.

1) почему не получается взять скриншот высоты больше 8100 ( а скорее 8191 или 8192)

2) почему в 86 версии тесты падают.
 и это совершенно разные вопросы.

Вполне возможно что в 85 версии вы просто не берете слишкомбольшой скриншот, потому что тесты не падают, а если уроните специально, то тоже не получите скриншота

Ну а про то почему упали тесты на 86 версии у вас никакой информации нет. ее съело падениесамих тестов на попытке сохранить скриншот.

1) Чтоб понять что такое эффект пестицида надо в него пару раз влететь и разобраться как именно баг проскочил мимо тестов. В любом случае, это всегда продолб или отсутствие аналитики.

2) Опыт. Хорошая документация. Грамотный анализ документации. покрытие требований тестами. Мы никак не можем сказать что мы рассмотрели все ситуации, можно только перечислить что мы провеили.

3) находят ли дефекты пользователи?

тесткейсы решают разные задачи.

1) передачу знаний

2) единообразность/стабильность тестирования разных версий

3) включение в работу джуниоров/ клиентов/ прочих некомпетентных людей.

4) Составление отчета о тестировании

5) Оценка покрытия.

6) Трассировка дефектов на требования.

Привет.

В этой статье "Тестируй не числом, а умением" рассказано, что уменьшить количество тестов можно, применив Попарное тестировние и Тестирование сочетаниями по N.
Для Попарного тестриования можно воспользоваться алгоритмом PICT. Попарное тестрование - это N=2.
А какой алгоритм составит сочетания по N=3?

RTFM

"By default, PICT generates a pairwise, or order two, suite of test cases–all pairs covered. You can set the order to a value larger than two using the option /o:. For example, if you specify /o:3, the resultant test cases will cover all triplets of values,  producing a larger number of tests than the pairwise option, but potentially giving the test suite more coverage. The maximum order for a simple model is equal to the number of parameters, which will result in an exhaustive, all possible combinations, test suite. Following the same principle, specifying /o:1 will produce a test suite that covers all values only once (combinations of 1)."