Post #33

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