Тренды в автоматизации тестирования 2016

bdd
trends
docker
agile
devops
vagrant
webdriver
tdd
Теги: #<Tag:0x00007fedc4189610> #<Tag:0x00007fedc41894d0> #<Tag:0x00007fedc4189390> #<Tag:0x00007fedc4189250> #<Tag:0x00007fedc4189110> #<Tag:0x00007fedc4188fa8> #<Tag:0x00007fedc4188e68> #<Tag:0x00007fedc4188c88>
(Mykhailo Poliarush) #1

Имя файла изображения1161x519 266 KB

Недавно набрел на видео о трендах в автоматизации тестирования 2016.

Если коротко пройтись по видео то можно узнать:

  • по каким факторам можно распознавать тренды
  • dev + test + dev ops = future
  • нужно больше нырять в dev ops
  • configuration management automation
  • куда же без agile testing
  • автоматизация везде, TDD\BDD пользуется спросом
  • selenium король автоматизации, остальные где-то далеко позади
  • платные инструменты уже крутятся вокруг selenium
  • платные сервисы действительно приносят пользу, некоторыми можно пользоваться
  • выбор языка программирования, как обычно сложный выбор, но джава рулит
  • виртуализация и контейнеризация в моде, кто еще не знает что такое docker и vagrant уже отстают
  • нагрузочное тестирование очень важный процесс, все больше проектов уделяют этому внимание
  • будущее сулит еще больше интетесностей. тестирование и автоматизация IoT, дронов, виртуальной реальности

Какие ваши мысли по этому поводу? Где будет будущее и на чем стоит делать упор сейчас?

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

  • изучать selenium webdriver более детально
  • изучать различные инструменты и библиотеки по автоматизации
  • изучать разные языки программирования
  • погружаться в DevOps или смежные сферы разработки
  • изучать и активно применять TDD\BDD и другие полезные инженерные практики
  • изучать доп. средства для автоматизации docker, vagrant, jenkins и т.д.
  • изучать другие области IoT, дронов, виртуальной реальности
  • сменить компанию и проект, и реально начать заниматься чем-то новым
  • другое, напишу чуть ниже в комментариях … :slight_smile:

0 участников

Ну и спасибо за лайк под постом :wink:

Какие тренды в автоматизации тестирования 2017?
(Mykhailo Poliarush) #2
(Goshko Nazar) #3

ох…с точки зрения поиска автоматизаторов - да, с точки зрения написания - далеко не так.
А в плане трендов, от АuQA все больше требуют общирности, и доступности.
Вообще темка интересная, и если не вдаваться в подробности:

  • 40% компаний незнают нужно ли им это
  • 20% говорят что нудно, но непонимают чем занимаются автокуа
  • 30% понимают автокуа, и кое как используют
  • 10% полностью используют автокуа и активно его развивают

С такой ситуацией, складывается весьма крепкое мнение, что автокуа надо - но не понятно зачем. Более того, в большинстве случаев автокуа отданы сами себе. По этому, на стыках “процентов” выходят требования:

  • развитие четкой направленности автокуа (автокуа от всех бед)
  • доступность автокуа (не все могут понять отчеты, и результативность куа)
  • интегрированность автокуа в конвеере разработки (регресс/производительнсоть)
  • внедрение куа на нужные вехи развития продукта (мы вот почти закончили, нужно быстро напедалить автотесты для всех вещей)
  • внедрения автокуа на ВСЕ стадии разработки

Тяжело говорить об этом, но многие компании, где я побывал, как работником, так и просто собеседовался, непонимают зачем и почему, грубо говоря автокуа, и на что оно направлено.
Если выделить из всего рассказа техническую сторону то:

  • доступность (скрины/видео/человекоподобные тесты (DSL))
  • отчетность (тесная интергация с CI)
  • простота (создание автотестов, которые будут понятны простому человеку, что бы куа давал только мидл-леер а писали тесыт другие люди - robotframework пример)

Уверен, сечас скажут что я описал очевидные вещи, но реальность действительно, печально, такова.

(Roma Marinsky) #4

Последний месяц как посматривал вакансии по автоматизации (В основном Львов, Днепр, Харьков), то 80% вакансий это Python + RobotFramework, но никак не джава (с прискорбием) :frowning:

(Mykhailo Poliarush) #5

Да, я тоже кстати заметил такой тренд. Вот мне кажется что python может иметь значительно большее распространение чем был было до этого.

В мире больше всего пишут на python, потому доля python должна увеличиваться …

Хотя есть неоспоримый факт, что большинство популярных инструментов для автоматизации все таки написаны на java …

(Yury) #6

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

На счет языка, имхо, надо овладевать и Питоном и Джавой. Фактически знание этих языков позволит работать практически с любым современным инструментом. Само собой это Селениум. Питон - это еще и TestComplete, а джава - IBM RFT. Ну и на другие тулы будет гораздо проще переключиться.

(Tatyana Durova) #7

Мы докер и вагрант тоже используем, сейчас вот встала потребность C# проект на селениуме запускать на агенте c CentOS, переводу на DNX и в докер. На CI сервере тоже шаги докера используются в плане сборки.

(Goshko Nazar) #8

