Эм, ну основы все же да.
Хотя бы простенькие селекты

Это гуглится при надобности за минуту

Все гуглится при надобности.
Но смысл в том, что вы уже знаете.

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

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

Если рассматривать не сферического Джуна в вакууме, а уже работающего человека, который не работает с sql?

Тогда лучше учить то что поможет в конкретных задачах на сейчас

Мне вот надо редко-редко залезть в базу и чё то там глянуть или удалить, это даже не основы))

Если остается время на "самообучение" и хочется переключиться - можно взять чтото другое

noSQL бд тоже существуют, кстати)

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

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

Ребят, для сбора информации по функционалу незнакомого приложения нужно: поговорить с заказчиком, поговорить с разрабами и коллегами, и провести исследовательское тестирование? Я правильно понимаю или что то упустил?

Am happy to share this with you, this could change your life.

t.me/fxbintrading

В идеала, сначала нужно поговорить с менеджером проекта/владельцем продукта, не важно как эта должность будет называться на проекте. Он, как правило, проводит вводную лекцию по продукту. А еще он может дать доступ к документации по проекту.
Обладая этими знаниями можно начинать исследовательское тестирование продукта. Но оно делается достаточно поверхностным, без зарывания в отдельные части. При этом главных задач у нас 3:
* Ознакомиться с продуктом в целом.
* В процессе ознакомления копить вопросы, а не бегать каждые пять минут и тыкать палкой в каждого встречного и поперечного.
* Провести высокоуровневую декомпозицию продукта на системы, модули и отдельные компоненты, чтобы у нас перед глазами, желательно в виде какой-нибудь майнд-карты, было видение архитектуры системы. Мол, есть у нас регистрация, а вот тут еще есть часть системы по работе с заказами, а вот тут мы печатаем чеки, отчеты и прочую лабуду...
Не забываем попутно курить предоставленную документацию и при накоплении большого объема вопросов, запрашивать время у коллег на их разбор.
Это обобщенный подход. Бывает много нюансов, в зависимости от того, сколько у нас времени, зачем нас позвали сюда, как тестировщика и т.д. и т.п.

👍

Выключите свет! они на свет лезут!

Новые курсы выпустили группу?

нет
просто напомнили ссылку на этот чат здесь https://t.me/qa_jobs

зачет)