Посиделки автоматизаторов

Немного с опозданием, но таки пишу небольшой отчет о посиделках автоматизаторов, на которые я попал, можно сказать, с самолета Новосибирск—Киев. На посиделки я пришел пообщаться, а также послушать опыт участников в налаживании процессов автоматизации. Да и что уж таить — тематика мне очень интересна.

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

У наших продуктов смежная предметная область. Например, в каждом продукте есть карточка предприятия в том или ином виде, во всех продуктах есть общие элементы этой карточки + своя специфика каждого продукта. Продукты различны по технологиям и ЯП.

Вопрос звучал так: можно ли писать тесты к продуктам с возможностью их переиспользования в целой линейке продуктов, написанных на совершенно разных технологиях?

По вопросу разгорелась дискуссия, и началась она с обсуждения вариантов организации отдела автоматизации в структуре компании в целом. Мы выделили 2 варианта.

Все на одного и один для всех, или Соберем «золотую» команду кросс-языковых автоматизаторов

Отдел автоматизации без привлечения разработчиков занимается написанием всей инфрастуктуры для автоматизации.

Плюсы:
  • отделы разработки не тратят время на создание инфраструктуры для автоматических тестов/фреймворков/api и т.д.
Минусы:
  • «золотая» команда. :) Отдел должен владеть всеми технологиями компании и должен разбираться во всех продуктах. Такую команду собрать очень сложно и дорого

Все за одного и один за всех, или Feature Development Team

Команда разработки каждого продукта планирует время девелопера для участия в написании инфраструктуры автоматизации. Формируется feature development team, т.е. команда, которая укомплектована теми специалистами, которые необходимы для решения именно этой задачи. В нашем случае это означает, что автоматизатору на помощь приходит кто-то из разработчиков.

Плюсы:
  • обязательные знания отдела определяются технологиями, с помощью которых будет осуществляться автоматизация тестирования продуктов.
  • разработчик, участвующий в написании инфраструктуры для автоматизации, знает продукт, использует свои знания о его внутреннем устройстве. Облегчает работу отдела автоматизации и ускоряет достижение результата.
Минусы:
  • в отделе разработки придется выделять время разработчика для работы над инфраструктурой автоматизации.

Какую схему выбрать? Мне больше нравится смешанная схема.

Смешанная схема

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

Обладает плюсами FDT-варианта и отчасти нивелирует его минусы. :)

После этого участники дали ответ на мой вопрос.

Keyword driven testing!

Ответом стал следующий вариант: отдел автоматизации берет на вооружение такую методику как keyword driven testing. Т.е. тесты пишутся в xml-нотации по следующему принципу:


сущностьдействиеданные

Сущность — проецируется в дальнейшем в класс драйвера. Сущности — так же, как и классы — могут наследовать друг друга.
Действие — проецируется в дальшейшем в метод класса.
Данные — параметры, которые будут переданы в вызываемые метод класса в драйвере.

Пример.


сущностьдействиеданные
SitePageopenhttp://test.test/index
TextFieldtypetest text
FormSearchFormsubmit

Существует хранилище для этих тестов и парсер. Парсер разбирает их и запускает на исполнение соответствующему драйверу продукта (своего рода API к продукту). Драйвер продукта выполняет тесты на определенном билде.
Каждый драйвер разрабатывается к продукту на своих технологиях и реализует действия, определенные в тестах.

В итоге:

  • отдел QA пишет тесты по методике KDT на xml, и тесты могут переиспользоваться для любых продуктов независимо от технологий. Порог вхождения небольшой. Можем задействовать всех QA-специалистов;
  • отдел автоматизации собственными силами или при поддержке разработчиков пишет драйвера к продуктам и актуализирует их с развитием продукта;
  • парсер и хранилище тестов реализуются единожды отделом автоматизации.

Заключение

Мне очень понравилось на посиделках, прошло и с пользой и большим интересом. Жду следующих посиделок ;)

Материал подготовили Кульпин Виталий и компания ДубльГИС

P.S. Вы еще не автоматизируете? Тогда приходите к нам! :)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



20 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
немного занимался автотестированием в большом продукте, потом завязал с этим делом и долго плевался, когда снова и снова предлагали-заставляли-принуждали этим заниматься вместо Джавы.
потом вытер упоминания об автотестинге из резюме и поменял работу где знали о том что я этим занимался.
попустило...
очень грабельное занятие.
много нюансов.
автотестинг — хорошая возможность сэкономить деньги, не ввязываясь в него.

а также, отличный способ отжать бабло с денежного лохклиента на wow-эффекте.

Помню похожие разговоры велись на хабре. Только там выступали против тестирования в целом. Мол кому оно нужно.

