Комментарии 37
Ну и, наконец, команда сама должна захотеть… (вставить нужное) и сама решить, кто что будет делать. Без принуждения «сверху».
Золотые слова. Все автоматизации, технологии, методологии, методики и практики не работают без желания команды.
Кмк Рейты писателя скриптов пользовательских сценариев ниже рейта разработчика. Давая эту работу более дорогому специалисту вы только увеличите бюджет.
То что у вас "не получилось" с выделенной командой тестеров говорит скорее о слабости менеджмента, чем об ошибочности подхода. Особенно, когда у вас много проектов — сам боженька велел матричную структуру с отдельным ульем тестеров в котором будет накапливаться, прости Господи, экспертиза.
А когда менеджмент слаб — никакой божественный agile, к сожалению, проблем не решит. Как только эффект новизны пройдет нерешённые проблемы в коммуникации и доверии сделают своё дело.
Рейты писателя скриптов пользовательских сценариев ниже рейта разработчика. Давая эту работу более дорогому специалисту вы только увеличите бюджет.
Для тестировщика нет разницы писать тесты в системе тест-менеджмента, типа HP ALM, куда они раньше тест-кейсы заводили; либо же эти тест-кейсы сразу как автотесты записывать. Библиотека реализована таким образом, что при ее регулярном использовании ты запоминаешь все ее шаги на память (их чуть больше 60), и собираешь тест-кейсы как в конструкторе. Как показал опыт, разработчик внутри команды привлекается редко, лишь тогда, когда тестировщик сталкивается с чем-то непонятным/незнакомым. Типа: реализовать шаги для тестирования интеграции с thrift-сервисом. Как правило, таких временных затрат за месяц набегает не больше 8 часов. Если сравнивать стоимость разработчика автотестов — и стоимость тестировщика, то в этом случае продукт получает экономию размером в еще один оклад тестировщика.
А когда менеджмент слаб — никакой божественный agile, к сожалению, проблем не решит.
Согласно скрам-гайду — команда, которая делает продукт, должна работать вместе. А не отдельными функциональными группами. Потому что, когда человек не является частью команды ответственной за продукт — качество его работы для этого продукта и эффективность будет сильно страдать.
Как только эффект новизны пройдет нерешённые проблемы в коммуникации и доверии сделают своё дело.
Эффекта новизны давно уже нет, так как пилотировали подход мы в 2016 году. А в 2017 процесс приобрел массовый характер. Из того, что я наблюдаю — у тестировщиков сформировалось свое коммьюнити, где они друг другу помогают в решении нестандартных проблем. К примеру, если кому-то нужен какой-то определенный шаг для автотеста, закидывается просьба в чат в slack, где либо находится владелец такого шага, либо коллега, готовый поделиться своим опытом.
Соглашусь — какое-то уж слишком сильное обобщение
Именно — это заявляю я, QA-Java-dev. Сценарии, автоматизация, сверка с документацией — все я. Один. Пошел шестой год этого марафона.
*на текущем этапе контрольной сверки автоматика выявила ошибки в самых не очевидных местах:
— не рабочие кнопки в «глубине» продукта
— поломавшийся скролл страницы
— порядочное кол-во написанного JS с ошибками (в том числе и синтаксически)
— проблемы в различном функционале (не корректная пагинация в таблицах, проблемы с ревизями и т.д.)
сам боженька велел матричную структуру
Матрица это ни разу не сербрянная пуля, скорее огромный компромисс от безысходности. В матрице не найдёшь ответственного, у каждого по два начальника. руководители функциональных отделов либо могут расслабиться и ничего не делать отдав ресурс в проект, либо становятся бутылочным горлышком, начиная пропускать через себя все задачи. Абстракция типа "отвечают за качество и развитие ресурса" на деле почти не работает. Наблюдал всё это во многих компаниях.
Кроме меня у нас еще есть полтора ручных тестировщика. Как-то раз я снял статистику по доле заведенных репортов на человека в команде. (Все-таки контроль качества я считаю обязанностью каждого участника команды, а не только выделенных людей.) И я с автоматизацией лидирую по этому показателю. И пока это так, автоматизация (со всей ее болью) себя оправдывает. Сравнительный обьем заведенных багрепортов — вот единственно вменяемая метрика эффективности и целесообразности автоматизации в проекте.
Какой вывод можно из этого сделать? Если премировать первое второе и третье место по обьему заведенных репортов — то тестировщики сами начнут автоматизировать. У нас не так, все на моем энтузиазме, но это как вариант. Только считать надо правильно, за вычетом дупликатов, отклоненных репортов и прочего мусора. «Чистые» баг-репорты это которые привели к изменению в коде приложения. Все остальное не считается. А то накидают там :)
Если премировать первое второе и третье место по обьему заведенных репортов — то тестировщики сами начнут автоматизировать.
Нет, проходили. Если премировать, то не автоматизация появляется, а придирки.
Пусть эти придирки оформлены в виде багрепорта, они приходят тимлиду, он их отклоняет. Отклоненный багрепорт говорит о его некачественности. Как правило такое получается у людей малознакомых с продуктом, например у новичков в проекте. Со временем тестировщик начинает чувствовать что стоит репортить а что нет. Пусть отклоненные багрепорты экспоненциально тянут «личную статистику» если хотите «карму» вниз.
Как я Вас понимаю, у Вас и к отклонению багрепортов придираются. Тут нужно ввести правило, что решения тимлида не обсуждаются. Тестировщик не правда в последней инстанции. Он может иметь свое мнение, пусть даже верное, но решает всегда техлид/тимлид. Со временем тестировщики научатся находить именно то, что действительно интересует разработчиков и продактовнера.
Это говорит о том, что человек не смог получить достаточно информации, чтобы не заводить этот репорт. Или тимлид может завернуть вполне обоснованный и критичный для продукта баг, просто потому, что дедлайны горят? Тогда становится очевидна совсем другая проблема.
Мои дупликаты получались тогда, когдамне было «некогда» (читай: лень) копаться в багтрекере. Отклоненные репорты получались тогда, когда я недостаточно тщательно читал спецификацию или поленился лишний раз спросить лида если спецификация остуствовала или была недостаточно ясна.
Автоматизированные проверки на «человеческом языке» это прям тренд современной автоматизации)
Проблема в том, что разработанный фреймворк гарантированно слишком сложен для понимания тестировщиком, который за 2 недели познал прелести программирования.
Да, он сможет написать проверку, более прокаченный — сможет прописать страницы и локаторы. Но вот доработать фреймворк (например, захотелось нам в одном тесте в БД залезть или сообщение в MQ кинуть) сможет только специальный человек. 2 недель обучения с нуля для этого не хватит.
Т.е. на мой взгляд, полностью Ваша проблема не решена.
Решали аналогичную задачу на маленькой команде(3 проекта). В итоге получился такой работающий механизм:
Один человек, автоматизатор с опытом занимается:
1. Запуском автоматизации на проекте
2. Обучением тестировщиков азам работы с фреймворком в части создания сценариев
3. Развитием фреймворка, реализацией новых фич в нем по запросам от команд.
Тестировщики на проектах занимаются:
1. Написанием непосредственно автоматизированных проверок
2. Следят за покрытием автоматизированных проверок и анализируют результаты прогона тестов.
1. Считали, что нужен человек, который будет как-то управлять развитием фреймворка
2. Разработка была загружена, дополнительные задачи сказались бы на основных
3. Разработка в двух командах из трех шла на технологиях сильно отличных от используемых в автоматизации (продукты на платформе SAS).
Я постаралась акцентировать внимание в конце статьи как раз на том, что заниматься разработкой тестового фреймворка тоже должна команда. А не выделенные люди.
И у нас, если тестировщик сталкивается со сложной задачей, где его навыков не хватает — реализацией занимается бекенд-разработчик из команды. Чаще всего они работают с тестировщиком в паре, за счет чего также происходит и передача навыков и та самая "прокачка" тестировщика.
По поводу обучения:
Когда мы только пилотировали этот процесс — разработчики автотестов как раз и занимались обучением тестировщиков. Затем мы провели эксперимент и обучение провел java-разработчик, и оно никоим образом в своем качестве не пострадало.
Сейчас у нас обучение проводят уже сами "прокачавшиеся" тестировщики.
А зачем вы сделали фреймворк с технологиями, которые сильно отличались от того, с чем работали ваши разработчики? Наверное, потому что эти разработчики не участвовали в разработке этого фреймворка? Я понимаю, что на SAS, наверное автотесты писать бы не стали, но наверняка у ваших коллег опыт был/есть не только с этой платформой?
Я не знаю как можно с помощью этого автоматизировать тестирование. Только м.б. извращенные варианты какие-то.
У вас свой подход, ни в коем случае не оспариваю правильность. Для себя вижу риск в неконтролируемом развитии фреймворка при таком подходе.
А как вы решаете проблему с тем, что к автоматизатору может случиться большой поток запросов от тестировщиков?
Приоритеты, очередь? Как это может повлиять на регрессию? Что случается в ситуации, когда автотесты сломались и регрессия из-за этого застопорилась?
Забавно, что и у меня есть доклад «Автотестеры не нужны» в нем я описал очень похожие шаги. И, кажется, сделал еще один, следующий.
В команде, в которой я работаю, тесты всех уровней — от юнитов до тяжелых UI тестов пишут все: бекендеры, фронтендеры, тестировщики, аналитики. Только дизайнер-проектировщик не пишет. Но раньше писала.
Вы едете на дамп через пару недель, надо обязательно встретиться и поболтать. А на кодефесте не появитесь случайно?
Не, на codeFest не получается попасть. А можно ссылку на ваш доклад?
По поводу того, что тесты пишут все: тут как команда договорится. Как правило во всех командах аналитики как минимум могут собрать тест-кейсы из готовых шагов, но при этом новые шаги разрабатывать вообще не умеют. Чаще всего, чтоб требования не писать в отдельной доке — описывают уже тестами.
Java-разработчики не любят "программировать на русском языке". Просто это и программированием сложно назвать =).
Но когда команда нуждается в помощи из-за загруженности тестировщика, то проблем не возникало и писали тесты на ура.
Пару раз даже запускали команды без обучения тестировщика и вообще без тестировщика, так как того еще не смогли найти. И в команде автотесты писали сами разработчики. Реже всего привлекаются для этой задачи front-разработчики. Ибо js. И больше времени коммьюнити потом тратит, чтоб им объяснить и научить.
Продукт/проект не генерировал соответствующую нагрузку на автотестера.
Это на самом не проблема. При любой организации труда всегда окажется недогруженнное звено. Со стороны продакт менеджера непревычно что человек не занят ничем полезным, но это нормально. Всегда можно найти второстепенные полезные задачи.
Для нас это было проблемой, потому что стоимость разработчика автотестов не маленькая. И естественно PO заинтересован по-максимуму использовать потраченные средства.
Если бы разработчик автотестов начал бы это свободное время тратить каким-либо другим образом на пользу команде/продукту, то наверное, его незанятость не так сильно бы бросалась в глаза.
И если недозагруженность сильная и регулярная — это повод задуматься.
А еще у нас была пара автотестеров, которые оказались недовольны своей незагруженностью и просили у меня дополнительные задачи.
Но есть несколько вопросов:
1) Как вы убеждали разработку начать активно писать тесты? Или они и раньше это делали?
2) Качество тестов разработчиков как-нибудь проверяется?
3) Тестирование ковыряется с Селениумом и, прости господи, BDD. Как они определяют отсутствие дублирования проверок, которые можно автоматизировать на более нижних слоях пирамиды?
4) Если я правильно понял, то разработка один раз причесала фрейморк. А дальше она как-нибудь вообще взаимодействует с UI тестами?
Для нас это было проблемой, потому что стоимость разработчика автотестов не маленькая. И естественно PO заинтересован по-максимуму использовать потраченные средства.
Если бы разработчик автотестов начал бы это свободное время тратить каким-либо другим образом на пользу команде/продукту, то наверное, его незанятость не так сильно бы бросалась в глаза.
И если недозагруженность сильная и регулярная — это повод задуматься.
А еще у нас была пара автотестеров, которые оказались недовольны своей незагруженностью и просили у меня дополнительные задачи.
Один из примеров — старт нового продукта. Как правило, это SPA-приложение, который практически не зависим от других подобных продуктов. Пересекаться они могут только, когда происходит изменение общебанковских сервисов, которые могут затронуть много систем, но это прям исключение из правил. И такие сервисы как правило покрывают тестами, чтоб сберечь обратную совместимость.
Поэтому, первые user story могут выглядеть вообще в стиле "Отобразить кнопку для такой-то категории клиентов". При условии, что все тесты на api пишутся на уровне unit — и e2e-тестов самими разработчиками, со стороны UI нужно выполнить тесты на поведение и интеграцию UI с API. И их опять же оказывается не так много, потому что все возможные логические и алгоритмические проверки для UI-компонент тоже зашиты в модульные тесты на UI, и пишутся фронт-разработчиком.
Багрепорты у нас заводятся тестировщиком, как тикеты в jira. А чаще всего не заводятся — а сразу же правятся разработчиком после приемочного тестирования. Только если баг не критичный, то заводится. Но вопрос приоритетности/критичности принимается совместно командой.
И как тут уже сказали — то, что у вас не получилось нормально подружить всех и вся (прикрываясь красивыми терминами из scrum/agile) — не нужно говорить об этом всем что ТАК надо делать всем. Спасибо
Автоматизатор тестирования — это тупиковая ветвь развития в нашей отрасли. Эта ветвь выросла по причине высокого спроса на автоматизацию тестирования и отсутствия четкого понимания кто её должен делать.
В итоге появилась целая специализация, и к сожалению к ней часто себя относят те, кто научился как-то готовить селениум, но при этом сам не тестировщик и не разработчик. Об этом в статье правильно написано.
Сейчас понимание как делать автоматизацию постепенно приходит. И мы "с удивлением" обнаруживаем, что привлечение разработчика к этому процессу на всех этапах даёт наилучший эффект.
О чем Анастасия и написала в статье. Статья — огонь!
Автоматизатор тестирования — это, по сути, разработчик, специализируйщийся на, как ни странно, автоматизации тестирования.
Для вас основная деятельность автоматизатора тестирования — это написание автотестов или разработка инструментов автотестирования?
Порочный образ мышления, по причине которого в скрам-команде разработки все называются девелоперами и никак иначе.
Вам не нужны разработчики автотестов