Далеко не всегда разрабов подключают к code review автотестов. Но когда подключают - удобно :)

Метрики, качество, эстимейты, выбор автоматизации - это так-то не мидловые задачи :)

Я бы смотрел в сторону лидовых курсов (по крайней мере, там я это точно видел) и книжек по управлению.

Всем привет

Был массив элементов
Прошёл по этим элементам
Нашёл нужный элемент и хочу вернуть его используя return

Далее хочу выполнить нажатие по этому элементу

Нажатие будет по элементу, который вернул?

если вы будете нажимать по тому элементу который вернул метод, то нажатие будет по тому элементу который вернул метод

Кто о чем, Арсений о курсах. :)

А что-то конкретное можете посоветовать?

Селениум, и его аналоги - довольно глупая штука, он нажимает туда, куда ему говорят нажимать.

Спасибо

Я бы вообще разделял книги "для джунов" и "для всех остальных". Джуны - это, условно, юниты без базовых знаний, которым эти базовые знания надо бы получить. И набор этих знаний, хоть и отличается от компании к компании, можно хотя бы примерно усреднить. Потому что задача такого джуна - получить эти знания, чтобы найти работу.
Задача же любого другого специалиста (в том числе и уже работающего джуна) - либо улучшить свои знания для текущей компании, либо - для желаемой (научиться и уйти). И вот тут надо смотреть на конкретные требования и боли.
Если непонятно, что у вас болит - смотрите в сторону инструментов управления и работы с ними: опросы, интервью, статистика. Это общие для всех управленцев инструменты, так что книжки читать можно не только по IT.
Если боли понятны (медленные автотесты, плохие запросы в БД, непонимание работы с эмуляторами) - тут вам помогут уже более конкретные книги и, возможно, статьи. Потому что нужно решить проблему, а для этого читать целиком книжку - оверкилл.
Наконец, если вы хотите перейти в другую компанию - смотрите на их требования, и ищите наиболее популярные книги под эти конкретные хотелки.

Лично мне очень зашел курс по тест-менеджменту от Руколь. На моем проекте он окупился в первые 2 недели внедрения.

Ну блин, я потому и делаю курсы, что для меня это один из наиболее эффективных способов обучаться :)

Ну, вариантов, на самом деле, достаточно много.
Например вот: www.amazon.com/Perfect-Software-Other-Illusions-Testing-ebook/dp/B004J4VVE2/
Хорошая книга, но она не про то “как надо делать”, а скорее про то, “зачем вообще это надо”.

Есть довольно древняя, но неплохая книга про косты тестирования.
www.amazon.com/How-Reduce-Cost-Software-Testing-ebook/dp/B006NYFV8I

Есть годная книжка про метрики в разработке ПО, тоже помогает поправить майндсет немного:
www.amazon.com/Software-Development-Metrics-Dave-Nicolette/dp/1617291358/

Местами вредные, местами полезные советы есть тут:
www.amazon.com/Fifty-Quick-Ideas-Improve-Tests/dp/0993088112
(на самом деле они все полезные, просто не все их правильно применяют)

Ну и на последок немного менеджмента.
www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186
www.amazon.com/Guide-Software-Development-Designing-Managing/dp/144716797X
www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897


Как верно заметил Арсений - для большого количества проблем целая книга это оверкилл.
И тут, как бы, есть два варианта:
1) Искать более атомарную информацию (статьи, видео, выступления с конференций) по конкретной теме\проблеме.
Быстрое решение для локальной проблемы.
2) Расширять общий кругозор по одной или нескольким темам.
Тут уже можно хоть курсами, хоть книжками, хоть теми же статьями, но уже в рамках доменной области, а не в рамках конкретной проблемы.

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

Если хочется понимать, как управлять качеством и командой - копайте глубже в менеджмент, product needs и product values, а так же в то, чем эти штуки можно измерить (помимо уровня громкости заказчика).
Если хочется понимать, как тестировать правильнее и эффективнее - копайте в сторону повышения технической экспертизы: архитектура, паттерны, дизайн приложений, особенности работы инструментов, кодинг, етк.

Как вы думаете, можно ли с университетским образованием (айти) не читая Савиных и Куликовых быть нормальным джуном

Хз... Вряд ли

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

О, спасибо :)

Образование/Книги/ и позиция ДЖУН не связаны никак.

Я думаю что любой уровень Джун/Мидл/Сениор предполагает знание некоторых "ХардСкилов" и опыт применения этих скилов для решения N-ного числа задач.

К слову, если вдруг важно - Perfect software пару лет назад перевели, и сделали это отлично. У меня есть в бумаге, очень рекомендую