Сразу напрашивается вопрос, «а кто спрашивает?»

Воображение рисует студента последнего курса технического ВУЗа, знания которого более менее свежи, информации дано много, программирование потрогано на нескольких языках, но вот оно не притягивает. Вот стартануть будет в профессии легко, дообучения будет много, но и рост знаний будет шустрый. Работать будет становиться все сложней, но потому , что знания позволят залезть глубже в работу программистов, в продукт. Бекграунд позволит предположить вариантов проблем больше, но и найдено будет не мало. Не будет легко, но легко было бы и не интересно.

Дальше представляю слесаря монтажника или весёлого бармена с опытом работы 10 лет, которому надоела низкая зарплата, когда много рассказов про IT с перспективами и частыми премиями. Вот тут размещая резюме первый подвох. А не ты один этот рассказ слышал, и там оказывается много народу хотят, но твое резюме даже не просмотрено особо. Дальше какие то платные, бесплатные курсы, начинаешь хотя бы краем глаза понимать куда ты вообще собираешься. Дальше приглашение, собеседование, отказ без пояснений. Думаешь, что не так, может плохо ответил, не так сел, не то рассказывал, но причину не сказали. Дальше бросаешь это дело и возвращаешься к старому ремеслу, или с новыми силами поднимаешься и идешь на ещё тонну собеседований. Наконец приглашение, долгожданный Оффер. На работе тоже много нужно, продолжаешь фигачить и учиться, и не звучит это все легко.

Если уж ударяться в крайности, то дальше воображаем человека лет 50-55, работал где-то, даже программировал , но, например, на чистом C. Новое не изучал, но вот подумал, что надо что-то менять, попробовать. Честно в резюме описываешь опыт , весь сугубо технический. Но откликов нет, все же понимают, что придется обучать. Опыт привлекает, но возраст отпугивает , и не понимают, сможет ли такой человек обучаться новому и быстро. А тут уж даже если и устроится человек, то простым его путь не вижу.

Получается, что путь легким в данных ситуациях не выглядит. Но если смотреть прицельно, то «а кто спрашивает?»

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

Их можно мне кажется перечислять очень долго, уже не говоря о том, что у каждого они свои. То, что проблема для одного тестировщика, совсем не проблема для другого.

Незнание какого-то инструмента

Часто приходится работать с каким новым инструментом. Либо его использует вся команда, а ты видишь первый раз. Либо надо было какой-то внедрять, кто-то изучил и выбрал, а ты уже поставлен перед фактом. Второй вариант удобнее, так как изучивший не только должен подготовить какие-то инструкции и демонстрации, но и совместно внедряя, будет подниматься много вопросов, которые сразу же будут решаться. В первом варианте приходится делать большинство исследований самому, и повезёт, если внедряя, параллельно написали инструкции и гайды, что делается не всегда. И если есть хороший ментор или наставник, то один раз он может помочь и настроить, и провести какие то первые тесты вместе. Рекомендую искать инструкции по настройке и использованию на официальном сайте. Вроде простая рекомендация, но первым делом идут в гугл, а я частенько замечала копирования просто с официального сайта. И возможно его инструкций будет с головой хватать для решения всех вопросов, как минимум на первых порах.

Если не устроило, то поискать в интернете. Ещё бы дала совет, что если за полчаса, максимум час не смогли решить какой-то вопрос, застряли на каком то моменте, и не двигаетесь вперёд, то всегда спросите. Умение спрашивать очень нужное и полезное. Всегда уточните, кому можно адресовать вопросы, и активно пользуйтесь, вопросов глупых не бывает. Но надо только сформулировать, чтобы сэкономить время отвечающего. Резюмируя скажу, что не видела ещё инструмента, в котором не смогла разобраться, просто иногда может занять больше времени, чем хотелось бы.

Одним из сложных моментов я бы ещё назвала неоднозначные формулировки в описании ТЗ (техническое задание, по которому тестируем).

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

Все это позволяет сократить время на уточнения по тех заданию. Но… как же много я вижу потерь времени на то, что тестировалось совсем не то, что изначально планировалось, как же много претензий к качеству, когда задача была поставлена так, что понять её можно двумя разными способами.

Часто решением проблемы однозначного понимания занимается проджект проекта. Хотя это цель всей команды разработки. Главное, определить места, которые могут быть поняты неоднозначно. Вся команда заинтересована на первых же этапах выяснить то, что на самом деле мы делаем и зачем. И чтобы это поняли все участники разработки (от постановщика до тестировщика).

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