Pull to refresh

Comments 37

Ну и, наконец, команда сама должна захотеть… (вставить нужное) и сама решить, кто что будет делать. Без принуждения «сверху».

Золотые слова. Все автоматизации, технологии, методологии, методики и практики не работают без желания команды.

Желаниями команды можно и нужно управлять. Иначе команда вам скажет — к чёрту тестирование, немножко багов есть у всех.

Кмк Рейты писателя скриптов пользовательских сценариев ниже рейта разработчика. Давая эту работу более дорогому специалисту вы только увеличите бюджет.
То что у вас "не получилось" с выделенной командой тестеров говорит скорее о слабости менеджмента, чем об ошибочности подхода. Особенно, когда у вас много проектов — сам боженька велел матричную структуру с отдельным ульем тестеров в котором будет накапливаться, прости Господи, экспертиза.
А когда менеджмент слаб — никакой божественный agile, к сожалению, проблем не решит. Как только эффект новизны пройдет нерешённые проблемы в коммуникации и доверии сделают своё дело.

Рейты писателя скриптов пользовательских сценариев ниже рейта разработчика. Давая эту работу более дорогому специалисту вы только увеличите бюджет.

Для тестировщика нет разницы писать тесты в системе тест-менеджмента, типа HP ALM, куда они раньше тест-кейсы заводили; либо же эти тест-кейсы сразу как автотесты записывать. Библиотека реализована таким образом, что при ее регулярном использовании ты запоминаешь все ее шаги на память (их чуть больше 60), и собираешь тест-кейсы как в конструкторе. Как показал опыт, разработчик внутри команды привлекается редко, лишь тогда, когда тестировщик сталкивается с чем-то непонятным/незнакомым. Типа: реализовать шаги для тестирования интеграции с thrift-сервисом. Как правило, таких временных затрат за месяц набегает не больше 8 часов. Если сравнивать стоимость разработчика автотестов — и стоимость тестировщика, то в этом случае продукт получает экономию размером в еще один оклад тестировщика.


А когда менеджмент слаб — никакой божественный agile, к сожалению, проблем не решит.

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


Как только эффект новизны пройдет нерешённые проблемы в коммуникации и доверии сделают своё дело.

Эффекта новизны давно уже нет, так как пилотировали подход мы в 2016 году. А в 2017 процесс приобрел массовый характер. Из того, что я наблюдаю — у тестировщиков сформировалось свое коммьюнити, где они друг другу помогают в решении нестандартных проблем. К примеру, если кому-то нужен какой-то определенный шаг для автотеста, закидывается просьба в чат в slack, где либо находится владелец такого шага, либо коллега, готовый поделиться своим опытом.

Соглашусь — какое-то уж слишком сильное обобщение. И слишком желтый заголовок. «У нас не получилось — значит оно не работает». Так можно сказать сказать про любой подход, любую технологию, любой процесс. А как просто пример разных возможных проблем с их разбором — статья вполне хороша.

Соглашусь — какое-то уж слишком сильное обобщение

Именно — это заявляю я, QA-Java-dev. Сценарии, автоматизация, сверка с документацией — все я. Один. Пошел шестой год этого марафона.

*на текущем этапе контрольной сверки автоматика выявила ошибки в самых не очевидных местах:
— не рабочие кнопки в «глубине» продукта
— поломавшийся скролл страницы
— порядочное кол-во написанного JS с ошибками (в том числе и синтаксически)
— проблемы в различном функционале (не корректная пагинация в таблицах, проблемы с ревизями и т.д.)
сам боженька велел матричную структуру

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

У нас более 25-и человек в четырёх командах, которые занимаются соответственно четырьмя функциональными компонентами приложения. Наша фирма один из подрядчиков. Заказчик требует от всех подрядчиков написания UI-автоматизации. Я один пишу автотесты на все четыре функциональные компоненты. Где-то тестов выходит больше где-то меньше. Никто мою работу не координирует, никто не говорит мне, что нужно автоматизировать. Несмотря на то, что я выполняю желание заказчика, я это делаю для себя, чтобы упростить работу по обнаружению проблем. А проблем хватает, поскольку приложение оргомное, собирается из компонент — всегда где-то что-то сломано. И часто не у нас, а во феймворке или в точке перехода от одной компоненты к другой.
Кроме меня у нас еще есть полтора ручных тестировщика. Как-то раз я снял статистику по доле заведенных репортов на человека в команде. (Все-таки контроль качества я считаю обязанностью каждого участника команды, а не только выделенных людей.) И я с автоматизацией лидирую по этому показателю. И пока это так, автоматизация (со всей ее болью) себя оправдывает. Сравнительный обьем заведенных багрепортов — вот единственно вменяемая метрика эффективности и целесообразности автоматизации в проекте.

