ох…с точки зрения поиска автоматизаторов - да, с точки зрения написания - далеко не так.
А в плане трендов, от АuQA все больше требуют общирности, и доступности.
Вообще темка интересная, и если не вдаваться в подробности:
40% компаний незнают нужно ли им это
20% говорят что нудно, но непонимают чем занимаются автокуа
30% понимают автокуа, и кое как используют
10% полностью используют автокуа и активно его развивают
С такой ситуацией, складывается весьма крепкое мнение, что автокуа надо - но не понятно зачем. Более того, в большинстве случаев автокуа отданы сами себе. По этому, на стыках “процентов” выходят требования:
развитие четкой направленности автокуа (автокуа от всех бед)
доступность автокуа (не все могут понять отчеты, и результативность куа)
интегрированность автокуа в конвеере разработки (регресс/производительнсоть)
внедрение куа на нужные вехи развития продукта (мы вот почти закончили, нужно быстро напедалить автотесты для всех вещей)
внедрения автокуа на ВСЕ стадии разработки
Тяжело говорить об этом, но многие компании, где я побывал, как работником, так и просто собеседовался, непонимают зачем и почему, грубо говоря автокуа, и на что оно направлено.
Если выделить из всего рассказа техническую сторону то:
простота (создание автотестов, которые будут понятны простому человеку, что бы куа давал только мидл-леер а писали тесыт другие люди - robotframework пример)
Уверен, сечас скажут что я описал очевидные вещи, но реальность действительно, печально, такова.
Последний месяц как посматривал вакансии по автоматизации (В основном Львов, Днепр, Харьков), то 80% вакансий это Python + RobotFramework, но никак не джава (с прискорбием)
А я заметил, что стало больше вакансий, где нужно внедрять автоматизацию с нуля. При чем не всегда заказчик / работодатель имеет четкие требования о платформе, на базе которой будет строиться автоматизация. А значит этот выбор и ответственность во многом ложатся на наши плечи.
На счет языка, имхо, надо овладевать и Питоном и Джавой. Фактически знание этих языков позволит работать практически с любым современным инструментом. Само собой это Селениум. Питон - это еще и TestComplete, а джава - IBM RFT. Ну и на другие тулы будет гораздо проще переключиться.
Мы докер и вагрант тоже используем, сейчас вот встала потребность C# проект на селениуме запускать на агенте c CentOS, переводу на DNX и в докер. На CI сервере тоже шаги докера используются в плане сборки.
А я заметил, что стало больше вакансий, где нужно внедрять автоматизацию с нуля. При чем не всегда заказчик / работодатель имеет четкие требования о платформе,
++
надо автокуа
а зачем? а почему именно сейчас?
не ну я хз, все так делают, думаю мы тоже должны, тем более автокуа звучит ка то круче чем куа
Лучшее, враг хорошего (с)
Давече приходилось объясняться почему я не могу написать автотесты для unity-android игры, и второе, почему эти тесты с “проходным” дизайнером будут неактуальны/не нужны.
Убедил, взяли студента на 1/4 ставки. Нервы целы, работа сделана, плюс, внеглавно готовим себе в штат сотрудника, который проходит боевое крещение.
попытаюсь объяснить, почему я считаю, что написание любого рода тестов, будь то API, unit, или UI скриптов - это стандартная ступенька эволюции тестировщика и почему люди сейчас ищут такого человека.
Не стоит изначально думать, что автокуа - будет заниматься только UI тестами. Например сейчас работая в 2гисе, работа обычного QA инженера включает в себя написание кода для UI, API и также ревью кода разработчиков\ их юнит тестов.
Понимание технологий и то, как это работает под капотом - одна из лучших вещей, какую можно сделать, чтобы начать влиять на качество кода, которое в перспективе выльется в меньшую головную боль. Как это достигать? Писать тесты Я не вижу ни одной причины работая в вебе тестировщиком, не захотеть учить язык, на котором пишут ваши разработчики, в особенности, если на нем можно писать юнит тесты для их кода, ревьюить их код (или хотя бы смотреть на мердж реквесты).
В How Google Tests Software четко разграничены ручные тестировщики и SDiT, которые решают задачи, которые фундаментально должны решать вопросы скорости разработки и обеспечения качества.
Зачем тогда вообще работать тестеровщиком, если можно работать уже разработчиком?
Писать юнит тесты для кода разработчиков? А давайте уже и проектить базу, та и дизайнить (ну а чо? UX ведь тоже тестеровщик должен учитывать?)
То что ищут, и что за это предлагают - это разные вещи, а занятость/проффесия должна четко определять кто и чем должен заниматься. А вот взаимосотрудничество - это уже малость другой фактор “взваливания” работы на когото другого.
ЗЫ Касаемо юнит тестов
Данная вещь это полностью забота разработчиков, так как они им нужны для сверки работоспособности кода ДО и ПОСЛЕ рефакторинга/введния нового функционала. Другое дело, что некоторые шибко умные девы, возомнили что писать тесты для СВОЕГО кода - это удел лохов, и взваливают работу на QAшников.
ЗЫЫ. Если мне б предстояло, ревьювить код дев-отдела, я бы смело говорил/просил позицию тим лида в отделе разработки, ибо для ревью мало знать язык, нужно иметь опыт НАПИСАНИЯ на нем кода, опыт в использовании текущих библиотек, и понимание процесса разработки на данном языке. И если меня приставляют к такой работе, я в праве требовать соответствующего отклика.
Это я к тому, что я не согласен с вашей позицией/точкой зрения
Я бы не стал принижать квалификацию тестировщика по сравнению с разработчиком.
Это принципиально разные задачи в примере, написание или правка юнит-тестов - нормальный таск для тестировщика.
Да, конечно должна четко определять, вот только я про это и говорю: что вы смотрите на сказанные вещи как превышение ваших должностных обязанностей, а я - как возможный момент роста качества кода-продукта
Почитайте все же How Google Tests Software, там четко проведена грань компетенции SETs и TEs.
Я бы не стал настолько драмматизировать, все же все в рамках фирмы работают на одно дело. Тут не место эгоизму, нужно подходить прагматически
Категорически не согласен. Это вопрос из серии “почему разработчик не может написать тест на свою программу или зачем вообще нужны тестировщики”. ISTQB различает 4 уровня тестов: Unit, Integration, System, Acceptance.
Тестировщики проверяют только последние 2 уровня. Почему? ответ очень прост: проверяя код, ты получаешь “замыленность зрения” на выходе. Иными словами, ты теряешь видение системы в целом и опускаешься на уровень “как оно сделано” вместо “как оно должно работать”. Ты получишь очень частую беду юнит тестов, когда тест проверяет, что юнит работает так, как он написан (вместо того, чтобы проверить, что юнит работает так, как должен) в своих системных тестах.
А это и неважно. Я ISTQB привёл как общеизвестный пример классификации типов тестов. Можно рассмотреть любую другую классификацию, где Unit будет отделён от System. Смысл моего ответа от этого не изменится.
Для себя в ИТ придерживаюсь принципа, что стоит обращать внимание (обращать внимание ≠ начинать изучать) на новые технологии спустя 3 года после их появления. Время покажет.
testomat.io управление авто тестами
Я не вижу ни одной причины работая в вебе тестировщиком, не захотеть учить язык, на котором пишут ваши разработчики, в особенности, если на нем можно писать юнит тесты для их кода, ревьюить их код (или хотя бы смотреть на мердж реквесты).
