Комментарии 10
У меня был случай. Меня приняли как DBA. Но забыли сказать что они искали дежурного DBA. В их чатике народ писал "я отошёл" и "я вернулся" с разницей в две минуты (видимо, отходил в туалет).
Я ушел на третий день.
Чатики прям боль. В поддерже на мне было около 12 продуктовых и столько же мастер стендов. Бывало и такое, что приходилось рабодать на двух-трех одновременно, потому что баги на них могли блокировать работу и саппорта первой линии и тестировщиков, которые не на дежурстве. Спам там просто дикий, заглушил телегу на второй день. Еще и тестеры иногда решали проблемы там, а не в тестовом чате)
Перегибы, конечно, бывают, но как ситуация видится мне:
1) тестировщик (особенно ака), по факту, должен уметь настроить своё окружение (почти как ДевОпс). Конечно, это может быть задача ДевОпса, но он один, очень умный, и очень занятой. Он сделает эту задачу, но через неделю. А если тестировщик сломает окружение? Опять ждать неделю?
2) аналогично с базами. От тестировщика требуется небольшой скоуп - работа с его личной инсталляцией, а так же дебаг. Сделать запрос, посмотреть результат, проверить отсутствие блокировок во время работы программы - да, требуеются _некоторые_ навыки, но опять же, они требуются чтобы не ждать админа баз данных. Сделать бэкап и развернуть его - тоже несложно.
3) техпис - а кому как не тестировщику писать? Аналитик может писать, если он есть. Если его нет, то только тестировщик обладет формализованными если не требованиями, то хотя бы ограничениями.
4) техсапорт - да, заявки от пользаков бросаются в КуА чтобы валидировать. Баг, не баг, что это вообще?
Согласен с вами полностью с тем, что хороший aqa должен бы и знать, как окружение натстроить, как развернуть тестовую бд для e2e, написать тестовую (именно тестовую) документацию, ну и валидировать баги. Упоминал в начале, что хороший специалист владеет смежными областями, но... К большому сожалению, когда я приходил в команду или задавал вопросы на собеседовании требовалось не просто настроить тестовое окружение или наладить процессы CI/CD (лично я думаю, что окружение ладно, но CI/CD точно должны быть вне зоны ответственности aqa). Зачастую, оказывалось что от CI/CD на проекте только название, сам выбирай инструменты, сам настраивай. С написанием документации тоже никаких проблем, но если только она тестовая. Множество статей, научных работ и книг определяют пул тестовой документации, и что-то ни в одной не находил "составление спецификации". Например, разработчик создав новую фичу отдавал на тест просто голую фичу, описания в одну строчку. Я спросил у лида, как мне тестить сие чудо? Он ответил, что нужно пойти к разрабу ,спросить как это работает и написать спецификацию... Чего, подумал я. Ладно поговорить с разрабом, по писать спецификацию? А для чего тогда у меня в команде человек с должностью "технический писатель" или "аналитик". На худой конец, почему этим разраб не удосужился заняться? Почему это зона моей ответственности? Зачем задачи саппортп попадают в qa (на одного бедного дежурного qa), если в проекте есть два человека, работающих в саппорте? Или они думают, что в qa работы маловато, тестить 12 продуктовых стендов, их мастеры, новые фичи и миграцию на постгресс (нашли время, конечно мигрировать). Это все конечно больше крик души... Но я вот думаю, что компаниям не стоити замалчивать такие вещи, когда их прямо на собесе спрашивают об этом. Лично я всегда так делаю. Более чем уверен, что найдется человек, которому будет искренне нравится такая работа, но это буду не я. Тем что они замалчивают подобные "мелочи", они тарят как мое, так и свое время. Ведь мог же найтись человек, который бы решал эти задачи быстрее и эффективнее ,чем тестировщик-аналитик, коим я и являюсь. Не раз предупредил компанию о своей сфере работы, инструментах и навыках, но видимо в погоне за "хорошим" кандидатом, они решили что можно мне и наврать в ответ на прямые вопросы... Не кажется ли вам, что это действительно проблема?
Это ведет к проблемам с дефицитом кадров, поскольку редко кто способен пройти столь жесткий отбор.
Нет никакого дефицита кадров в российском ИТ. есть дефицит желания платить деньги.
В то же время, поиски специалистов на более высокие позиции (senior и lead) затягиваются на долгие месяцы.
ИТ в РФ. Все по прежнему: не нужно. Итоги 1 квартала 2024, обзор текущей прессы и статей на Хабре
Почему эффективной сове не выгодно нанимать даже тушканчика (а увольнять, наоборот, выгодно)
Если компании могут выявить ложь кандидата на собеседовании или испытательном сроке, то у кандидата не всегда есть достаточно времени, чтобы выявить ложь со стороны компании.
Несмотря на горячее желание кадровиков закреплять кадры за производством пожизненно, все еще можно уволиться за две недели в РФ
ТС Алёша вот и все. Если видишь что позиция шляпа по факту и в трудовой не инженер по автоматизации тестирования - встаёшь и уходишь
а компания - очень лояльной и открытой
И буквально тут же про фактическую ложь со стороны компании. Так и в чем там была "очень открытость и лояльность"?
Насчёт написания спецификации, я бы просто отказался. Как и с постоянным саппортом (разовые горящие случаи еще куда ни шло).
По факту, в той фирме банально не выстроены нормальные рабочие процессы.
Кстати, сам был в похожей ситуации и тоже ушёл нафик.
Под лояльностью и открытостью я имел в виду больше понимающий подход к сотрудникам, ну и справедливости ради меня предупредили о работе в саппорте. Но вот где слукавили, так это в количестве этой самой работы :( В целом можно понять, что в небольшой компании процессы выстроены не лучшим образом, но как быть со вторым примером. Они буквально до последнего старались скрыть, что это сервисная команда, а в "команде" один человек... Это хорошо, что я решил узнать обо всем в конце технического, а если бы нет? Узнал бы на испытательном? Знаю много людей, которые не задают вопросы о компании, продукте и команде, стараясь устроиться на любое место. Думаю, их бы точно ждало разочарование. А ведь можно было изначально пригласить тех, ко был бы заинтересован в такой работе, а не скрывать все от соискателей до последнего...
К примеру, в одно время с тем, когда меня приглашали на работу из первого кейса, меня приглашали работать в дочерке одной нефтяной компании над их новым приложением для малого бизнеса. HR еще на прескрине предупредил о том, что по факту я там буду первооткрывателем в тестировании, буду настраивать свои процессы, а позже собирать команду. На тот момент (год или полтора назад) я вполне оправданно считал, что такая работа мне не по плечу. Но оглядваясь назад, если бы я только знал, что меня ждет в другой компании, я бы согласился и не думал бы, даже не смотря на то, что это совершенно новый опыт и большая ответственность как для спеца с двухлетним опытом.
Устраивался на автоматизатора тестирования, а попал в поддержку