Какой вывод можно из этого сделать? Если премировать первое второе и третье место по обьему заведенных репортов — то тестировщики сами начнут автоматизировать. У нас не так, все на моем энтузиазме, но это как вариант. Только считать надо правильно, за вычетом дупликатов, отклоненных репортов и прочего мусора. «Чистые» баг-репорты это которые привели к изменению в коде приложения. Все остальное не считается. А то накидают там :)
Если премировать первое второе и третье место по обьему заведенных репортов — то тестировщики сами начнут автоматизировать.

Нет, проходили. Если премировать, то не автоматизация появляется, а придирки.
Да, я подозреваю что так это не работает. Я вообще не люблю такие прямые материальные вознаграждения, они очень совковые и как правило, по своей природе, дают нежелательный побочный эффект. Другой вариант:
Пусть эти придирки оформлены в виде багрепорта, они приходят тимлиду, он их отклоняет. Отклоненный багрепорт говорит о его некачественности. Как правило такое получается у людей малознакомых с продуктом, например у новичков в проекте. Со временем тестировщик начинает чувствовать что стоит репортить а что нет. Пусть отклоненные багрепорты экспоненциально тянут «личную статистику» если хотите «карму» вниз.
Как я Вас понимаю, у Вас и к отклонению багрепортов придираются. Тут нужно ввести правило, что решения тимлида не обсуждаются. Тестировщик не правда в последней инстанции. Он может иметь свое мнение, пусть даже верное, но решает всегда техлид/тимлид. Со временем тестировщики научатся находить именно то, что действительно интересует разработчиков и продактовнера.
Отклоненный багрепорт говорит только о том, что тимлид его решил отклонить. Это мало что говорит о качестве багрепорта.
Багрепорт ведь отклоняют с указанием причины.
Это говорит о том, что человек не смог получить достаточно информации, чтобы не заводить этот репорт. Или тимлид может завернуть вполне обоснованный и критичный для продукта баг, просто потому, что дедлайны горят? Тогда становится очевидна совсем другая проблема.
Мои дупликаты получались тогда, когдамне было «некогда» (читай: лень) копаться в багтрекере. Отклоненные репорты получались тогда, когда я недостаточно тщательно читал спецификацию или поленился лишний раз спросить лида если спецификация остуствовала или была недостаточно ясна.
В целом утверждение, что разработчик автотестов не нужен скорее ложное, если под таким человеком мы подразумеваем кого-то, кто занимается разработкой фреймворка.
Автоматизированные проверки на «человеческом языке» это прям тренд современной автоматизации)
Проблема в том, что разработанный фреймворк гарантированно слишком сложен для понимания тестировщиком, который за 2 недели познал прелести программирования.
Да, он сможет написать проверку, более прокаченный — сможет прописать страницы и локаторы. Но вот доработать фреймворк (например, захотелось нам в одном тесте в БД залезть или сообщение в MQ кинуть) сможет только специальный человек. 2 недель обучения с нуля для этого не хватит.
Т.е. на мой взгляд, полностью Ваша проблема не решена.
Решали аналогичную задачу на маленькой команде(3 проекта). В итоге получился такой работающий механизм:
Один человек, автоматизатор с опытом занимается:
1. Запуском автоматизации на проекте
2. Обучением тестировщиков азам работы с фреймворком в части создания сценариев
3. Развитием фреймворка, реализацией новых фич в нем по запросам от команд.
Тестировщики на проектах занимаются:
1. Написанием непосредственно автоматизированных проверок
2. Следят за покрытием автоматизированных проверок и анализируют результаты прогона тестов.
А основные разработчики не могут писать модули для тестового фреймворка?
Технически могут, наверное. На момент внедрения не рассматривали такой подход:
1. Считали, что нужен человек, который будет как-то управлять развитием фреймворка
2. Разработка была загружена, дополнительные задачи сказались бы на основных
3. Разработка в двух командах из трех шла на технологиях сильно отличных от используемых в автоматизации (продукты на платформе SAS).

