Сейчас бы без опыта в сферическом коне требования научиться анализировать и тестовую документацию писать
А потом придти на первое место работы и заново научиться с требованиями работать и тестовую документацию писать
Добро пожаловать во взрослый мир.
Каждый раз, когда вы будете менять работу, может оказаться так, что на новом месте и требования по другому пишут, и тестовую документацию по другому ведут.
А где-то вообще не будет ни того, ни другого.
Анализ требований упирается в три составляющих:
1) Понимание принципов работы продукта (платформы, стэка, бизнеса).
2) Понимание теории тестирования (потому что, в общем-то, большая часть пробелов в документации отлично ловится на написании тестов, если уж раньше не получилось).
3) Способность задавать (правильные) вопросы aka критическое мышление и здравый смысл.
В целом, каждый из этих пунктов не особенно-то привязан к наличию реального прям продакшена и опыта с ним.
Естественно, когда аналитик метает в тебя ТЗ, которое ему пришлось написать в три часа ночи на пути из бара в бордель, а вокруг бегает проджект менеджер с криками «НУ ЧО ТАМ ВСЁ НОРМАЛЬНО????» процесс обучения проходит быстрее, чем когда тебе приходится выкапывать знания самому из недр интернетов или курсов.
Точно так же, как понимание проблемных мест и частых ошибок в тех или иных доменных областях гораздо быстрее приходит когда протестированная тобой задача роняет продакшен тринадцать раз к ряду.
Но это всё ещё не значит, что практика на продакшене- единственный способ для получения этих знаний.