t.me/atinfo_chat Telegram группа по автоматизации тестирования

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

база знаний
, , , , , , , ,
Теги: #<Tag:0x00007fd766ef1768> #<Tag:0x00007fd766ef15d8> #<Tag:0x00007fd766ef1308> #<Tag:0x00007fd766ef1100> #<Tag:0x00007fd766ef0f98> #<Tag:0x00007fd766ef0d90> #<Tag:0x00007fd766ef0a48> #<Tag:0x00007fd766ef0750> #<Tag:0x00007fd766ef05e8>
#1

Имя файла изображения1161×519 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:

21 Симпатия
Какие тренды в автоматизации тестирования 2017?
#2
#3

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

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

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

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

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

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

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

2 Симпатий
#4

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

#5

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

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

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

#6

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

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

8 Симпатий
#7

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

#8

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

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

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

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

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

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

5 Симпатий
#10

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

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

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

2 Симпатий
#11

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

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

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

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

1 Симпатия
#12

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

1 Симпатия
#13

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

2 Симпатий
#14

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

2 Симпатий
#15

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

1 Симпатия
#16

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

#17

OpenSource, docker, kotlin, reportPortal

3 Симпатий
#18

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

#19

docker, Appium, JS

#20

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

image.png1204×818 72.4 KB

image.png1320×800 123 KB

image.png1320×800 93.9 KB

image.png1208×770 61.8 KB

и т.д.