А я заметил, что стало больше вакансий, где нужно внедрять автоматизацию с нуля. При чем не всегда заказчик / работодатель имеет четкие требования о платформе,
++

  • надо автокуа
  • а зачем? а почему именно сейчас?
  • не ну я хз, все так делают, думаю мы тоже должны, тем более автокуа звучит ка то круче чем куа
    Лучшее, враг хорошего (с)
    Давече приходилось объясняться почему я не могу написать автотесты для unity-android игры, и второе, почему эти тесты с “проходным” дизайнером будут неактуальны/не нужны.
    Убедил, взяли студента на 1/4 ставки. Нервы целы, работа сделана, плюс, внеглавно готовим себе в штат сотрудника, который проходит боевое крещение.
(Евгений Бухгаммер) #9

попытаюсь объяснить, почему я считаю, что написание любого рода тестов, будь то API, unit, или UI скриптов - это стандартная ступенька эволюции тестировщика и почему люди сейчас ищут такого человека.

Не стоит изначально думать, что автокуа - будет заниматься только UI тестами. Например сейчас работая в 2гисе, работа обычного QA инженера включает в себя написание кода для UI, API и также ревью кода разработчиков\ их юнит тестов.

Понимание технологий и то, как это работает под капотом - одна из лучших вещей, какую можно сделать, чтобы начать влиять на качество кода, которое в перспективе выльется в меньшую головную боль. Как это достигать? Писать тесты :slight_smile: Я не вижу ни одной причины работая в вебе тестировщиком, не захотеть учить язык, на котором пишут ваши разработчики, в особенности, если на нем можно писать юнит тесты для их кода, ревьюить их код (или хотя бы смотреть на мердж реквесты).

В How Google Tests Software четко разграничены ручные тестировщики и SDiT, которые решают задачи, которые фундаментально должны решать вопросы скорости разработки и обеспечения качества.

(Goshko Nazar) #10

Зачем тогда вообще работать тестеровщиком, если можно работать уже разработчиком?
Писать юнит тесты для кода разработчиков? А давайте уже и проектить базу, та и дизайнить (ну а чо? UX ведь тоже тестеровщик должен учитывать?)
То что ищут, и что за это предлагают - это разные вещи, а занятость/проффесия должна четко определять кто и чем должен заниматься. А вот взаимосотрудничество - это уже малость другой фактор “взваливания” работы на когото другого.

ЗЫ Касаемо юнит тестов
Данная вещь это полностью забота разработчиков, так как они им нужны для сверки работоспособности кода ДО и ПОСЛЕ рефакторинга/введния нового функционала. Другое дело, что некоторые шибко умные девы, возомнили что писать тесты для СВОЕГО кода - это удел лохов, и взваливают работу на QAшников.
ЗЫЫ. Если мне б предстояло, ревьювить код дев-отдела, я бы смело говорил/просил позицию тим лида в отделе разработки, ибо для ревью мало знать язык, нужно иметь опыт НАПИСАНИЯ на нем кода, опыт в использовании текущих библиотек, и понимание процесса разработки на данном языке. И если меня приставляют к такой работе, я в праве требовать соответствующего отклика.

Это я к тому, что я не согласен с вашей позицией/точкой зрения

(Евгений Бухгаммер) #11

Я бы не стал принижать квалификацию тестировщика по сравнению с разработчиком.

Это принципиально разные задачи в примере, написание или правка юнит-тестов - нормальный таск для тестировщика.

Да, конечно должна четко определять, вот только я про это и говорю: что вы смотрите на сказанные вещи как превышение ваших должностных обязанностей, а я - как возможный момент роста качества кода-продукта :slight_smile:
Почитайте все же How Google Tests Software, там четко проведена грань компетенции SETs и TEs.

Я бы не стал настолько драмматизировать, все же все в рамках фирмы работают на одно дело. Тут не место эгоизму, нужно подходить прагматически :slight_smile:

(Goshko Nazar) #12

никто ее не принижает, просто у нее направленность другая, и соответственно скил билд

(Дмитрий Мирошник) #13

Категорически не согласен. Это вопрос из серии “почему разработчик не может написать тест на свою программу или зачем вообще нужны тестировщики”. ISTQB различает 4 уровня тестов: Unit, Integration, System, Acceptance.
Тестировщики проверяют только последние 2 уровня. Почему? ответ очень прост: проверяя код, ты получаешь “замыленность зрения” на выходе. Иными словами, ты теряешь видение системы в целом и опускаешься на уровень “как оно сделано” вместо “как оно должно работать”. Ты получишь очень частую беду юнит тестов, когда тест проверяет, что юнит работает так, как он написан (вместо того, чтобы проверить, что юнит работает так, как должен) в своих системных тестах.

(Евгений Бухгаммер) #14

ISTQB для меня не показатель абсолютной истины, т.к постулаты его не переосмысливались и стары как гуано мамонта.

(Дмитрий Мирошник) #15

А это и неважно. Я ISTQB привёл как общеизвестный пример классификации типов тестов. Можно рассмотреть любую другую классификацию, где Unit будет отделён от System. Смысл моего ответа от этого не изменится.

(Mykhailo Poliarush) #16

А кто какие тренды сформировал для себя на 2017 год в автоматизации?

(Roma Marinsky) #17

OpenSource, docker, kotlin, reportPortal

(Kosmos) #18

Для себя в ИТ придерживаюсь принципа, что стоит обращать внимание (обращать внимание ≠ начинать изучать) на новые технологии спустя 3 года после их появления. Время покажет.

(Anton Karpenko) #19

docker, Appium, JS

(Mykhailo Poliarush) #20

Можно еще пройтись по трендам тут https://insights.stackoverflow.com/trends

image.png1204x818 72.4 KB

image.png1320x800 123 KB

image.png1320x800 93.9 KB

image.png1208x770 61.8 KB

и т.д.