Я считаю, что описание багов должyо быть пошаговое. Так проще и воспроизводить, и понимать что произошло. Естественно для этого качественной писанины с комментариями достаточно в большинстве случаев, но не всегда. Когда нужно делать быстро, а описаний много, бывает проще написать что в аттаче скрин, на котором всё видно. Когда же тестировщик и разработчик разноязычные персонажи (япошки, ну и русские к примеру), то уровень их общения через единый английский иногда заходит в тупик, вот тут мне например бывает удобно делать документ с описанием действий и скриншотами к ним. Это естественно может оказаться лишним, зато вопросы пропадают сразу. Сам пользуюсь, если есть возможнность snagit, если нет - то встроенными средствами. Относительно записи видео могу сказать, что использовал его в целях предоставления разработчикам доказательств о том, что они явно что-то не то сделали (когда в свежедописанном месте совсем уж чудеса творятся), и проще ещё раз внимательно проверить всё написанное, нежели для одной маленькой кнопочки описывать всё, что она делает не так. Также ролики удобно использовать в целях предоставления доказательств воспроизводимости багов для такого элемента, как ProgressBar.

да, и забыл

!!! умение быстро находить нужную информацию (поисковики, хорошие книги, правильные форумы, блоги в помощь + иногда проще спросить у соратника по работе + круто ориентироваться во внутренней документации, не пропускай её мимо)

это не знания, но ОЧЕНЬ полезно уметь, особенно когда ничинаешь

мда...

думал, что форум в помощь...

по моему единственным полезным ответом является ответ Натальи (кстати почитать материалы её блога может оказаться полезным), однако:

1) без знания языка (любого, имеющего важное место в работе) жить плохо. Но обязательно нужно знать но только тот язык, на котором будешь писать документацию, отчётность и описывать найденные проблемы.

2) любое знание пригодиться, но для начала наизусть нужно знать только то, с чем будешь постоянно иметь дело

Начать мне кажется стоит с тематики ПО, которое собираетесь тестировать. Сложно тестировать вещи, о существовании которых узнал 5 минут назад.

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

для тестирования ПО хорошо знать ОС (особенности, отличия, банально ориентироваться внутри). Для автоматизации (даже самой минимальной) скорее всего понадобится знание CMD, bash и подобного рода вещей

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

возможно сразу пригодиться знать, что такое чеклист и тесткейс

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


пока в голову ничего не пришло больше, могу только присоединиться к словам Натальи.
Иди устраиваться в крупную компанию. Они и расскажут, и покажут, и научат, и заставят на практике закрепить...)))