Комментарии 104
Сейчас, когда метрики продукта улучшились, мы избавились от этого дежурного, но в любой момент сможем вернуть. (Пока писал статью, мы вернули его, т.к. заметили начинающуюся деградацию стабильности)
Вот именно в этом месте у Вас есть третья возможность с ужасом осознать, что групповая ответственность не работает. Первой было «это всё куда-то исчезло» с самороспуском QA. Второй — когда помогло назначение конкретного ответственного за пайплайн. После осознания, глядишь, и ванговать на два порядка не придётся.
Вы правы, если отвечают все — не отвечает никто. Мы с первого раза это осознали. Проблема в том, что починка пайплайна, его стабилизация и ускорение, не очень интересная работа, мы не нашли добровольцев, которые готовы были на 100% своего времени погрузиться в эту работу. Поэтому решили пока закрывать проблему дежурствами по необходимости. В крупных компаниях есть релизные команды, куда входят и QA инженеры. Цель этих команд катить релизы и улучшать эти процессы. Но мы пока либо не доросли до этого, либо у нас особый путь)
Мы с первого раза это осознали
Это особенно заметно по отмене дежурного за пайплайн. Типа, пожар же потушен, давайте теперь пожарную часть расформируем, зачем она. Когда в следующий раз загорится — соберём обратно, это же дёшево. Даже в википедии в определении пожарной охраны первое слово «профилактика», потом уже «тушение».
Ну и вот перечитайте свой комментарий, пожалуйста. Большинство важной работы не представляет интереса, если за неё не награждать, потому что она неблагодарная. Если в организации награждают за фичи на демо, в продукте будут только фичи, работающие только на демо. Но нет, хотим работать исключительно по фану, удивляемся результатам.
Да, мы отменяли дежурного с осознанием, что придется его вернуть снова. То что мы решаем проблему каким-то способом есть показатель что мы ее осознали.
Что вы имеете в виду под «награждать»?
Что вы имеете в виду под «награждать»?
Награда — что-либо, выдаваемое (даваемое, присваиваемое) в качестве поощрения за заслуги, отличия, в знак благодарности кем-либо за что-либо (w).
Повинность — законодательно закреплённая обязанность по выполнению общественно полезного труда (w).
Ваше дежурство по пайплайну является повинностью. Ещё раз, вы ввели дежурного чтобы что-то стало лучше. Что-то в итоге стало лучше, потом вы (кстати, кто именно?) дежурного отменили, осознавая, что его придётся возвращать. Стало обратно ухудшаться — вводим дежурного снова. Зачем было отменять дежурного, если вы знали, что что-то ухудшится обратно?
Есть великая разница в осознании факта проблемы (что-то нежелательное происходит) и самой проблемы (что конкретно происходит и почему происходящее нежелательно). «Мы как-то решаем проблему» это такой анекдот про прапорщика и пальму — «чо тут думать, трясти надо».
Ваше дежурство по пайплайну является повинностью.
Любое дежурство по природе является повинностью.
Награждение не сделает работу менее скучной и не интересной. Но вы правы, эта работа важная и нужная и делать ее кто-то должен. И обеспечить ее выполнение мы можем это несколькими способами. Или вводить отдельную команду или вводить дежурство. Может есть еще какие-то способы.
кстати, кто именно?
Наш технический директор задал вопрос, оставляем дежурного или отменяем, команды решили что можно отменить, т.к. метрики стабилизировались и по внутренним ощущениям разработчиков все стало лучше.
Зачем было отменять дежурного, если вы знали, что что-то ухудшится обратно?
Пока дежурный дежурит, он не пишет фичи, за которые нам платят клиенты и фактически выпадает из команды. Ну и как я уже говорил нет людей, которые готовы все свое рабочее время посвятить этой работе.
Есть великая разница в осознании факта проблемы...
Может мы действительно не осознали самой проблемы, а осознали пока только факт наличия проблемы. Но осознание этого — первый шаг на пути к решению проблемы.
Пока дежурный дежурит, он не пишет фичи
Вы только что написали, что какая-то часть разработчиков в процессе создания фич разламывает пайплайн. И Вы не обладаете ни средствами обнаружения таких разработчиков, ни средствами наставления их на путь истинный. Именно этими своими словами Вы натурально демотивируете своих же людей, показывая, что разламывание пайплайна приносит деньги, а его починка — нет!
У нас есть канал в слаке, куда падают уведомления о том, что пайплайн красный, в комментах автоматически тегаются люди, чьи коммиты были в этой версии кода и они идут чинить пайплайн.
А зачем у вас сначала рушится общий пайплайн у всех, а потом чинится группой подозреваемых? Почему нельзя в общую ветку MR принимать только после зеленого пайплайна по этому MR?
и как, получается отдетектить такое?
У нас есть Slack-бот, который смотрит в TeamCity, GitHub, Kaiten… и видит кто коммитил в конкретный билд и призывает их в тредах к сообщению.
Подробнее об этом боте можно почитать в статье Один бот от всех забот
Подробнее об этом боте можно почитать в статье Один бот от всех забот
ага, интересно.
У вас можно мержить MR если тесты не все зеленые?
У вас можно мержить MR если тесты не все зеленые?
Короткий ответ — нет, нельзя.
Более развернутый ответ — в dev ветку у нас нет MR, мы сразу мержим и оптимистично считаем что все мержат релизопригодный код. Если пайплайн падает, то бот призывает авторов, и они чинят тесты.
Этот же пайплайн гоняется и на релизной ветке. Релизную ветку мы сначала раскатываем на prod. На прод с красными тестами не релизим, сначала зеленим пайплайн, потом катим. А потом уже мержим PR в master.
Более развернутый ответ — в dev ветку у нас нет MR, мы сразу мержим и оптимистично считаем что все мержат релизопригодный код. Если пайплайн падает, то бот призывает авторов, и они чинят тесты.
Этот же пайплайн гоняется и на релизной ветке. Релизную ветку мы сначала раскатываем на prod. На прод с красными тестами не релизим, сначала зеленим пайплайн, потом катим. А потом уже мержим PR в master.
ясно.
Это сильно отличается от того, как у нас принято.
Каждый девелопер коммитит в фиче-ветку, которая как правило дольше 1-2 недель жить не должна.
Мержить её можно только при полном позеленении.
Это сильно отличается от того, как у нас принято.
Каждый девелопер коммитит в фиче-ветку, которая как правило дольше 1-2 недель жить не должна.
Мержить её можно только при полном позеленении.
А интегрируются в общую ветку часто? Или только когда фича готова?
фича доделана, фиче-ветка мержится в мастер и ветка навсегда удаляется, больше никогда не переоткрывается.
Всё это должно занимать не больше 1-2 недель времени _кодирования_ (со всеми прототипированиями, продумываниями и прочим, бывает и побольше конечно) и мержреквест должен быть обозрим и инспектируемым коллегами.
Если кто-то 4 недели самозабвенно писал код, то конечно никто не может это вмержить в мастер, потому как оценить последствия от таких огромных изменений нереально.
Оказывается то, что мы у себя внедрили, называется trunkbaseddevelopment.com
Всё это должно занимать не больше 1-2 недель времени _кодирования_ (со всеми прототипированиями, продумываниями и прочим, бывает и побольше конечно) и мержреквест должен быть обозрим и инспектируемым коллегами.
Если кто-то 4 недели самозабвенно писал код, то конечно никто не может это вмержить в мастер, потому как оценить последствия от таких огромных изменений нереально.
Оказывается то, что мы у себя внедрили, называется trunkbaseddevelopment.com
Да, это все правильно. Единственное что мне сразу бросается в глаза это время жизни ветки. 1-2 недели это долго. На trunkbaseddevelopment.com есть раздел "short-lived-feature-branches" и там они пишут
"One key rule is the length of life of the branch before it gets merged and deleted. Simply put, the branch should only last a couple of days. Any longer than two days, and there is a risk of the branch becoming a long-lived feature branch (the antithesis of trunk-based development)."
у нас всё таки немножко специфика: задачи бывают сложные. Делали бы магазин/вебпроект, там задачи лучше дробятся и прогнозируются.
Думаю, если делать доплату 50% за дежурство, то очередь будет из желающих. И дежурство станет наградой. Например, дежурит тот, кто меньше всего ломал пайплайн. А значит умеет с ним обращаться)
У меня стойкое ощущение, что «релизные команды» — это всё как раз от страха того, что не выстроен процесс жизни без них.
Коллеги, очень советую использовать метод пяти почему и прочитать книгу: Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию.
Они вам помогут организовать процессы в вашей компании.
А еще найдите грамотного QA, я думаю вы уже стали большими и вам уже нужен отдельный специалист по качеству.
Они вам помогут организовать процессы в вашей компании.
А еще найдите грамотного QA, я думаю вы уже стали большими и вам уже нужен отдельный специалист по качеству.
Да, спасибо за советы, они на самом деле полезные. Цель прочитал не так давно и сейчас осознаю, что когда регрессионное тестирование тормозило релизы, мы пользовались этими знаниями, чтобы ускорить наши релизы. Например, освободили тестировщиков от любой работы не связанной с тестированием релизов, ввели правило Stop The Line когда разработчики не могли создавать новые задачи, чтобы не копить очередь. У нас об этом есть статья.
А что касается грамотного QA, если поделитесь контактами, будет очень здорово. Мы бы с удовольствием его наняли. А пока приходится через боль и страдания проходить по всем граблям.
А что касается грамотного QA, если поделитесь контактами, будет очень здорово. Мы бы с удовольствием его наняли. А пока приходится через боль и страдания проходить по всем граблям.
Да, спасибо за советы, они на самом деле полезные. Цель прочитал не так давно и сейчас осознаю, что когда регрессионное тестирование тормозило релизы, мы пользовались этими знаниями, чтобы ускорить наши релизы.
Регрессионное тестирование не может тормозить релиз. Оно не для этого сделано.
Например, освободили тестировщиков от любой работы не связанной с тестированием релизов, ввели правило Stop The Line когда разработчики не могли создавать новые задачи, чтобы не копить очередь. У нас об этом есть статья.
Я ее прочел. Применяйте пять почему и почитайте про релизный менеджмент. Есть общепринятый набор терминов, лучше следовать им. И вы не очень поняли зачем делается код фриз…
А что касается грамотного QA, если поделитесь контактами, будет очень здорово. Мы бы с удовольствием его наняли. А пока приходится через боль и страдания проходить по всем граблям.
Напишите Сергею Мартыненко
Его сайт: blog.shumoos.com
Настоятельно рекомендую к ознакомлению
Регрессионное тестирование не может тормозить релиз. Оно не для этого сделано.
Вот только не весь менеджмент это понимает :-)
Я неправильно выразился. Регрессионное тестирование не тормозит релизы само по себе. Я имел в виду, что регрессионное тестирование было бутылочным горлышком нашего релизного цикла.
Про релизный менеджмент почитаю, если кинете в меня толковой книгой буду благодарен.
Можете рассказать зачем?
Блог Сергея недавно открыл для себя, потихоньку изучаю.
Про релизный менеджмент почитаю, если кинете в меня толковой книгой буду благодарен.
И вы не очень поняли зачем делается код фриз
Можете рассказать зачем?
Блог Сергея недавно открыл для себя, потихоньку изучаю.
Я имел в виду, что регрессионное тестирование было бутылочным горлышком нашего релизного цикла.
Вы не успевали его полноценно делать, оно тормозило или очень хотелось релизить фичу, но релиз пребывал в состоянии "аль денте"?
На самом деле в процессе чтения статьи я не мог отделаться от мысли, что бизнес достаточно сильно давит на разработку и процесс весьма сильно разбалансирован. По крайней мере разработчики, которых не интересует качество продукта — это такой весьма заметный и большой красный флаг, обычно такое бывает на разного рода галерах, где главное фичу отгрузить в минимально работоспособном состоянии, а дальше или менеджеры утрясут вопросы и будет заказа на доработку, или клиент отвалится и черт бы с ним, все равно деньги уже получены.
Вы не успевали его полноценно делать, оно тормозило или очень хотелось релизить фичу, но релиз пребывал в состоянии «аль денте»
Мы успевали его делать, но делали это дольше, чем хотелось бизнесу. Точнее так, весь процесс доставки фичи занимал много времени, а бизнес всегда хочет доставить фичу как можно быстрее (при прочих равных)
бизнес достаточно сильно давит на разработку
Давление есть, но это здоровое давление, от которого никуда не деться. Оно больше исходит от необходимости бизнеса развиваться, расти, успевать или обгонять конкурентов.
разработчики, которых не интересует качество продукта...
Если из моей статьи вы сделали вывод, что наших разработчиков не интересует качество продукта, значит я что-то упустил или криво сформулировал (shame on me), потому что наши разработчики заинтересованы в качестве продукта.
Чтобы избавиться от бутылочного горлышка в виде регресса, надо не отказываться от него как такового, а применять адекватные техники по созданию пака на регресс, не забывать про эффект пестицида, импакт анализ и пирамиду автотестирования. Плюсом можно действительно заняться качеством процесса и архитектурой системы.
Мы отказались от ручного регресса, автоматические тесты с покрытыми критичными сценариями из регресса ходят после каждого коммита в общую ветку. Т.е. от самого регресса мы не отказывались, а свели его к прохождению автотестов.
> Пропала компетенция написания автотестов
Можете пояснить, почему пропала компетенция написания автотестов? Я так понимаю, что в QA отделе были люди с этой компетенцией. Они уволились?
Можете пояснить, почему пропала компетенция написания автотестов? Я так понимаю, что в QA отделе были люди с этой компетенцией. Они уволились?
Да, изначально были люди с этой компетенцией и они написали существующий набор автотестов. Потом один человек уволился, остальные пошли заниматься кто продуктовым менеджментом, кто разработкой, а кто скрам мастерством.
А написали бы нормально, «Мы разучились писать автотесты», а не «пропала компетенция» — может и корень проблемы был бы виден сразу. Люди уволились, писать стало некому и незачем — им за это теперь не платят. Откуда этот новомодный канцелярит?
Мы подумали про автотесты — передадим их разработчикам и они будут сами тестировать без проблем.
А тест-планы тоже разработчики прорабатывают и составляют, на основе которых пишутся автотесты?
Тест-план — это очень уж высокоуровневый документ для использования его для написания автотестов. Возможно, имелись в виду тестовые спецификации и тестовые процедуры?
Давайте я попробую сформулировать свой вопрос с более практической точки зрения. Разработчик в рамках задачи реализовал какую-то новую фичу в проекте, например в рамках требования от бизнеса. После этого ему нужно написать автотест (согласно повествованию в статье). Для того чтобы написать автотест, как мне кажется, должен существовать какой-то план тестирования этой фичи. Конечная же задача чтобы выполнялось требование от бизнеса. Далее на основе плана пишется код автотеста. Если это так, то кто составляет план и кто верифицирует что план верный? И есть ли какое-то ревью теста?
Для того чтобы написать автотест, как мне кажется, должен существовать какой-то план тестирования этой фичи.
Тестовый план — это документ, определяющий более глобальные моменты, что будет тестироваться, какие виды тестов, критерии начала, критерии окончания и т. п. Тестовая спецификация — это уже набор конкретных тестовых случаев, но обычно всеобъемлющий по продукту, для удобства можно уже составлять тестовые сьюты, которые тоже содержат в себе тест-кейсы, но могу формироваться более произвольно. И наконец — собственно тестовые случаи, которые и автоматизируют. Вот тест-кейсы обычно ревьювят другие тестировщики, но могут и продакт овнеры, и бизнес-аналитики, и разработчики (в целом — чем больше ревьюверов — тем лучше).
Вы придираетесь к формулировкам и не отвечаете по существу. Суть вопроса верная: делается ли анализ и составляются ли тест-кейсы перед автоматизацией?
Вы придираетесь к формулировкам
Чтобы быть уверенным, что мы точно говорим об одной и той же вещи. Я был на проекте, к примеру, где чек-листы называли тесткейсами. Не то чтобы критично, но это регулярно мешало взаимопониманию.
Суть вопроса верная: делается ли анализ и составляются ли тест-кейсы перед автоматизацией?
Должны делаться. А так — от проекта зависит, конечно.
Чем вас от этот вот ответ не устроил?
Вот тест-кейсы обычно ревьювят другие тестировщики, но могут и продакт овнеры, и бизнес-аналитики, и разработчики (в целом — чем больше ревьюверов — тем лучше).
QA инженеры составляют приемочные критерии к каждой задаче вместе с Владельцем продукта и с разработчиками. Затем QA инженеры в командах берут конкретные задачи смотрят на эти приемочные критерии и составляют тест-кейсы для фичи и отмечают какие кейсы должны быть автоматизированы.
Тест план и тест стратегия – это всё-таки не тождественные вещи, план можно (а иногда и нужно) составлять хоть на каждый спринт (итерацию).
Согласен, стратегия еще более высокий уровень абстракции. Но составлять тестовый план на каждый спринт? Мне кажется перебор, лучше на каждый релизный цикл. Впрочем это конечно от проекта зависит.
Под спринтом имел в виду ситуацию, при которой в конце спринта что-то уезжает на прод.
В классическом скраме в конце каждого спринта создаётся что-то новое, что готово к релизу. По каким-то соображениям оно может не релизиться, но должно быть готово. Включая включение в общие тестовые планы продукта.
Есть несколько вариантов структур управления, один из них — «матричная структура управления». Скорее всего у вас «QA Engineer» в команде должен иметь «двойное подчинение» — команде/тимлиду и «QA Tech Lead». Так вы сможете получить и максимальную интеграцию QA в разработку и единого ответственного за организацию QA в компании.
Вы правы. Недавно на нашем гитхабе выложили структуру IT и там как раз матричная структура, к которой мы будем идти.
Как мы «разогнали» команду QA
Всё, что надо знать
О том, как разработчики строят IT в Dodo
Спасибо что написали. Статьи и выступления про неудачный опыт иногда полезнее рассказов про удачные решения.
Прекрасная статья, которую также можно было бы назвать «недостатки ИТ образования в РФ и как мы изобретаем велосипед с опозданием на 20 лет». Предлагаю погуглить силабус курса по QA какого-нибудь адекватного университета(MIT например), взять от туда список литературы и дать почитать своему менеджменту. У меня всегда горело с профессионального уровня российского тестирования, судя по всему вы решили зайти на очередной круг, который уже проходили в году так 2010 многие отечественные «ИТ гиганты» :) Хотя чему удивляться, все адекватные специалисты спешно покидают родину все последние годы, а потом тилиды с опытом 3 года и менеджеры проектов по верстке лендингов, встают к рулю.
Фактически вы нарушили все подходы по SDLC и оно внезапно не взлетело, «вот это поворот, вот это поворот...»
Фактически вы нарушили все подходы по SDLC и оно внезапно не взлетело, «вот это поворот, вот это поворот...»
Потому что разработчики получали обратную связь слишком поздно.
Баги находились на этапе, когда уже вся разработка «закончена», всё «интегрировано» и нужно проверить, что продукт готов к релизу.
..
Сказывается и наш поход в сторону отпила микросервисов от монолита. В монолите становится меньше тестов, и все больше в отдельных репозиториях, пайплайн становится стабильнее.Понятно, что тестировать «котлетку» проще когда она вот свеженькая с огня, чем когда она уже запихана в гамбургер и упакована в коробочку.
Т.е. у вас был водопад. Понятно, что вам хотелось сделать т.н. «shift-left».
Но решение, на мой взгляд, не соответствует задаче. Вы заставили тех, кто жарит котлетки еще и проверять их, а если они не проходят тесты — то откладываем их в сторону (мутим тест) и делаем новую котлетку. Еще и придумываем новые тесты для котлетки. А отгружать котлетки надо с той же скоростью что и раньше. Ну ведь понятно, что в таких условиях серьезного подхода к обеспечению качества не будет. Где тот человек который будет смотреть на процесс создания котлеток и скажет, так, плиту надо передвинуть, купим фаршефасовочную установку чтобы котлетки были все одинакового веса. Будем проверять фарш на консистенцию до поступления на кухню. И т.д., и т.п. В качестве упражнения спросите себя, что, кто и как влияет на качество продукта.
Судя по избранному пути вы, как мне представляется эта картина, на самом деле хотели сэкономить на кадрах и просто внушили себе, что это решит проблему.
На самом деле проблема в структуре организации, схеме интеграции, архитектуре приложения, поэтому оно не поддается частичному тестированию. Так эту проблему и надо решать. Зачем убирать выделеных тестировщиков? Ведь они заинтересованое лицо. А разработчик лицо не заинтересованое.
Почему разработчики «плохие» тестировщики? Поверьте, у разработчиков очень хорошо с логикой они отлично могут погрузить себя в роль «хакера». Но им не до этого. Потому что надо пилить. Не одному здравомыслящему человеку не придет в голову работать себе во вред.
А выделеный тестировщик — лицо заинтересованое. Ему платят, в конце концов, за то, чтобы он был таким «противовесом» и ничему не верил на слово. Получается здоровое противоборство умов.
А когда тестированием занимаются разработчики у нас возникает банальный конфликт интересов. Тесты им реально мешают. И получается, когда они сами этими тестами управляют, они сделают в конце концов так, чтобы они им не мешали. Приспособятся. У вас будут зеленые тесты и баги на проде.
Я знаю команды, которые за красные тесты дрючат. Так там такое в тестовом коде найдешь, что стыдно вслух сказать. Заглушенные тесты до фикса бага в продукте ещё самое безобидное.
Поясню еще раз для всех: глушить тесты нельзя, по простой причине — они перестают указывать на проблему. А это их, собственно, первоочередное назначение. В любое время дня и ночи. Узелок на память, если хотите.
Т.е. исходя из этого дуализма логично было бы хотя бы разделить для разработчиков фазу «ваяния» и фазу «созерцания» сотворенного. Или передавать по кругу. Художник ведь тоже отходит от картины, чтобы посмотреть что получилось. Мы, например, делали еженедельные воркшопы по тестированию, заводили баги, и в следующие три дня их решали. На этих воркшопах такие баги «вытряхивали» иногда — мама не горюй. Но нужен человек который будет этот процесс сопровождать. Если предоставить их самим себе, эффективности будет на первых порах мало.
Можно делить команду и воркшоп делают двое а трое «на службе», потом меняются чтобы было противоборство. Это будет давать интеллектуальный запал. Кто кому больше багов найдет. И скорборд повесить в кабинете. Там такое начнется.
Спасибо за коммент, с многим согласен. Особенно с «плохими» программистами и «заинтересованными» тестировщиками. Всем своим работодателям это говорил пока сам тестил.
> Можно делить команду и воркшоп делают двое а трое «на службе», потом меняются чтобы было противоборство.
Мы пробывали такое сделать, правда без скор-борда (мне бы точно не помогло, т.к. я не воспринимаю информацию «вне», когда я работаю, мне джира удобнее). Некоторые во время «дежурства» просто читали новости 5 часов в день. Но я должен сказать что ни кнута ни пряника за фикс багов не было.
> Можно делить команду и воркшоп делают двое а трое «на службе», потом меняются чтобы было противоборство.
Мы пробывали такое сделать, правда без скор-борда (мне бы точно не помогло, т.к. я не воспринимаю информацию «вне», когда я работаю, мне джира удобнее). Некоторые во время «дежурства» просто читали новости 5 часов в день. Но я должен сказать что ни кнута ни пряника за фикс багов не было.
Все правильно написано. Поддерживаю.
Мне прям понравилась аналогия с бургерами. Аналогия с пиццей была бы еще лучше)
QA инженеры пошли в команды разработки, чтобы в рамках конкретной команды смотреть как жарятся котлетки, помогать командам жарить эти котлетки и проверять качество этих котлеток до упаковки.
Разработчики пишут автотесты, но на какие сценарии писать подсказывает QA инженер. И зачастую тестирует тоже QA инженер, но иногда могут потестировать разработчики. Но от QA инженера есть сценарии как это нужно тестировать.
Что касается игнора тестов, я тут тоже согласен с вами, нельзя игнорить тест, если он не проходит по какой-то причине, нужно разобраться и починить эту проблему.
QA инженеры пошли в команды разработки, чтобы в рамках конкретной команды смотреть как жарятся котлетки, помогать командам жарить эти котлетки и проверять качество этих котлеток до упаковки.
Разработчики пишут автотесты, но на какие сценарии писать подсказывает QA инженер. И зачастую тестирует тоже QA инженер, но иногда могут потестировать разработчики. Но от QA инженера есть сценарии как это нужно тестировать.
Что касается игнора тестов, я тут тоже согласен с вами, нельзя игнорить тест, если он не проходит по какой-то причине, нужно разобраться и починить эту проблему.
До боли все знакомо с этой ситуацией и с идеями «короткой обратной связи» (как будто критический баг с полным набором логов не достаточно сильная обратная связь). Мне вот только интересно в новом подходе, когда разрабы сами пишут автотесты:
— где они для этого находят время (а времени на это прилично уходит)?
— не лукавят ли они, тестируя свой продукт? могут ли «незамыленно» и разносторонне проверять?
— кто следит за развитием фреймворка? или каждый пилит свой?
Как-то часто не осознают, что проект автотестов может быть сложнее, чем продукт, который он тестирует. И подходы к его разработке и поддержке на практике являются такими же, как к разработке отдельного продукта. Со своим инструментарием и внутренним контролем качества.
Статья полезная и показательная. Жаль руководители, которые иногда принимают кардинальные решения, такие статьи не читают.
— где они для этого находят время (а времени на это прилично уходит)?
— не лукавят ли они, тестируя свой продукт? могут ли «незамыленно» и разносторонне проверять?
— кто следит за развитием фреймворка? или каждый пилит свой?
Как-то часто не осознают, что проект автотестов может быть сложнее, чем продукт, который он тестирует. И подходы к его разработке и поддержке на практике являются такими же, как к разработке отдельного продукта. Со своим инструментарием и внутренним контролем качества.
Статья полезная и показательная. Жаль руководители, которые иногда принимают кардинальные решения, такие статьи не читают.
- На PBR-е в задаче уже написано что должно быть покрыто автотестами и разработчики знают что нужно покрывать они учитывают это в объеме задачи когда затягивают к себе в бэклог
- Для этого нужен QA в команде, который будет увеличивать разносторонность тестирования и смотреть свежим взглядом на фичу, используя свои знания из области тестирования и знание продукта
- Вот с этим пока беда. По сути никто. Поэтому сейчас есть дублирование функций, разные подходы в разных местах. Но мы идем к тому, чтобы QA комьюнити забрало себе владение этим фреймворком и его развитие.
На PBR-е в задаче уже написано что должно быть покрыто автотестами и разработчики знают что нужно покрывать они учитывают это в объеме задачи когда затягивают к себе в бэклог
Разработчики пишут юниты, интеграционные или e2e-тесты?
Разработчики пишут все виды тестов, которые необходимы для тестирования фичи.
После такого ответа стало интересно, какой процент от задачи занимает написание тестов.
Задал вопрос своей команде ответил пока один человек, поэтому процитирую его ответ
Тесты от unit- и до интеграционных, не покидающих кода сервиса (in-memory репозиторий — да, sqlite вместо mysql — нет) у нас часто пишутся по TDD, поэтому оценить временные затраты сложно — нет отдельной таски. Бывает, что для теста нужно написать 100500 строк тупого кода вроде DSL, бывает, что нужно выносить дублирующийся код из самих тестов в какие-то отдельные конструкции. Я бы сказал, что отношение времени чистой разработки к написанию unit-тестов — 50/50 с легким уклоном в тесты.
Тесты, работающие с SUT как с black-box (хоть по HTTP API или шине, хоть через UI), тоже бывают разные. Где-то нужно переиспользовать готовые шаги и чуть-чуть поменять when'ы, а где-то нужно писать целые PageObject'ы (и иногда вносить изменения в сервис, потому что тот не готов тестироваться автоматически). Относительное время я точно не скажу, а по абсолютному — от полудня до двух-трех дней плюс-минус трамвайная остановка (большой разброс)
Все не очевидные последствия в данной ситуации изумительно лечатся депримированием и снятием опционов с менеджмента (предложивших / согласовавших) разогнать QA, года на 1.5-2 точно хватит с запасом
Классика непонимания что такое QA, и чем этот отдел занимается вообще. В двух словах этот отдел — это фильтр между разработчиками и клиентами. Все эти тесты это просто инструменты для этого отдела. Если от QA приходит вердикт, релиз нельзя отправлять в прод из-за ошибок, то это решение никто не может оспорить, ни PM, ни Big Boss, вообще никто. И нарушение ведет как правило не только к денежным, но и репутационным потерям.
Ну и как обычно проблемы с пониманием времени которое нужно для проверки новой функциональности. Например есть фича на разработку которой ушло 100 часов, так вот для проверки этой фичи нужно не меньше 100 часов. И для того чтобы фича появилась не через 200 часов — после разработки и тестирования делают просто — QA начинает разработку тестов для фичи одновременно(или чутка раньше) с разработкой фичи.
Ну и как обычно проблемы с пониманием времени которое нужно для проверки новой функциональности. Например есть фича на разработку которой ушло 100 часов, так вот для проверки этой фичи нужно не меньше 100 часов. И для того чтобы фича появилась не через 200 часов — после разработки и тестирования делают просто — QA начинает разработку тестов для фичи одновременно(или чутка раньше) с разработкой фичи.
Да, все правильно, поэтому и приняли такое решение пойти в команды и покрыть регресс автотестами, чтобы была возможность начинать раньше обеспечивать качество продукта.
Например есть фича на разработку которой ушло 100 часов, так вот для проверки этой фичи нужно не меньше 100 часов.
Кстати вообще не факт, наблюдал как фичи длинной в 80 часов можно было протестировать за 2 часа(включая документирование тест-кейсов и результатов), и как фичи длинной в 4 часа приходилось тестировать 40 часов(даже после применения всем методик, которые уменьшают количество требуемых тестов), так то во многом зависит от самой фичи и от того, какую часть продукта она затрагивает.
Вот чтобы это все не вычислять и не угадывать, берут такое же значение или больше для просчета сколько надо времени на тестирование фичи. А коэффициент этот как правило высчитываться из размера отдела QA. Не забываем что есть если ошибки которые сложно воспроизвести или обнаружить причину возникновения ошибки или же просто ошибка проявляет себя в 1% случаев
На все команды не хватило QA-инженеров.А как вы хотели, если у вас на одного тестировщика приходится аж 17 разработчиков?! (proof)
это хорошая практика, когда вся команда и разработчики и тестировщики могут писать тестыНет. Как любил повторять Генри Форд, «каждый должен заниматься своим делом, и достигать в нем высокого мастерства».
Вообще говоря, странно, что компания с почти 10-летней историей никак не может нащупать свой правильный путь.
А как вы хотели, если у вас на одного тестировщика приходится аж 17 разработчиков?!
С того момента у нас вышло 2 QA инженера, поэтому отношение изменилось)
Плюс открыты 3 вакансии и когда мы всех наймем опять ситуация будет другая.
Нет. Как любил повторять Генри Форд, «каждый должен заниматься своим делом, и достигать в нем высокого мастерства».
Может быть. Но Генри Форд жил давно, когда не было компьютеров и индустрии разработки ПО. Приведу абзац текста из книги Continuous Integration: Improving Software Quality and Reducing Risk
In many organizations where automated functional testing is done at all, a
common practice is to have a separate team dedicated to the production and
maintenance of the test suite. As described at length in Chapter 4, “Implementing
a Testing Strategy,” this is a bad idea. The most problematic outcome is that the
developers don’t feel as if they own the acceptance tests. As a result, they tend
not to pay attention to the failure of this stage of the deployment pipeline, which
leads to it being broken for long periods of time. Acceptance tests written without
developer involvement also tend to be tightly coupled to the UI and thus brittle
and badly factored, because the testers don’t have any insight into the UI’s underlying
design and lack the skills to create abstraction layers or run acceptance tests
against a public API.
The reality is that the whole team owns the acceptance tests, in the same way
as the whole team owns every stage of the pipeline. If the acceptance tests fail,
the whole team should stop and fix them immediately.
Авторы считают, что нужно привлекать разработчиков к написанию тестов.
А разработчики у вас случайно не админят сервера? Если сказать коротко, то для QA, разработки, админства надо чтобы мозги работали по разному. Вот поэтому тут и не работает принцип «швец, жнец и на дуде дудец».
Нет, сервера они не админят. Хотя опыт перехода целой команды разработки в инфраструктуру у нас был и разработчики стали инженерами инфраструктуры.
А можете подробнее рассказать почему должны работать по-разному мозги QA, разработчика и инженера инфраструктуры, в чем разность?
А можете подробнее рассказать почему должны работать по-разному мозги QA, разработчика и инженера инфраструктуры, в чем разность?
Ну это очень просто. Задача разработчика создать что-то. Задача QA проверить то что создал разработчик на соответствие каким-то критериям. По сути же задача QA сводиться к тому, чтобы проверить «на прочность», найти способ как сломать. Если разработчик по сути зажат рамками системы в которой он что-то разрабатывает, то QA наоборот действует на эту систему из вне. И проверяет не только новую функциональность, но и саму систему.
Поэтому и выходит что когда разработчик создает тесты, то он просто не выходит за рамки системы (по сути для него тест это просто другой кусок существующей системы), а так же он создает тест чтобы тот был зеленый в большинстве случаев. QA же создает тест за пределами системы(он просто не знает систему), а так же тест создает чтобы тот не был зеленым.
Инфраструктурщики это как разработка кода наживую на проде, с живыми миграциями данных, с кучей планов (что делать если что-то пошло не так) + от QA постоянное «недоверие» и «перепроверка» всего что связанно с системой.
Под системой имеется в виду полностью все что связанно с ПО — спецификации, архитектура, библиотеки, инфраструктура.
Да переходы есть и это довольно частое явление, переключить мозги на постоянку не проблема. Да это все по сути инженерия, но специфика разная.
Пишу это все на основе своего опыта, занимался и автоматизацией в QA, и разработкой и админством.
Поэтому и выходит что когда разработчик создает тесты, то он просто не выходит за рамки системы (по сути для него тест это просто другой кусок существующей системы), а так же он создает тест чтобы тот был зеленый в большинстве случаев. QA же создает тест за пределами системы(он просто не знает систему), а так же тест создает чтобы тот не был зеленым.
Инфраструктурщики это как разработка кода наживую на проде, с живыми миграциями данных, с кучей планов (что делать если что-то пошло не так) + от QA постоянное «недоверие» и «перепроверка» всего что связанно с системой.
Под системой имеется в виду полностью все что связанно с ПО — спецификации, архитектура, библиотеки, инфраструктура.
Да переходы есть и это довольно частое явление, переключить мозги на постоянку не проблема. Да это все по сути инженерия, но специфика разная.
Пишу это все на основе своего опыта, занимался и автоматизацией в QA, и разработкой и админством.
Тестирование — это не сервера. Тестирование — это убедится в качестве своей же работы. Я сам себе пишу тесты, чтобы быть уверенным в качестве моей работы. Потому что бесконечное перекидывание задачи между программистом, который за собой не проверяет, и тестировщиком, который каждый раз находит новые баги, в итоге только увеличивает время на выполнение задачи.
У меня супруга тестировщик — говорит: максимальный фейс-палм у тестировщика вызывает, когда на тестирование отдают фичу, которая не делает то, для чего она создавалась. Возникает вопрос — ты задеплоил и не можешь ткнуть три кнопки, что оно просто работает? Не в силах проверить — прошел ли вообще деплой и вообще тот ли комит ты задеплоил? А тестировщику надо все это верифицировать, проверить стабильно ли воспроизводится, описать и вернуть таску обратно.
Да я балансирую на грани сроков и объема тестирования, да у меня замылен глаз. Но я лучше знаю свой код. Я пишу тесты, которые покрывают основные моменты. Они сокращают мне время на проверку моей же работы. Я становлюсь более уверенным в своем коде. Я сокращаю шансы что-то случайно поломать в другом месте. В конце-концов — тесты помогают мне ставить на место токсичных членов команды, которые во всех проблемах винят других, но только не себя. Со временем вся команда понимает, что мой код стабилен и, в основном, свободен от багов. И начинают смотреть сначала у себя. Это вот прям реально такое было.
Если же мне в помощь дадут еще одного человека QA-автотестера — вместе мы горы свернем. Потому что он более независим, у него не замылен глаз, свежие мозги и есть время подумать над другими тест-кейсами. Но рано или поздно я поймаю эти кейсы и просто сам допишу тест, если что.
Поэтому вот это все «программист не должен писать тесты» — означает, что программисту посрать на проект и на команду. Он скидывает с себя ответственность за свою же работу. Чаще всего есть оправдание — менеджмент закидывает задачами, как золотая антилопа того чувака на лестнице.
У меня супруга тестировщик — говорит: максимальный фейс-палм у тестировщика вызывает, когда на тестирование отдают фичу, которая не делает то, для чего она создавалась. Возникает вопрос — ты задеплоил и не можешь ткнуть три кнопки, что оно просто работает? Не в силах проверить — прошел ли вообще деплой и вообще тот ли комит ты задеплоил? А тестировщику надо все это верифицировать, проверить стабильно ли воспроизводится, описать и вернуть таску обратно.
Да я балансирую на грани сроков и объема тестирования, да у меня замылен глаз. Но я лучше знаю свой код. Я пишу тесты, которые покрывают основные моменты. Они сокращают мне время на проверку моей же работы. Я становлюсь более уверенным в своем коде. Я сокращаю шансы что-то случайно поломать в другом месте. В конце-концов — тесты помогают мне ставить на место токсичных членов команды, которые во всех проблемах винят других, но только не себя. Со временем вся команда понимает, что мой код стабилен и, в основном, свободен от багов. И начинают смотреть сначала у себя. Это вот прям реально такое было.
Если же мне в помощь дадут еще одного человека QA-автотестера — вместе мы горы свернем. Потому что он более независим, у него не замылен глаз, свежие мозги и есть время подумать над другими тест-кейсами. Но рано или поздно я поймаю эти кейсы и просто сам допишу тест, если что.
Поэтому вот это все «программист не должен писать тесты» — означает, что программисту посрать на проект и на команду. Он скидывает с себя ответственность за свою же работу. Чаще всего есть оправдание — менеджмент закидывает задачами, как золотая антилопа того чувака на лестнице.
Тестирование — это убедиться что что-то соответствует каким-то требованиям. Как правило эти требования размазаны по куче документов. И как правило в ТЗ к какой-то фиче или в баг репорте никто не вписывает параметры которые используют при Load Testing или Stress Testing, даже если и впишут то разработчик не будет их проверять или не сможет создать такую нагрузку. И таких требований которые не знают разработчики на самом деле очень много.
Ваши требования к вашей работе тут не причем.
Вот как раз порядок что QA постоянно находит какие-то баги и отправляет на доработку код — это нормально, неприятно, но нормально.
А потом бах случается какой-то баг и никто не смотрит в ваш код, он же покрыт тестами. Хоть и плохо и поверхностно
Ваши требования к вашей работе тут не причем.
Вот как раз порядок что QA постоянно находит какие-то баги и отправляет на доработку код — это нормально, неприятно, но нормально.
Со временем вся команда понимает, что мой код стабилен и, в основном, свободен от багов. И начинают смотреть сначала у себя. Это вот прям реально такое было.
А потом бах случается какой-то баг и никто не смотрит в ваш код, он же покрыт тестами. Хоть и плохо и поверхностно
Я пишу тесты, которые покрывают основные моменты.А потом оказывается что баг был в этом самом коде, и на его поиски ушло в сто раз больше времени. QA это всегда недоверие ко всем тестам и ко всему коду, поэтому всегда тесты прогоняют с начала и все. А еще есть баги в архитектуре/спецификации например, которые тестами никак не вылавливаются. Есть еще и баги в тестах :)
Тестирование — это убедиться что что-то соответствует каким-то требованиям. Ваши требования к вашей работе тут не причем.
Ну а программист разве не кодит фичу, чтобы она выполняла требования? И как он потом понимает, что он все сделал правильно? И почему мои требования к себе не причем? Т.е. если программист не требует от себя правильно кодить фичи — это проблема всех остальных, но не лично его? Наверное где-то есть идеальные программисты, которым не нужны тесты, но я пока таких не встречал.
Вот как раз порядок что QA постоянно находит какие-то баги и отправляет на доработку код — это нормально, неприятно, но нормально.
Но не нормально, когда к QA приходит отмашка от программиста «все готово», а там вообще ничего не готово. От слова совсем. Это подстава со стороны программиста, которая говорит о его отношении к проекту и команде. Даже если его завалили задачами — сделать смок тестирование перед отправкой таска на тестирование сокращает время разработки. И бизнесу, который платит ему зарплату, это только в плюс.
А потом бах случается какой-то баг и никто не смотрит в ваш код, он же покрыт тестами.
А потом оказывается что баг был в этом самом коде, и на его поиски ушло в сто раз больше времени.
Так стоп «начинают смотреть сначала у себя» != «смотреть ТОЛЬКО у себя». Начинают другие, чисто по теории вероятности, если не нашли — идут ко мне. Если бага в итоге у меня — я дописываю тест.
Такое ощущение, что у вас теоретическое представление о программистах и процессах разработки.
С требованиями там все просто, разработчику требования приходят переработанные PM-ом, Tech или Team Lead-ом. QA же работает с требованиями от бизнеса или клиентов, которые технически не всегда грамотные. И то что вы идеально сделали фичу по ТЗ — это хорошо, но это ТЗ может содержать ошибки или не точности.
Покрытие кода тестами на 10%(и только кода одного разработчика) — с точки зрения QA это тоже самое что отсутствие этих самых тестов вообще. Поэтому в Вашей ситуации это просто усиливает ваш аргумент «идите смотрите у себя, у меня все ок».
Это только ощущение.
Тема разработчик и QA сложная и холиварная, и с той и с той стороны есть куча косяков. Я побывал и на той и на той стороне «баррикад», и админил еще в придачу.
Покрытие кода тестами на 10%(и только кода одного разработчика) — с точки зрения QA это тоже самое что отсутствие этих самых тестов вообще. Поэтому в Вашей ситуации это просто усиливает ваш аргумент «идите смотрите у себя, у меня все ок».
Такое ощущение, что у вас теоретическое представление о программистах и процессах разработки.
Это только ощущение.
Тема разработчик и QA сложная и холиварная, и с той и с той стороны есть куча косяков. Я побывал и на той и на той стороне «баррикад», и админил еще в придачу.
С требованиями там все просто, разработчику требования приходят переработанные PM-ом, Tech или Team Lead-ом. QA же работает с требованиями от бизнеса или клиентов, которые технически не всегда грамотные.
Большинство компаний/сотрудников только мечтают об этом. Обычно есть босс + программист, в лучшем случае босс + аналитик/тестировщик + программист.
Полный набор редко у кого встретишь и лично я в таких компаниях не работал.
И у всех компаний акцент на чем-то — у кого-то сильный менеджмент, у кого-то программисты, у кого-то тестировщики, у кого-то техподдержка. Кстати в одной шведской компании с сильными акцентом на тестирование в итоге внедрили промежуточный этап — программист деплоит себе свою таску и тестит сам, и только после этого имеет право перевести задачу на отдел тестирования.
Покрытие кода тестами на 10%
С чего вы решили, что в моей ситуации это было 10? А не 50 или 80?
В одной крупной компании в которой я работал, разработчикам выдавалась лицензия на софт для домашнего использования (пром система документооборота и фин учета), чтобы сотрудники дома бухгалтерию и документы вели в этой системе. И при этом был полноценный QA отдел.
Хорошо, Ваш код покрыт тестами. Вы контролируете качество своей работы.
Хорошо, Ваш код покрыт тестами. Вы контролируете качество своей работы.
Полностью согласен. С другой стороны мы (программисты) не специалисты по тестированию и не всегда можем или хотим придираться к каждой мелочи.
Я считаю правильным решением было бы если бы после того как продакт пишет описание фитчи, перед тем как она попадает к разработчику тестировщик должен описать все Acceptance Tests которые явсляются неотъемлемой частью фитчи. Это конечно же не отменяет всех остальных видов тестов, которые разработчики должны писать для проверки своего кода.
Я считаю правильным решением было бы если бы после того как продакт пишет описание фитчи, перед тем как она попадает к разработчику тестировщик должен описать все Acceptance Tests которые явсляются неотъемлемой частью фитчи. Это конечно же не отменяет всех остальных видов тестов, которые разработчики должны писать для проверки своего кода.
НЛО прилетело и опубликовало эту надпись здесь
Ликвидировать централизованный ручной QA в компании — это терять самую трудно нарабатываемую экспертизу.
Гуру Спринта или Реакта вы наймёте за соответствующие деньги. А где вы наймёте гуру ВашегоПродукта? А ведь QA — это архетип power user'а. Опытного пользователя, который всё знает и всё умеет. Который точно знает как оно должно быть и как оно не должно быть (и почему). Опытный QA — это эксперт в вашем продукте. Самый главный эксперт. Может быть, даже единственный, кто понимает, как все эти куски друг с другом стыкуются и почему именно так.
Утрата экспертизы в своём собственном продукте — это едва ли не хуже, чем дружное увольнение всей комады разработки.
Да, экспертизу в продукте с улицы не купишь. Но в нашем случае экспертиза в продукте не делась никуда, мы остались в компании и остались в своем продукте, просто стали ближе к разработке
Согласен, еще QA хорошо бы работать в поддержке или хотя бы читать тикеты. У меня супруга работала на стыке аккаунт менеджера и QA. Он видела все боли клиента и чуть ли не единственная знала — как работает вся эта программа с точки зрения бизнеса и конечного заказчика, знала о багах, которые клиенту еще только предстоит найти и знала как их косвенно обойти при возможности.
Вообще это неправильно — заставлять разработчиков писать е2е тесты. Во-первых, как упоминали выше — каждый должен заниматься своим делом. Ну, казалось бы — пилят разрабы автотесты — это не так сложно для них, время идет, зп идет — все проверяется. Но при этом они не видят картины в целом по фреймворку, и насколько точно в нем тестируется весь продукт.
Отсюда вторая проблема — очень не зря говорят, что хорошо, когда автоматизацией занимаются бывшие ручные тестеры — люди с опытом составления кейсов и документации. Разработчик так не сможет покрыть автотестами функционал, как сделает это тестировщик. У него будет минимум сценариев е2е тестов на фичу, которые будут напоминать расширенные юнит тесты с кучей моков и заглушек — лишь бы в отчете загорелся зеленый свет.
И третья проблема — она тоже на мой взгляд важна — разработчики знают код и уверенно усложняют фреймворк дополнительными самописными библиотеками, кучей оверрайда и т.д… Потом, если захотите возобновить набор автотестеров — то им будет очень сложно интегрироваться, так как там может ждать TestNG+Junit+Cucumber+Rest+ что-то еще монстр собранный из разных частей фреймворков.
И по поводу «утерянной экспертизы» — надо все документировать — в конфлюенс в битбакете в гитлабе в проекте — где угодно, но комменты нужны такие, чтобы и дураку понятно было.
Короче — наймите нормального QA лида — он разберется)
Читать было интересно))
Отсюда вторая проблема — очень не зря говорят, что хорошо, когда автоматизацией занимаются бывшие ручные тестеры — люди с опытом составления кейсов и документации. Разработчик так не сможет покрыть автотестами функционал, как сделает это тестировщик. У него будет минимум сценариев е2е тестов на фичу, которые будут напоминать расширенные юнит тесты с кучей моков и заглушек — лишь бы в отчете загорелся зеленый свет.
И третья проблема — она тоже на мой взгляд важна — разработчики знают код и уверенно усложняют фреймворк дополнительными самописными библиотеками, кучей оверрайда и т.д… Потом, если захотите возобновить набор автотестеров — то им будет очень сложно интегрироваться, так как там может ждать TestNG+Junit+Cucumber+Rest+ что-то еще монстр собранный из разных частей фреймворков.
И по поводу «утерянной экспертизы» — надо все документировать — в конфлюенс в битбакете в гитлабе в проекте — где угодно, но комменты нужны такие, чтобы и дураку понятно было.
Короче — наймите нормального QA лида — он разберется)
Читать было интересно))
Я очень рад, что вам было интересно почитать)
По поводу того, кто должен писать тесты ответил в комменте выше
Проблему неумения разработчиков составлять исчерпывающие сценарии мы решаем наличием QA инженеров в команде, которые составляют эти сценарии. Разработчикам только нужно их автоматизировать.
Тут не могу прокомментировать, пока не сталкивались, возможно столкнемся
Да, документировать нужно и в каком-то виде тест-кейсы мы храним + автотесты сами по себе документация.
По поводу того, кто должен писать тесты ответил в комменте выше
Отсюда вторая проблема
Проблему неумения разработчиков составлять исчерпывающие сценарии мы решаем наличием QA инженеров в команде, которые составляют эти сценарии. Разработчикам только нужно их автоматизировать.
И третья проблема
Тут не могу прокомментировать, пока не сталкивались, возможно столкнемся
надо все документировать
Да, документировать нужно и в каком-то виде тест-кейсы мы храним + автотесты сами по себе документация.
Смотрю я на это все и просто ржу или плачу. Вот прям 1 в 1 такая вот хрень сейчас происходит в моей компании, только у нас еще хуже, у нас тестировщики теперь приемкой заниматься должны, а мы теперь разработчики и верификаторы (недотестировщики)… И как раз сегодня моей команде грозили лишением премий из-за того, что в прод. версию месячной давности ушел критический баг… И автотесты под Selenium тоже говорят начинайте писать… да еще и на java, а у нас вся команда фронта, кроме меня, не знает ничего кроме js/ts… Видимо это заразно среди руководителей
Странное у вас руководство, зачем тесты под селениумом обязательно на джаве? Я конечно в целом скорее тоже за джаву и не сторонник js в автотестах, но если вся команда хорошо владеет js, то почему нет? Тем более что JS-инфраструктура для автотестов сейчас семимильными шагами развивается. Вон Playwright тот же к примеру.
Я вообще не понимаю уже, кто эти ребята из QA.
Это какие-то «недопрограммисты»?
Ну серьезно, ребята, у нормального программиста просто кровь из глаз, когда он смотрит на код тестировщиков.
Раньше это были какие-то девочки, которые быстро-быстро стучали по клавишам и дергали мышкой, нажимая на все что можно в интерфейсе и мне хотя бы была понятна идея.
Потом решили (и весьма правильно) что все можно автоматизировать. И этим же девочкам сказали писать код! Код, блин! Это то, к чему программист идет годами, через учебу, практику, чтение правильных книг и т.д.
И, к ужасу, это стало возможно, потому что появился язык питон (я в курсе что он пайтон, но так привычнее), который ввиду своей специфики позволят писать как угодно и кому угодно. Это, конечно, хорошо для обучения. Но для профессионального программирования… Обычно языки худо-бедно подталкивали к тому чтобы писать правильно, здесь эта поддержка отсутствует. И понеслась… Кстати, тот же питон сильно полюбили админы. Если раньше они жили в своей специфической нише из bash и awk (туда программистам было заглядывать жутковато, как в космический корабль «чужих»), то тут их пагубные привычки разлились широким морем по всему энтерпрайзу (еще одна боль — это смотреть на код админов на пайтоне).
Теперь, могут сказать, мол, вот, все дело в деньгах, программисты получают больше. Да нифига подобного! Уже давно все не так. Тестер, кое как умеющий в питон или JS, получает не меньше (а часто и больше) чем профессиональный программист с опытом на тех же языках. У меня несколько знакомых программеров ушли в QA по этой причине. Довольны: нагрузки меньше, ответственности меньше, денег больше — их обычные для программеров скилы по кодированию выглядят в мире QA как супер-пупер эксклюзи.
Вообщем, я думаю, что если надо написать какой либо код (не важно, для автотестов или для бизнес логики, и, таки да, и для развертывания образа БД) лучше чем профессиональные программисты этого не сделает никто. И т.о. если уже релиши полностью автоматизировать тестирование, то самое логичное — это дать писать автоматизацию профессиональным программистам, а не каким-то непонятным «QA — специалистам».
Это какие-то «недопрограммисты»?
Ну серьезно, ребята, у нормального программиста просто кровь из глаз, когда он смотрит на код тестировщиков.
Раньше это были какие-то девочки, которые быстро-быстро стучали по клавишам и дергали мышкой, нажимая на все что можно в интерфейсе и мне хотя бы была понятна идея.
Потом решили (и весьма правильно) что все можно автоматизировать. И этим же девочкам сказали писать код! Код, блин! Это то, к чему программист идет годами, через учебу, практику, чтение правильных книг и т.д.
И, к ужасу, это стало возможно, потому что появился язык питон (я в курсе что он пайтон, но так привычнее), который ввиду своей специфики позволят писать как угодно и кому угодно. Это, конечно, хорошо для обучения. Но для профессионального программирования… Обычно языки худо-бедно подталкивали к тому чтобы писать правильно, здесь эта поддержка отсутствует. И понеслась… Кстати, тот же питон сильно полюбили админы. Если раньше они жили в своей специфической нише из bash и awk (туда программистам было заглядывать жутковато, как в космический корабль «чужих»), то тут их пагубные привычки разлились широким морем по всему энтерпрайзу (еще одна боль — это смотреть на код админов на пайтоне).
Теперь, могут сказать, мол, вот, все дело в деньгах, программисты получают больше. Да нифига подобного! Уже давно все не так. Тестер, кое как умеющий в питон или JS, получает не меньше (а часто и больше) чем профессиональный программист с опытом на тех же языках. У меня несколько знакомых программеров ушли в QA по этой причине. Довольны: нагрузки меньше, ответственности меньше, денег больше — их обычные для программеров скилы по кодированию выглядят в мире QA как супер-пупер эксклюзи.
Вообщем, я думаю, что если надо написать какой либо код (не важно, для автотестов или для бизнес логики, и, таки да, и для развертывания образа БД) лучше чем профессиональные программисты этого не сделает никто. И т.о. если уже релиши полностью автоматизировать тестирование, то самое логичное — это дать писать автоматизацию профессиональным программистам, а не каким-то непонятным «QA — специалистам».
В странах где QA это инженеры контроля качества, где есть факультеты для обучения этой профессии — все хорошо. У нас же до сих пор тестера, а не инженеры. С админством такая же беда.
Я могу рассказать обратные истории, когда из QA уходили в разработку — потому что «нагрузки меньше, ответственности меньше, денег больше». И нету постоянной бумажной работы. Наформошлепил, залил и пусть себе QA разбираться что ок, что не ок.
Сам из разработки уходил в QA — да баги просто пачками вылавливаешь, потому как знаешь где разрабы ошибаются. Хороший опыт посмотреть на себя со стороны :)
По моему ощущению все админы которые могли в bash, awk и sed — ушли в разработчики. 20 лет назад только телеком был кузницей кадров и только на такой работе можно было получить какой-то инет для доступа к информации. Знаю потому что сам так начинал, с FreeBSD, работы на провайдере.
В деньгах я бы не измерял ничего, потому что есть например DevOps, у которых почти вся разработка на yaml :)
Я могу рассказать обратные истории, когда из QA уходили в разработку — потому что «нагрузки меньше, ответственности меньше, денег больше». И нету постоянной бумажной работы. Наформошлепил, залил и пусть себе QA разбираться что ок, что не ок.
Сам из разработки уходил в QA — да баги просто пачками вылавливаешь, потому как знаешь где разрабы ошибаются. Хороший опыт посмотреть на себя со стороны :)
По моему ощущению все админы которые могли в bash, awk и sed — ушли в разработчики. 20 лет назад только телеком был кузницей кадров и только на такой работе можно было получить какой-то инет для доступа к информации. Знаю потому что сам так начинал, с FreeBSD, работы на провайдере.
В деньгах я бы не измерял ничего, потому что есть например DevOps, у которых почти вся разработка на yaml :)
del
Сама идея прикрепить тестировщиков к командам правильная, но думаю тут немного поспешили с реализацией. Тут есть два самых эффективных путей решений (как минимум за мою работу они показали себя максимально эффективно):
- Это выделение сильных сеньерных людей, которые бы ходили на митинги, планирование и ретро с командами, так же давала командам обратную связь. Возвращаясь в команду тестирования они ставят задачи остальным. Это решение очень хорошо скейлится. Одно из его названий testing is a service.
- Введение дополнительной роли Quality Architect, который как раз и отвечает за тестирование продукта в целом, и к которому стягиваются все результаты тестирования.
Оба метода имеют свои недостатки и преимущества. Но в любом случае введение тестировщиков в команды — это хорошее решение!
Удачи вам в более успешной трансформации!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как мы «разогнали» команду QA, и что из этого получилось