Работа тестировщиком⁠⁠

Вот только не тестерам надо объяснять в чем соль шутки )))
Часть функционала покрыта избыточным тестированием а часть вообще без внимания

работаю разработчким
такое ощущение, что наши тесторивщики не только не понимают чего-то, но вообще в жизни не сильно умные

компания международная, все тестеры индусы (ну или шриланкийцы)

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

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

А я бы не советовал бы Саввина. Вредная книга. После нее переучиваться придется. Мой совет - Куликов.

https://careers.epam.by/content/dam/epam/by/book_epam_by/Sof...

1) Вы пишите документацию (тест кейсы, тест сценарии) на каждую задачу, даже если она совсем незначительная?

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

2) Есть ли какие-нибудь методики тестирования? А то мне почему-то кажется, что взять пункт из требований -> проверить все его возможные вариации -> перейти к следующему пункту

Советую почитать того же Куликова. Ну и еще загуглить "7 принципов тестирования" (там статья в двух или трех частях). Протестировать всё а) невозможно б) особо нет смысла тратить время на тестирование некоторых кейсов. Можно выделить эквивалентные области и протестировать по одному кейсу из каждой области. Можно выделить граничные значения и протестировать их плюс шаг влево и шаг вправо. Нужно опираться на свой опыт/экспертное мнение: если правили что-то, что могло сломаться как в прошлый раз/или что-то что могло быть задето, то надо пройтись и по этому функционалу. Надо выделить позитивные и негативные сценарии. Начинать нужно с позитивных, ибо если основной сценарий не проходит, то нет смысла и дальше тестировать. Надо посмотреть задачу с точки зрения пользователя. Ведь задача тестировщика в конечном счете не в том, чтоб убедиться, что задача была сделана, а в том, что потребитель будет пользоваться продуктом так как задумывалось. То есть продукт должен быть удобным, понятным, следовать каким-то внутренним или общепринятым UX гайдам. То есть задача тестировщика, не тестировать задачу, а тестировать продукт в целом, включая постановку задачи, причину по которой она возникла и т.д. Чтоб не вышло так, что сделали задачу согласно требованиям, но в требованиях была полная хрень.

3) Нужно ли писать автотесты на все что возможно или опять таки, если задача незначительная, то не стоит запариваться? И возможно ли автотестирование с десктопными приложениями?

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

Автотесты для десктопа написать можно. Есть различные варианты, которые зависят от языка программирования, на котором написано приложение, и есть ли у вас доступ к коду приложения. Но наверное лучше начать с автоматизации веба - проще будет.

Еще вариант - общаться в команде) берешь и спрашиваешь разработчика "как ты думаешь, на что эта фича влияет/затрагивает/что посмотреть". При верно заданном вопросе верному человеку можешь сэкономить кучу нервов и времени. Ну и конечно же, спросил - получил ответ - переварил и еще схожие места проверил) если работаешь с одними и теми же людьми, то иногда можно уже предсказать кто где накосячит.

В общих чертах - это смоук. Регресс - почти полное тестирование основного функционала. Чаще всего это оговаривается лидом или тест-дизайнером.

Могу предложить курс Алексея Баранцева, практикум по тест-дизайну. Там как раз рассматриваются различные техники тестирования и их применение. Курс достаточно тяжелый, но интересный.
Также можно почитать основу, того же Савина: Тестирование.com вроде.

Если не найдете в интернете - могу сообразить ссылку, но не сегодня уже