Я бы в тестеры пошёл, пусть меня научат

Сафонова

нет.
Я считаю — зависит от конкретного человека. Но уж совершенно

точно, ручное тестирование приводит к развитию софта.
Мне приходилось пользоваться приложением для записи в некий кроссфит-зал. Оно — основной способ записаться на тренировку. Второй способ — лично записаться в отделе продаж, если с приложением что-то не так. Т.е. пользователю навязан способ. Удобен ли он?

найденный мной способ = 7 шагов.
— Добавление параметров фильтрации увеличивает

перечень результатов выдачи, вместо того, чтобы сокращать.
— Сообщение о том, что запись на тренировку невозможна выдается на последнем шаге.
— В сообщении орфографическая ошибка.
— Кнопка обратной связи есть лишь в одном месте, и ее не так просто найти.
— Переход по пуш-уведомлению приводит к ошибке.
— Запись на уже проведенную и оцененную тренировку можно отменить.
И т.д. При чем, возможно, приложение соответствует т.з.
Если хочется что-то менять к лучшему, надо идти в тестеры!

Куликов),
— тематические ресурсы (http://www.protesting.ru куда стоит идти за терминологией),
— форумы (http://software-testing.ru),
— блоги

продвинутых тестировщиков.
Интересоваться темой разработки ПО (модели разработки, жизненный цикл ПО, самое общее представление о языках программирования) чтобы:
разговаривать с будущим работодателем на одном языке,
четко понимать свой стартовый уровень.
Фильтровать и копить полезную информацию. Привычка все записывать спасает.

себе позволить).
— Стажировка (если нацелены планомерно развиваться именно в рамках

данной компании).
— Конференции, мит-апы и иже с ними.

Все, что поможет получить сконцентрированный опыт, уже кем-то обкатанный на практике.

если вы обнаруживаете:
— проблемы в работе, 
— орфографические ошибки, 
— то, что

вас раздражает как обычного пользователя.
Развивать критическое мышление.
Пользоваться здравым смыслом.

ваш предыдущий рабочий опыт и тестирование.
Разместить резюме на любом удобном

сервисе поиска работы, который часто мониторят IT-компании.
Посещать мероприятия, подобные этому.

соответствовать жестко прописанным требованиям). 
С чем вы имеете дело? (прямой работодатель/кадровые

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

в вас заинтересован и задача которого — как можно быстрее

вывести вас на приемлемый уровень, дабы получить в вашем лице полезного соратника.
Заниматься функциональным тестированием (тестировать ПО путем имитации действия конечного пользователя, с целью проверки реализованного функционала на соответствие требованиям, вариантам использования, стандартам и т.д.).
Что именно делать — зависит от места работы (модель разработки, наличие/отсутствие документации, наличие/отсутствие аналитиков).

Проведение повторного тестирования.
Завершение тестирования.

необходимых ресурсов,
вычисление трудоемкости выполнения намеченных действий.

Чаще всего, этим занимается

руководитель отдела/лид команды тестирования.

тестами.
Требования
— функциональные (описывающие какие функции должен выполнять продукт), 
— нефункциональные (требования

к окружению, поддерживаемости, надежности и прочим характеристикам продукта).

— прямые (т. е. формализованные в технической документации), 
— косвенные (т. е. проистекающие из прямых, либо являющимися негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования данного или подобных продуктов). 
Прямые требования всегда приоритетнее косвенных

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

реализации тестируемой функции или её части.
Тест-сьют (test suite) — набор тест-кейсов, охватывающий определенный функционал (фичу).
Тест-план (test plan) – зачастую используется как синоним тест-сьюта, но в классическом понимании это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

для майнд-мапов, создавая модель тестируемого функционала и прописывая кейсы на

уровне заголовков.
Проектировать стоит с точки зрения прогона основных пользовательских сценариев, в которых бы фигурировала фича.
Убедиться, что все правильно: показать готовую карту тестов с ответственным за продукт сотрудником (опционально: лидом команды тестирования, или аналитиком, или лидом команды разработки, или продукт-оунером). Это поможет не упустить важные моменты и расставить приоритеты.
Если есть необходимость писать подробные тест-кейсы, то выглядит это так: общее предусловие, шаг и ожидаемый результат.
Существует ПО для создания, хранения, прогона функциональных тестов (HP ALM, Test Rails, TFS и т.д.)

в программах для майнд-мапов, прописывая кейсы на уровне заголовков).
Проектировать с

точки зрения прогона основных пользовательских сценариев, в которых бы фигурировала фича.
Обсуждать готовую карту тестов с ответственным за продукт сотрудником (опционально: лидом команды тестирования, или аналитиком, или лидом команды разработки, или продукт-оунером). Это поможет не упустить важные моменты и расставить приоритеты.
Существует ПО для создания, хранения, прогона функциональных тестов (HP ALM, Test Rails, TFS и т.д.)

о полноте тестирования разрабатываемого функционала.

В условиях гибкой разработки вполне вероятна

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

— Проходятся кейсы (статусы: пройден, провален, заблокирован).
— Если кейс провален, создаётся связанный с кейсом баг-репорт (bug-report).

баг раньше — лучше проверить, не плодить дубли.
Повторно воспроизводить баг,

прежде, чем создавать баг-репорт (точны ли шаги, стабилен ли баг).
Прописывать: говорящий заголовок, предусловия (если необходимо), шаги воспроизведения, фактический результат, ожидаемый результат, пояснение, локализацию. При необходимости добавлять скриншоты, выжимки из логов, ссылки на функциональные требования, записывать gif с действиями пользователя (например, с помощью LICEcap). Пригодится все то, что на ваш взгляд облегчит участь разработчика.
Писать понятно. Перечитать несколько раз перед сохранением (каждый раз найдется что улучшить). Баг может вернуться через длительный промежуток времени или попасть на ретест к другому тестировщику. Избегать сокращений, кроме самых популярных.
Для более удобного создания баг-репортов часто используются баг-трекинговые системы
(Redmine, Jira, TFS). Освоить легко, знать полезно.

закрыт,
баг может вернуться на доработку.

Стратегия ретеста зависит от конкретной компании:

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

основе которой можно сделать вывод о готовности ПО (выпуску версии).

Параметры

завершения могут быть разные:
— пройдены все созданные кейсы,
— пройдены приоритетные кейсы, проверены все вернувшиеся баги,
— и т.д.

которое необходимо на них потратить (приходит с опытом).
В ходе тестирования

отдавайте приоритет основному, базовому, часто используемому функционалу (особенно для тех, кто склонен «закапываться» в работе, навык приходит с опытом).
Делайте общение с вами простым и конструктивным.
Это складывается из мелочей (если вы прикреплены к определенной команде разработчиков, держите у себя различные инструменты, которыми они пользуются, например, для работы с Git: пусть будет Source Tree, Git Extensions, Git Kraken), т.к. им будет проще вам что-то объяснять на знакомом примере).
Задавайте обдуманные вопросы. Много вопросов (как и положено новичкам).
Записывайте ответы и любую полезную информацию.
Помните, что вы стоите на страже интересов пользователей.
Учите английский и практикуйтесь читать код, даже если это мучительно больно.