Я постаралась акцентировать внимание в конце статьи как раз на том, что заниматься разработкой тестового фреймворка тоже должна команда. А не выделенные люди.
И у нас, если тестировщик сталкивается со сложной задачей, где его навыков не хватает — реализацией занимается бекенд-разработчик из команды. Чаще всего они работают с тестировщиком в паре, за счет чего также происходит и передача навыков и та самая "прокачка" тестировщика.
По поводу обучения:
Когда мы только пилотировали этот процесс — разработчики автотестов как раз и занимались обучением тестировщиков. Затем мы провели эксперимент и обучение провел java-разработчик, и оно никоим образом в своем качестве не пострадало.
Сейчас у нас обучение проводят уже сами "прокачавшиеся" тестировщики.


А зачем вы сделали фреймворк с технологиями, которые сильно отличались от того, с чем работали ваши разработчики? Наверное, потому что эти разработчики не участвовали в разработке этого фреймворка? Я понимаю, что на SAS, наверное автотесты писать бы не стали, но наверняка у ваших коллег опыт был/есть не только с этой платформой?

Один SAPовец, один сишник, остальные разработчики БД, в основном Oracle, такой бэкграунд.
Я не знаю как можно с помощью этого автоматизировать тестирование. Только м.б. извращенные варианты какие-то.
У вас свой подход, ни в коем случае не оспариваю правильность. Для себя вижу риск в неконтролируемом развитии фреймворка при таком подходе.

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

Риск понятен, который Вы обозначили, как и любой риск с ним можно работать. Например планировать работы.
Если автотесты сломались, их чинят. В зависимости от причин слома — автоматизатор или тестировщик.
Анастасия, статья мне понравилась, идея тоже.
Забавно, что и у меня есть доклад «Автотестеры не нужны» в нем я описал очень похожие шаги. И, кажется, сделал еще один, следующий.

В команде, в которой я работаю, тесты всех уровней — от юнитов до тяжелых UI тестов пишут все: бекендеры, фронтендеры, тестировщики, аналитики. Только дизайнер-проектировщик не пишет. Но раньше писала.

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

Не, на codeFest не получается попасть. А можно ссылку на ваш доклад?


По поводу того, что тесты пишут все: тут как команда договорится. Как правило во всех командах аналитики как минимум могут собрать тест-кейсы из готовых шагов, но при этом новые шаги разрабатывать вообще не умеют. Чаще всего, чтоб требования не писать в отдельной доке — описывают уже тестами.
Java-разработчики не любят "программировать на русском языке". Просто это и программированием сложно назвать =).
Но когда команда нуждается в помощи из-за загруженности тестировщика, то проблем не возникало и писали тесты на ура.
Пару раз даже запускали команды без обучения тестировщика и вообще без тестировщика, так как того еще не смогли найти. И в команде автотесты писали сами разработчики. Реже всего привлекаются для этой задачи front-разработчики. Ибо js. И больше времени коммьюнити потом тратит, чтоб им объяснить и научить.

Почему тестировщик не «тестер», а «автотестер» не автотестировщик? Вы уж определитесь и называйте их одинаково — или тестерами или тестировщиками.
Продукт/проект не генерировал соответствующую нагрузку на автотестера.

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

Для нас это было проблемой, потому что стоимость разработчика автотестов не маленькая. И естественно PO заинтересован по-максимуму использовать потраченные средства.
Если бы разработчик автотестов начал бы это свободное время тратить каким-либо другим образом на пользу команде/продукту, то наверное, его незанятость не так сильно бы бросалась в глаза.
И если недозагруженность сильная и регулярная — это повод задуматься.


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

Статья прям хороша.

Но есть несколько вопросов:
1) Как вы убеждали разработку начать активно писать тесты? Или они и раньше это делали?
2) Качество тестов разработчиков как-нибудь проверяется?
3) Тестирование ковыряется с Селениумом и, прости господи, BDD. Как они определяют отсутствие дублирования проверок, которые можно автоматизировать на более нижних слоях пирамиды?
4) Если я правильно понял, то разработка один раз причесала фрейморк. А дальше она как-нибудь вообще взаимодействует с UI тестами?

Для нас это было проблемой, потому что стоимость разработчика автотестов не маленькая. И естественно PO заинтересован по-максимуму использовать потраченные средства.
Если бы разработчик автотестов начал бы это свободное время тратить каким-либо другим образом на пользу команде/продукту, то наверное, его незанятость не так сильно бы бросалась в глаза.
И если недозагруженность сильная и регулярная — это повод задуматься.


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

