Comments 31
> Автоматизация через GUI наиболее болезненная и дорогостоящая из-за хрупкости и низкой скорости тестов, но зачастую начинают именно с нее.
Дорогостоящая? Автоматизаторов GUI-тестирования нужно на порядок меньше, чем остальных программистов.
И правильно делают, что начинают с нее — первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов. «Взять и покрыть юнитами все, что наделали на сегодняшний день» можно только если ничего не наделали, поэтому надо начинать с высокоуровневых тестов, которые укажут, в какие направления нужно спускаться, уровень за уровнем, а не бросаться с юнитами на все подряд.
> Тем временем, факт создания новой команды никак не влияет на команду разработки: она все также продолжает отдавать в тестирование некачественный продукт, игнорируя написание модульных и интеграционных тестов.
Ничего подобного, если есть CI. К следующему спринту (или какую у вас там религию планирования менеджеры придумают) чувак, не сумев позеленить свой мержреквест будет вынужден начать включать голову, когда код пишет. Если у него это получаться будет хуже, чем у коллег, то вообще отлично — нашли, кто баги наплодил.
> Нестабильных и медленных по своей природе GUI-автотестов с каждым релизом становится все больше, а значит больше ресурсов уходит на их поддержку, что ведет к расширению команды автоматизации.
Автотест не бывает «нестабильный» просто так — либо витую пару грызут мыши, либо кто-то сильно гордый отказывается логировать/дебажить. А то, что нестабильность выявляется — это потому, что автотест более внимателен к деталям, чем наивный пользователь, который просто ленится багрепортить нестабильность, а вместо этого ругает свою винду, браузер или старый комп.
> Департамент обеспечения качества растет, но не обеспечивает должный рост качества выпускаемого продукта.
см. пункт 2
P.S.: две недели отвечать не смогу. Только в личку.
Дорогостоящая? Автоматизаторов GUI-тестирования нужно на порядок меньше, чем остальных программистов.
И правильно делают, что начинают с нее — первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов. «Взять и покрыть юнитами все, что наделали на сегодняшний день» можно только если ничего не наделали, поэтому надо начинать с высокоуровневых тестов, которые укажут, в какие направления нужно спускаться, уровень за уровнем, а не бросаться с юнитами на все подряд.
> Тем временем, факт создания новой команды никак не влияет на команду разработки: она все также продолжает отдавать в тестирование некачественный продукт, игнорируя написание модульных и интеграционных тестов.
Ничего подобного, если есть CI. К следующему спринту (или какую у вас там религию планирования менеджеры придумают) чувак, не сумев позеленить свой мержреквест будет вынужден начать включать голову, когда код пишет. Если у него это получаться будет хуже, чем у коллег, то вообще отлично — нашли, кто баги наплодил.
> Нестабильных и медленных по своей природе GUI-автотестов с каждым релизом становится все больше, а значит больше ресурсов уходит на их поддержку, что ведет к расширению команды автоматизации.
Автотест не бывает «нестабильный» просто так — либо витую пару грызут мыши, либо кто-то сильно гордый отказывается логировать/дебажить. А то, что нестабильность выявляется — это потому, что автотест более внимателен к деталям, чем наивный пользователь, который просто ленится багрепортить нестабильность, а вместо этого ругает свою винду, браузер или старый комп.
> Департамент обеспечения качества растет, но не обеспечивает должный рост качества выпускаемого продукта.
см. пункт 2
P.S.: две недели отвечать не смогу. Только в личку.
И правильно делают, что начинают с нее — первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов.
Если стоит задача создать хоть какое-нибудь покрытие автотестами проекта, на котором отсутствуют автотесты, правильнее начинать с небольшого количества End-to-End тестов, и продолжить спускаться на более низкие уровни. Но когда в создании автотестов заинтересована только Automation QA команда, этого спуска не происходит, и все заканчивается на End-to-End.
Ничего подобного, если есть CI.
Это действительно возможный вариант. влияния отдела Automation QA на разработку, если разработка и менеджмент доверяют и понимают результаты прогонов с CI.
Автотест не бывает «нестабильный» просто так
Просто так не бывает, но в End-to-End тестах бывает чаще, чем в других. Как минимум из-за взаимодействия с системой через пользовательский интерфейс, который иногда бывает довольно изменчив. Если с разработчиками фронтенда удается выстроить работу так, чтобы изменения во фронте не сильно влияли на результаты тестов,, это, конечно, замечательно.
UFO just landed and posted this here
Дорогостоящая? <...> первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов.
Суть автоматизации тестирования в сокращении времени между появлением бага и его обнаружением. В случае юнит теста вы узнаете о баге еще до коммита. И вы будете с точностью до метода знать, где находится проблема. В случае GUI теста в лучшем случае сценарий будет такой:
1. Разработчик сделает пул реквест
2. Другой разработчик его посмотрит и зааппрувит
3. Сработает какой-либо триггер сборки новой версии (будь то наличие изменений в репозитории или просто ночью в определенное время)
4. Где-нибудь сразу после сборки пойдут тесты и упадут (и, вероятно, отправят письмецо «команде автоматизации»)
5. Через некоторый промежуток времени у автоматизатора появится время посмотреть в чем проблема. Он, скорее всего попробует воспроизвести проблему локально чтобы убедиться, что проблема не в тесте (а тесты довольно нестабильная штука, что бы вы не говорили о ленивости их разработчиков)
6. Убедившись, что это действительно проблема в продукте, тестировщик пойдет заводить баг
7. Баг попадает в бэклог (или еще какое-то хранилище, где он будет ждать пока его починят)
8. Разработчик через некоторое время доберется до бага.
9. Из бага не всегда можно понять где именно проблема, поэтому некоторое время разработчик потратит на отладку
10. После этого баг будет пофикшен и пул реквест снова отправится на код ревью
И далеко не факт, что после правки этого бага не появилось новых двух ;)
Поэтому да. Дорогостоящая как по трудовым ресурсам, так и по времени обнаружения и устранения
В чем проблема прогнать GUI-тест до пул-реквеста? Для многих систем это обычное дело.
Минимизация времени обнаружения и устранения — это важно. Поэтому приведенный вами процесс разработки в корне неверен. Какой еще аппрув пул-реквеста до тестов?
1. Разработчик коммитит в свою ветку и пушит (часто!) эту ветку в репозиторий
2. На каждый пуш, в каждую ветку, запускаются тесты.
3. Если тесты неудачны — этому разработчику сразу же отправляется письмо.
4. На каждый пул-реквест автоматически запускаются тесты. Если тесты не прошли, пул-реквест аппрувить нельзя!
1. Разработчик коммитит в свою ветку и пушит (часто!) эту ветку в репозиторий
2. На каждый пуш, в каждую ветку, запускаются тесты.
3. Если тесты неудачны — этому разработчику сразу же отправляется письмо.
4. На каждый пул-реквест автоматически запускаются тесты. Если тесты не прошли, пул-реквест аппрувить нельзя!
А если тест ломается по причине новой функциональности? Как поступить с мерджем в такой ситуации?
Не проводить мердж, пока тесты не починены.
Не очень понял.
Например есть кнопка отправки формы. В новой версии она сменила местоположение и GUI-тест ее не может найти. При этом в мастер-бранче, она все еще на прежнем месте и тест проходит.
Как обработать эту ситуацию?
Обычно у выделенной QA-команды еще и отдельный репозиторий, так что вариант закоммитить правку в тот же фича-бранч не подойдет.
«End-to-End тесты, которые тестируют не сложные сценарии использования интерфейса, а лишь бизнес-логику, но через интерфейс, который доступен конечному пользователю. Так как данная категория тестирования все еще лежит в сфере интересов разработки, то автоматизация ложится на плечи команды разработки»
А с чего бы это вдруг? Команда разработки будет делать эти тесты как? Коллегиально, каждый по 100 строк? Фронтендеры или бекэндеры, кто лучше справится? Чтобы разрабатывать End-to-End тесты, разработчики внезапно должны залезть уж очень глубоко в бизнес-домен и заодно на «поле» своих коллег, иначе ничего не выйдет. А им ещё фичи писать. Переключение контекста, которое требует времени и нервных клеток, а так же само время на создание и поддержку этих тестов, кто оплатит? Бизнес. А ему это выгодно? Представляю ситуацию — а чего у нас к релизу половина фич не сделана? Да тут Селениум 3-ий вышел и Огнелис перестал работать с 50-ой версии со старым драйвером, так что звиняйте, мы тут тесты правим.
Или всё таки логичнее выделить одного-двух несчастных для этого? Ой, вот вам и появился выделенный отдел автоматизации.
Ну и доставило «не сложные сценарии использования интерфейса, а лишь бизнес-логику». То есть, в кровавом интерпрайзе бизнес логика так, тьфу, не сложная?) По моему опыту как раз таки наоборот. И end-to-end там будет не «добавить товар в корзину», а нечто фееричное. Так что, не убедили.
А с чего бы это вдруг? Команда разработки будет делать эти тесты как? Коллегиально, каждый по 100 строк? Фронтендеры или бекэндеры, кто лучше справится? Чтобы разрабатывать End-to-End тесты, разработчики внезапно должны залезть уж очень глубоко в бизнес-домен и заодно на «поле» своих коллег, иначе ничего не выйдет. А им ещё фичи писать. Переключение контекста, которое требует времени и нервных клеток, а так же само время на создание и поддержку этих тестов, кто оплатит? Бизнес. А ему это выгодно? Представляю ситуацию — а чего у нас к релизу половина фич не сделана? Да тут Селениум 3-ий вышел и Огнелис перестал работать с 50-ой версии со старым драйвером, так что звиняйте, мы тут тесты правим.
Или всё таки логичнее выделить одного-двух несчастных для этого? Ой, вот вам и появился выделенный отдел автоматизации.
Ну и доставило «не сложные сценарии использования интерфейса, а лишь бизнес-логику». То есть, в кровавом интерпрайзе бизнес логика так, тьфу, не сложная?) По моему опыту как раз таки наоборот. И end-to-end там будет не «добавить товар в корзину», а нечто фееричное. Так что, не убедили.
А с чего бы это вдруг? Команда разработки будет делать эти тесты как? Коллегиально, каждый по 100 строк? Фронтендеры или бекэндеры, кто лучше справится?
Один из вариантов: GUI End-to-End покрывают фронтенд-разработчики, API End-to-End — бэкенд-разработчики. Фичи же получается как-то коллегиально делать, с автотестами тоже не возникнет проблем.
Чтобы разрабатывать End-to-End тесты, разработчики внезапно должны залезть уж очень глубоко в бизнес-домен
По-моему писать бизнес-логику, не понимая как должен будет выглядеть конечный результат, довольно странно. А для понимания конечного результата придется залезать в бизнес-домен в любом случае.
А вы так делали, чтобы утверждать, что не возникнет проблем? А насчёт переключение контекста, времени, ничего не хотите сказать? А с точки зрения управления — по факту, вместо того, чтобы управлять небольшой командой автоматизаторов, нужно будет управлять всей командой разработки, которым придётся разрабатывать параллельно ещё один продукт, проблем не возникнет?
Уровни понимания конечного результата дюже разные бывают. Некий результат в вакууме понять то не сложно. Но тонкости изучать и при этом ещё постоянно быть в курсе всех изменений? Вы, верно, шутите.
Уровни понимания конечного результата дюже разные бывают. Некий результат в вакууме понять то не сложно. Но тонкости изучать и при этом ещё постоянно быть в курсе всех изменений? Вы, верно, шутите.
Хорошая статья, качественно написанная и оформленная. И тезисы верные.
С почином, пишите ещё!
С почином, пишите ещё!
Мне картинка очень понравилась… жизненно!
Не понятно только для чего на ней 2, 4 и 6я. Они же совершенно не несут никакой информации а 2 и 4 вообще одна и та же.
С удовольствием полюбовался еще раз, сообщаю: на 2 картинке верхний жук обходит релиз чтобы катить его к тестерам (на 3й он поворачивается к собеседнику) на 4й он обдумывает свой ответ и план действий, на 6й оказывается что нижний жук тоже катит свой релиз к тестерам… Очень жизненно: пообщались, посетовали и продолжили работу дальше (а что делать? дома семья, дети голодные, против системы идти себе в ущерб).
У нас приложение поделено на функциональные разделы. У каждого раздела свой подрядчик. Мы делаем три раздела из двенадцати. В каких-то командах четверо пишут ui-автотесты на один раздел, у нас один пишет на три.
Я — отдельная команда. Нашего тимлида по-поводу автотестов дергает техлид заказчика. Мое дело держать автотесты «в зеленом секторе». Не дергают моего тимлида он не дергает меня. И никому нет особенно дела как у меня там дела, пока все нормально. Правда я еще багрепорты пишу. Если бы не это наверное бы не знали как и звать :) И можно было бы передать ответственность за написание автотестов разработчикам, но это сьедает столько времени, что лучше не надо. Пусть пишут код. А «Команда-Я» как нибудь бегом широкими прыжками на хвосте.
Соглашусь, был бы рад, если бы мне дали какого нибудь студента в помощники, но проект строго бюджетирован.
В принципе считаю что лучше брать на автоматизацию специально людей. Но не из-за пирамид на графике. Просто они по другому смотрят на продукт.
Когда тестировщик приходит к программисту прояснить принцип работы куска функционала, программист часто говорит или думает «о, обьяснил и сам лучше понял» — это очень ценный диалог. Тестировщик может задавать наивные вопросы. Мне кажется это имеет положительное влияние на вырабатывание качественно другого подхода к разработке. Но на это нужно время. Время. Его всегда мало.
Я — отдельная команда. Нашего тимлида по-поводу автотестов дергает техлид заказчика. Мое дело держать автотесты «в зеленом секторе». Не дергают моего тимлида он не дергает меня. И никому нет особенно дела как у меня там дела, пока все нормально. Правда я еще багрепорты пишу. Если бы не это наверное бы не знали как и звать :) И можно было бы передать ответственность за написание автотестов разработчикам, но это сьедает столько времени, что лучше не надо. Пусть пишут код. А «Команда-Я» как нибудь бегом широкими прыжками на хвосте.
Соглашусь, был бы рад, если бы мне дали какого нибудь студента в помощники, но проект строго бюджетирован.
В принципе считаю что лучше брать на автоматизацию специально людей. Но не из-за пирамид на графике. Просто они по другому смотрят на продукт.
Когда тестировщик приходит к программисту прояснить принцип работы куска функционала, программист часто говорит или думает «о, обьяснил и сам лучше понял» — это очень ценный диалог. Тестировщик может задавать наивные вопросы. Мне кажется это имеет положительное влияние на вырабатывание качественно другого подхода к разработке. Но на это нужно время. Время. Его всегда мало.
Подход интересный, но к снижению количества высокоуровневых тестов не приведет. QA в любом случае несет ответственность и будут проверять все возможные сценарии.
Но соглашусь, покрытие кода unit-тестами снизит количество возвратов билда девелоперам в случае наличия ошибок, что в итоге может привести к снижению времени производственного цикла.
Но соглашусь, покрытие кода unit-тестами снизит количество возвратов билда девелоперам в случае наличия ошибок, что в итоге может привести к снижению времени производственного цикла.
В статье упущено много опций, например, про тестируемые конфигурации в GUI тестах (как пример тестирование мобильных приложений и взаиможействие с ОС) это сильно изменит процентное соотношение, или наличие отдельной бизнес-логики на стороне клиента и т.д.
Если кратко, то да, этот подход будет действенен для какого-либо проекта, но реальность намного сложнее и не все так просто.
I always argue that high-level tests are there as a second line of test defense.
Только не "утверждаю", а "спорю" с тем, что это вторая линия обороны. То есть, это не вторая, а первая линия.
Беда, коль пироги начнет тачать пирожник...
В тесте две мысли, о переносе тестирования в отдел разработки и о написании тестов программистами. Первая — частично верная, а вторая — нет.
Есть такое золотое правило тестирования "в своем коде баги не видны". Если программист при написании кода решил, что «не меньше» это «больше», он так решит и при написании тестов. В итоге написанные программистом тесты годятся лишь для рапорта «у нас все хорошо». А на самом деле — в коде ещё полно ошибок.
Я уж не говорю о том, что программеры больше синтетики, а тесты хорошо пишут аналитики (люди, у которых процессы анализа преобладают над синтезом).
Поэтому к программистам добавляется тестер. Из расчета примерно один тестер на 2-3 программиста. Он получает ТЗ вместе с программистами и пишет тесты. В идеале тестер ещё и участвует в ревью кода.
Чтобы избежать давления, тестер подчиняется при этом руководству QA. И его оплата — как-то завязывает на число найденных им багов. Или на число багов, пролетевших мимо него и найденных на поздних стадиях тестирования.
Все это не новость, давно описано у Брукса под названием «Бригада главного хирурга».
Дополнительный плюс этого метода — через пару лет такой практики тест становится достаточно зрелым разработчиком и готов к переходу в девелоперы.
В тесте две мысли, о переносе тестирования в отдел разработки и о написании тестов программистами. Первая — частично верная, а вторая — нет.
Есть такое золотое правило тестирования "в своем коде баги не видны". Если программист при написании кода решил, что «не меньше» это «больше», он так решит и при написании тестов. В итоге написанные программистом тесты годятся лишь для рапорта «у нас все хорошо». А на самом деле — в коде ещё полно ошибок.
Я уж не говорю о том, что программеры больше синтетики, а тесты хорошо пишут аналитики (люди, у которых процессы анализа преобладают над синтезом).
Поэтому к программистам добавляется тестер. Из расчета примерно один тестер на 2-3 программиста. Он получает ТЗ вместе с программистами и пишет тесты. В идеале тестер ещё и участвует в ревью кода.
Чтобы избежать давления, тестер подчиняется при этом руководству QA. И его оплата — как-то завязывает на число найденных им багов. Или на число багов, пролетевших мимо него и найденных на поздних стадиях тестирования.
Все это не новость, давно описано у Брукса под названием «Бригада главного хирурга».
Дополнительный плюс этого метода — через пару лет такой практики тест становится достаточно зрелым разработчиком и готов к переходу в девелоперы.
Если программист при написании кода решил, что «не меньше» это «больше», он так решит и при написании тестов
Именно поэтому QA-отдел и должен осуществлять «Помощь разработчикам при написании тестов из первой категории».
Из расчета примерно один тестер на 2-3 программиста.
А JIRA разрабатывают с 6 QA-инженерами на 70 девелоперов, причем QA-инженеры отвечают не за написание тест-кейсов и называются немного иначе.
«Помощь» — это не то. Хороший тестер знает психологические профили разработчиков и их типичные ошибки. И ещё до тестов понимает, в каких местах может скрываться ошибка. Помощь тут бесполезна. Разработчику можно 10 раз сказать, что он делает типичную ошибку — но он все равно будет её делать, ибо это особенность его мышления.
Но главное не в этом. Чтобы получить senior development нужно лет 10 практической работы. Senior QA становятся намного быстрее. Поэтому и надо заменять дорогих разработчиков на дешевых тестеров. А уж как называть их — дело десятое. Можно и тестерами и подаванами и секретарями…
Но общий вектор в любом случае состоит в разгрузке высококвалифицированных сотрудников за счет передачи вспомогательных функций низкоквалифицированным.
Впрочем, если у вас QA получают больше девелоперов, то ваша идея имеет смысл.
Но главное не в этом. Чтобы получить senior development нужно лет 10 практической работы. Senior QA становятся намного быстрее. Поэтому и надо заменять дорогих разработчиков на дешевых тестеров. А уж как называть их — дело десятое. Можно и тестерами и подаванами и секретарями…
Но общий вектор в любом случае состоит в разгрузке высококвалифицированных сотрудников за счет передачи вспомогательных функций низкоквалифицированным.
Впрочем, если у вас QA получают больше девелоперов, то ваша идея имеет смысл.
Все хотят дешевых тестеров, но требования как с сеньоров-разрабов, эта тема не прокатывает. Хороший тестер не будет дешевле разраба.
Разница в оплате тестеров и программистов — это разница в образовании и опыте работы. Из опытного пользователя — получается вполне приличный тестер. Из юниора-программиста — выходит отличный тестер.
Есть лишь одна особенность, нужная для тестера — умение влипать в редкие ситуации. Всему остальному тестер обучается быстро.
Это как по собственному опыту, так и по руководству группой тестеров.
Есть лишь одна особенность, нужная для тестера — умение влипать в редкие ситуации. Всему остальному тестер обучается быстро.
Это как по собственному опыту, так и по руководству группой тестеров.
Из юниора-программиста — выходит отличный тестер.Ох не всегда из программиста выходит тестер, тем более отличный.
Не всегда. Тестеры — аналитики, программисты — синтетики. Но… шанс, что из юниора выйдет тестер больше, чем то, что юниор станет сеньором.
Что такое тестерская невезуха, оно же чутье.
Тыкаю мышкой в интерфейс — 100% баг, тыкает второй тестер — 50% баг, тыкает автор — нет бага. Оказывается была там полоска высотой в один пиксель… Ну в общем я не ту точку мышиного курсора на цель наводил. :-))))
Что такое тестерская невезуха, оно же чутье.
Тыкаю мышкой в интерфейс — 100% баг, тыкает второй тестер — 50% баг, тыкает автор — нет бага. Оказывается была там полоска высотой в один пиксель… Ну в общем я не ту точку мышиного курсора на цель наводил. :-))))
> Так как созданный QA-отдел теперь отвечает не только за контроль качества продукта, но и за обеспечение качества, то в его обязанности входит: Помощь разработчикам при написании тестов из первой категории…
т.е. автоматизатор == разработчик (читает код, понимает его, пишет код тестов на том же языке) + аналитик бизнес-стори, сложные сценарии) + контакты с пользователями, поддержка + юзабилити (дизайн, UX)…
А что делает разработчик — пилит нетленку по ТЗ+юнит тесты на нее же за бОльшую зп.
При таком раскладе QA сваливает на разработчика в течении полугода.
т.е. автоматизатор == разработчик (читает код, понимает его, пишет код тестов на том же языке) + аналитик бизнес-стори, сложные сценарии) + контакты с пользователями, поддержка + юзабилити (дизайн, UX)…
А что делает разработчик — пилит нетленку по ТЗ+юнит тесты на нее же за бОльшую зп.
При таком раскладе QA сваливает на разработчика в течении полугода.
Sign up to leave a comment.
Automation QA — это отдельная команда?