Я могу понять ваши слова, так как сам сталкивался с такой ситуацией, где автоматизация делалась ради автоматизации.

Но не хочу разводить демагогию. Если вам интересно могу привести десятку примеров, где автоматизация тестирования может принести пользу.

По поводу java. Сейчас уже можно писать UI тесты на этом языке программирования.

Как Web, так и Desktop.

автотестинговая поддержка большого продукта предъявляет высокие требования к спецам — они не только скрипты пишут, а ещё и сам продукт хорошо знают (функционал, бизнес требования итп), и всё что «сбоку» — работа с БД, вебом, продолжите список...
очень недешевые спецы.
а баги в основном находят не они, а систем\регрешшн итп-(мануал)тестеры.
вопрос: что дают автотесты?
уверенность в том, что система работает хорошо?
не дороговато?

Вот то, что вы описали это типичный bullshit automation. Он да, как правило не стоит тех денег которые в него вбухивают.

Это уже «зависит от». Миф о том, что тестировщики получают меньше чем программисты со временем рассевается. Да, разница есть, но намного меньше чем пару лет назад. Давайте посмотрим на развитые американские или европейские компании где есть такие должности как «Software Developer in Test». Мы тоже идем к тому, что автоматизаторы это те же самые программисты, которые пишут программы для тестирования. По поводу того, что находят баги, не совсем соглашусь. Автотесты, как и любые другие тесты нужно писать с умом. Чтобы они как раз находили баги, если они есть. Есть моменты, когда UI тесты писать нецелесообразно(или писать их но очень мало), а более выгодно покрыть приложение тестами на уровне кода или базы данных. Как можно увидеть на automation пирамиде. 4.bp.blogspot.com/…gory1_fig01.jpg

Есть такая шутка, что SDET в мелкомягких и гуглах это специальная такая должность для тех кого страшновато в девелоперы брать, но и выгонять жалко. И слова «Software Developer» там для того чтобы граждане не расстраивались. Шутка, но в каждой шутке есть доля шутки.

Всегда выгоднее покрывать приложение тестами ниже UI (чего как правило в принципе не делается и людей сразу сажают делать автоматические тесты на уровне UI выполняющие работу мануальных тестировщиков *bullshit!*). UI надо трогать только в случаях когда больше вариантов нет, и то делая это надо понимать зачем такие тесты пишутся. Если MBT — одно. Если получать более качественные билды — другое:
www.slideshare.net/...-doing-it-wrong

speakerdeck.com/...-all-shiny-toys

А если избавиться от человеков — лучше сразу переходить на целебные медикаменты.

То что тестировщики, получают меньше программистов это не миф, и это не зависит не от города и не от страны, в которых они работают.В этом легко убедится, посмотрев статистику по зарплатам в разделе зарплаты. С одним только исключением, может быть кому-то разница в зарплате 350-500 баксов, это пустяк, на который не следует обращать внимания.

Среднее по больнице это не то, о чем говорит коллега. В тестировании довольно низкий входной порог, что вызывает большую дисперсию и низкое среднее значение (которое, по статистикам выложенным на этом же сайте, выше чем у PHP-шников, например). По детальной статистике, которую можно посмотреть на этом же сайте, видно, что получать как минимум «не меньше» в тестировании можно. Да, сложнее чем в ряде других областей, но вполне реально.

Замечательный отчет. И задачка была хорошая :)

Сюда вообще можно запостить комментарий длиннее двух предложений, да еще так чтобы не появляась эта странная красная полоска?

Пустой див с классом top-msg topError
Выглядит примерно так: lh3.googleusercontent.com/...440/Capture.JPG

это когда матерное слово вставляешь, например.
полоска появляется, а надписи нету.
привыкайте.
баги — часть шарма ДОУ.

это программерский сайт, кто не может обойти баги — уходит))

Software as a Disservice это очень плохая модель. И радоваться тут совершенно нечему (скорее даже наоборот).

ЗЫ: Это не из-за матерных слов произошло. Продолжаем дискотеку.

Коментар порушує правила спільноти і видалений модераторами.

ЗЫ: Это не из-за матерных слов произошло.

самое короткое заклинание для вызова красной полоски — это «гoвнокод»

(на =хуй= она не реагирует, кстати)

Software as a Disservice это очень плохая модель.

в мире чистогана,-да.

здесь параллельный мир.

Таки да, странная проверка :)

Коментар порушує правила спільноти і видалений модераторами.

Виталя, спасибо за отчет. Отлично все расписал. Вы уже определились по какой схеме будете работать?

Андрей привет! Надо встретиться :) Как раз и общаемся

Підписатись на коментарі