Как может быть автоматизатор недогружен? Все сценарии автоматизированы для всех целевых платформ, все тесты зеленые, на все багрепорты написаны, все багфиксы верифицированны? Или какой спектр задач у автоматизатора? Вообще у меня люди которые «не видят работы» мысленно попадают в отдельную категорию. Читал недавно Valve's New Employee Handbook, так там человек сам должен подбирать себе и проект и занятие по душе в нем. Т.е. там таких, которым нечем заняться, нет в принципе.

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


Поэтому, первые user story могут выглядеть вообще в стиле "Отобразить кнопку для такой-то категории клиентов". При условии, что все тесты на api пишутся на уровне unit — и e2e-тестов самими разработчиками, со стороны UI нужно выполнить тесты на поведение и интеграцию UI с API. И их опять же оказывается не так много, потому что все возможные логические и алгоритмические проверки для UI-компонент тоже зашиты в модульные тесты на UI, и пишутся фронт-разработчиком.


Багрепорты у нас заводятся тестировщиком, как тикеты в jira. А чаще всего не заводятся — а сразу же правятся разработчиком после приемочного тестирования. Только если баг не критичный, то заводится. Но вопрос приоритетности/критичности принимается совместно командой.

UFO just landed and posted this here
ох уж эти agile словечки и подходы. Мне просто интересно — вот был у вас выделенный автоматизатор с навыками разработки и навыками тестирования, есть куча тестеров без навыков разработки, но с навыками (я надеюсь не только white box) тестирования. И вы в какой-то момент решили — «А давайте нагрузим тестеров еще и сверху работой, а автоматизатора уволим?». И вот вы берете и сообщаете — или вы учите java/scala/python/groovy/php (прости господи ) и мы вешаем на вас еще больше ответственности и нагрузки под видом — «мы же команда, мы же агиле!», а еще вы станете сильным специалистом full stack qa или мы вас увольняем. Так было? BDD вам понятно кто писал фреймворк и кто поддержку (скорее всего оказывает), так вот следующий вопрос — а кто отвечает за архитектуру/качество кода? Нагруженная команда разработки?
И как тут уже сказали — то, что у вас не получилось нормально подружить всех и вся (прикрываясь красивыми терминами из scrum/agile) — не нужно говорить об этом всем что ТАК надо делать всем. Спасибо
Я бы больше сказал: вам не нужны тестеры и автотестеры. Берите QA-специалистов. Да, они могут стоить как разработчики, но зато они сами прекрасно знают как обеспечить качество на проекте (даже если для этого потребуется заставить программистов заниматься ручным тестированием). Умение автоматизировать для них всего-лишь инструмент.

Автоматизатор тестирования — это тупиковая ветвь развития в нашей отрасли. Эта ветвь выросла по причине высокого спроса на автоматизацию тестирования и отсутствия четкого понимания кто её должен делать.


В итоге появилась целая специализация, и к сожалению к ней часто себя относят те, кто научился как-то готовить селениум, но при этом сам не тестировщик и не разработчик. Об этом в статье правильно написано.


Сейчас понимание как делать автоматизацию постепенно приходит. И мы "с удивлением" обнаруживаем, что привлечение разработчика к этому процессу на всех этапах даёт наилучший эффект.


О чем Анастасия и написала в статье. Статья — огонь!

Автоматизатор тестирования — это, по сути, разработчик, специализируйщийся на, как ни странно, автоматизации тестирования.

Эта тупиковая ветвь может и процесс CI настроить и в разработке помочь и протестировать может. Если у разработчика есть время на написание UI\Backend тестов значит ресурс девелопера просто так простаивает и нужно набирать больше тасков в спринт и использовать девелопера как девелопера т.к. его время стоит дороже чем автоматизатора.

Для вас основная деятельность автоматизатора тестирования — это написание автотестов или разработка инструментов автотестирования?

>нужно набирать больше тасков в спринт и использовать девелопера как девелопера т.к. его время стоит дороже чем автоматизатора

Порочный образ мышления, по причине которого в скрам-команде разработки все называются девелоперами и никак иначе.
Полумеры для слабаков. Не нужен никто, кроме пула умеющих абсолютно все, командно-мотивированных мегаспецов, между которыми размазаны все возможные проектные задачи. Каждый получает за четверых, работает за семерых, профит! Scrum-коммунизм, как высшая стадия развития agile.
Sign up to leave a comment.