Ну, я бы сказал "с довольно высокой вероятностью". :)

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

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

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

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

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

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

Мне кажется диалог зацикливается.
Ещё раз. Это не про "сможет или не сможет человек уйти к кому-то, у кого собеседования проще".
Это про мотивацию.
Если человек не готов по каким-то причинам потратить своего свободного времени на тестовое задание - это его право.
Совершенно не важно, почему он не хочет этого делать - по идеологическим соображениям, или потому что ему не понравилось тестовое, или потому что он может спокойно найти работу, не делая тестовое задание.
Это просто говорит о том, что "ну, не очень-то интересно".

В моём конкретном случае это - стоп фактор.
Потому, что это про некий cultural fit, интерес к работе и общую мотивацию людей, которых я набираю в команду.
Потому, что я не вижу смысла тратить деньги и ресурсы компании на ребят, которые выбирают работу по критерию "а вот здесь тестовое не надо делать, пойду сюда".
Ну и т.д.

В целом, тестовое задание отсеивает значительную часть желающих. Это факт.  
Есть ли среди отсеившихся процент тех, кто потом, через N времени, проникся бы и всячески мотивировался бы?
Есть. Как и любой критерий отсева, этот - не стопроцентный.
Но тут всё зависит от того, какой результат хочется получить.

В моём случае false positive результат несёт гораздо больше проблем и затрат, чем false negative.

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

Я не выдаю одно за другое.
Нежелание выполнять тестовое может быть связано в том числе с тем, что человек считает его «несоответствующим реальной практике».
А может быть с чем-то ещё. Миллион возможных причин. :)

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

В основном да. А что это за статья?

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

Доброе!
Как называется направление тестирования когда на стороне клиента(Web сайта) нужно работать с входящими и исходящими запросами?

Обучалку ищу понимание допинать

Тестирование API

Внезапно..
Спасибо!

Не обязательно. Это может быть просто функциональное тестирование, не обязательно апи.

всем привет.

я тут недавно задавал вопросы по составлению стратегии тестирования

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

я нашёл rapid software testing https://rapid-software-testing.com/rst-for-yourself/

и внутри у него есть euristic test strategy model https://www.satisfice.com/download/heuristic-test-strategy-model

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

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

так как так и не ясно, что у вас там происходит, поверхностное:
1. Определяете критичные (важные) области и свойства фичи/приложения/чего угодно ещё.
как правило это всё делится на области вида
"это приносит бабло" - списочек кнопок и функций с пометкой "очень важно!",
"это нужно, чтобы этим было возможно пользоваться" - списочек кнопок и функций/экранов, поддержка кучки платформ/браузеров, критерии по нагрузке, если таковые есть,
"это нужно, чтобы всё работало" - апишки, бэк - снаружи вроде не видно, а оно есть и должно работать.
Без требований большая часть этих вещей особо не придумывается, поэтому первым шагом всё равно будет добыча требований.
2.1 каждое из направлений ещё декомпозируете (например, отделяете мух от котлет в функциональном, ui  и нагрузочном тестировании, которые у меня в куче во втором пункте).
2.2 упарываться в декомпозиции вплоть до отдельно взятых полей/контролов, насколько есть времени и желания
3. гуглите точечно по названию нужной области. Например, "тестирование апи", "тестирование апи чек-лист", "тестирование формы ввода"
составляете список
4. добиваете каким-нибудь умным запросом в гугл вроде "интеграционное тестирование", "тестирование перехода состояний"
5. из полученного формируете список проверок
чтобы не умереть - обычно советуют проверять то, что обозначено как критичный функционал (причём определять, что критично, ещё до декомпозиции п 2.2)
также можете погуглить куда-нибудь в сторону ACC-анализа,
но от жирного "собрать требования" ничто не спасёт в любом случае.

извините.

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

спасибо)

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

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