testomat.io управление авто тестамиСтараюсь улучшать процессы и избавляться от ненужной траты времени как на технические аспекты автотестов так и в менеджементе.
Но для понимания как у других и где я нахожусь с нашей производительностью - хочется знать сколько тестов в месяц пишут ваши автотестировщики. И сколько времени уходит на написание одного теста.
Сильно интересует web тесты Java Selenium Gherkin
Но если у вас другой стек и другие типы тестов - делитесь тоже!
Встречный вопрос - считать хотите для чего? Это снова “индусский код” и подсчёт строчек кода? Или причины другие?
1 лайк
Нет, это с точки зрения бизнес модели, стратегии скорости покрытия тестами а также расчета стоимости проекта.
Узнать какой прирост по тестам в месяц считается средним а какой нереальным.
Причина - узнать нахожусь ли я где-то в середине или например в самом конце.
Понятно что у всех сложность и длина тестов разная.
Может кого-то в командах инженеры пишут по 5 ui тестов в день а в месяц - по 100
а может у кого-то один тест в три дня.
Узнать средние цифры и опыт других команд это полезно, потом эти знания можно экстраполировать но объем проекта, сложность, состав и сделать выводы.
Кол-во строк меня не интересует особо - я рассматриваю тест как бизнес единицу - один пользовательский сценарий.
Ян, если честно я не до конца понимаю вашу ситуацию. Вы пытаетесь просчитать объем и стоимость работ для тендера? Просто вы так пишете как будто вот эти UI-тесты и есть ваш “бизнес”, то что вы продаёте, что немного странно, но для компаний аутсорсеров, которые продают тестирование как услугу - вполне допустимо. Во всех других случаях мне это кажется странным и даже абсурдным.
По поводу же того, что тесты и строчки кода - разные вещи, то это не так. Это практически калька тех же самых ситуаций, просто в других нарядах, но суть одна и та же. Это классическая ошибка менеджмента и попытка считать “мифического человека-месяца”. Вот вы говорите про UI-тесты и их количество, а оно вам зачем? Если вы их конечно не продаёте. Вот @asolntsev создатель Selenide не раз упоминал в своих докладах, что одна из болезней индустрии это то, что многие пытаются всё тестировать через UI-тесты. Например, вот в этом докладе было:
И вот я возвращаюсь к своему изначальному вопросу: что считаем и для чего? С мануальными тестами ровно такая же ситуация? Написать можно хоть даже один тест и это будет великолепно и хоть тысячу и это будет бесполезно. Всё упирается в конкретный контекст. А по поводу “средней продуктивности” по рынку, то я тут не открою никакого секрета полишенеля, если скажу, что цифры между “худшими” и “лучшими” показателями отличаются не на доли процентов или даже не в разы. Поэтому по сути и нет никакого “среднего”. Я даже больше скажу, каждый работник как и любой живой человек может работать как условный Петя на 146% и условный Вася на треть силы. И это будет один и тот же человек просто в разное время и в разные жизненные ситуации. Причем в каждом из нас сидят эти условные Пети и Васи, но в разных пропорциях. Более того, усилия на написание тестов на проекте не равномерны по времени. Они сильно выше в начале проекта, особенно если он реально пишется с нуля, снижаясь со временем, но может в дальнейшем снова начать расти, когда поддержка старых уже написанных тестов будет съедать всё больше и больше времени, особенно, если начнут всплывать проблемы, которые не мешали на этапе роста и стали проявляться, начиная с определенного масштаба. Иногда это приводит к масштабному переделыванию почти всей архитектуры. Поэтому мне и непонятно, что пытаетесь мерить. Если вы уже делали подобные проекты и не раз, то можете оценивать свою продуктивность и своих коллег. Зачем вам чужая? Вы же не знаете чужой специфики проектов. Может там копипастят тесты и набивают для объема, а не для пользы проекта. Вам зачем идти по этой дорожке?
Да все намного проще - узнав эти цифры я не буду стимулировать команду к написанию полупустых тестов в погоне за количеством, в этом нет никакого смысла. Да у меня много реализованных проектов в компаниях разного масштаба и скорость моих команд была примерно одинаковая( в порядке) во всех типах тестов ui API и тд - ну или если на начальном этапе скорость у команд была одна, то после улучшения всех процессов - все примерно приходили к одной точке.
А ситуация например такая - нужно автоматизировать регресс на новом проекте(ui) есть от заказчика 1000 тестов, я говорю если команда из 4 человек - она сделает это за 11 месяцев
Мне говорят что на рынке все пишут в разы быстрее и даже в десятки раз быстрее в других компаниях. Для меня такая оценка нереалистичная в таком контексте, в таком типе тестов, в таком, стеке и в такой численности команды.
По этому я хочу узнать “как у всех” и убедиться. Большое кол-во информации и оценок от больших компаний я уже узнала от знакомых или из опубликованных статей которыми я могу аргументировать. Решила спросить и тут.
все равно ответа вы не даёте
среднего нет
ui тесты в идеале должны тестить ui, формочки и прочую фигню, где будет замокан бек и бд, чтоб это всё работало быстро
а бизнесовая логика в идеале должна тестироваться на среднем слое опять же без ui
Это совсем не сложная цифра и каждый менеджер считает сгорание задач, как минимум для построения роадмэпа на ближайшие месяцы или год или спринт. Если конечно это проект с нуля а не просто пополнения автотестами от релиза релизу.
Посчитать за командой или за собой сколько ты делаешь UI тестов в месяц это не сложно ( если проект на api тестах - посчитать сколько API тестов в месяц делается).
Сразу попрошу прощения за свой тон. 
Перестаньте тратить время на KPI и прочие подсчёты в тестирование. Тестирование проекта заканчивается, тогда когда на него заканчивается бюдже 
. Количество автотестов зависит только от того сколько вы хотите экономить от вашего бюджета на тестирование. Нет смысла покрывать автотестами то что не нужно будет перетестировать многократно, даже если у вас практикуется BDD, ATDD и прочие с ними. А если хотите посчитать бюджет на тестирование то просто узнайте когда ваш проект должен быть в лайфе… и умножит все время которое у вас есть на стоимость всей команды и потом умножьте на 2 и прибавьте еще 2 недели стоимости работы вашей команды 
Простая математика.
3 лайка
Вопрос немного некорректен.
- Мы пишем норм тесты или что-нить с thread.sleep(1)?
- А фреймворк у нас уже готов или пишем с нуля?
- А тесты пишем в соответствии с пирамидой тестов или всё ui-щиной покрываем?
- Мы гонимся за кол-вом тестов, когда мы берём 1 и тот же тест, меняем в нём значение и говорим, что это - новый тест теперь или такие тесты скидываем на уровень unit тестов?
- А мы оптимизируем тесты по скорости выполнения или пусть 100 тестов всю ночь бегут, нам не жалко?
- А техдолг по тестам / фреймворку мы закрываем или забиваем?
- А упавшие / мигающие тесты мы фиксим или главное - количество?
Вот все эти моменты дадут скорость написания тестов от 1 в 2 дня до 50 в день.
Мне из ответов Яны показалось, что там просто стандартная ситуация в продажах, в смысле торг и переговоры. Условный владелец бюджета (денежный мешок), по какой-то причине решил для себя автоматизировать регресс аж на 1000 кейсов и ведёт переговоры с исполнителем, торгуясь или за цену или за сроки или за всё вместе взятое. При этом проект якобы “новый”, что уже звучит как фантастика для такого регресса, либо там регресс этот полная чушня и он сам бы не смог и половины кейсов обосновать как необходимые к автоматизации.
Мотивация этого денежного мешка из ответов мне не до конца понятна, а также степень её силы. Возможно это годовая премия или КПИ по выполнению плана автоматизации до конца года, возможно что-то другое аналогичное. Без четкого понимания этого побуждения сложно вести переговорную линию. Потому, что если человек условно супер важно закрыть задачу именно до какого-то числа, то тогда он допустим может увеличить бюджет / штат, чтобы поднять среднюю выработку в единицу времени, хотя и тут может быть подвох (вспоминаем классиков про мифических человеко-месяцев и т.п.), опять-таки можно улучшить практики, эффективность работы каждого сотрудника, применить более лучшие инструменты и т.д. Если же у человека мало денег и он хочет сэкономить, то тут надо смотреть на снижение квалификации работников и как следствие их оклада, на снижение объема работ (уменьшение тестовой модели, которую автоматизируете) и т.д.
Ничего из приведенных ответов не указывает на реальную причину, а также на другие движущие факторы. Просто, есть данность “1000 кейсов” и надо сделать их автоматизированными. При этом судя по ответам выше, то этот “человек с деньгами” итак имея более сильную переговорную позицию поставил себя в ещё более сильную позицию (я её называю “супер позицию”). После получения сметы на своё ТЗ он сказал исполнителю: “А чё так долго и дорого, другие мне делали дешевле и быстрее”. При этом заставляя уже исполнителя оправдываться и обосновывать свою стоимость работы. Причём там сразу дают понять, что разница не просто незначительная, а в десятки раз. Интересно, он может на фактах подтвердить свои слова про “в других местах мне делали в десятки раз быстрее” или это просто звиздёж, чтобы сбивать цену?
Вот интересно, кто-то тут делал проекты размером в 1000 UI тестов? За сколько сделали и силами какой команды. Накидайте, что-ль Яне ответы, чтобы ей за себя не было сильно стыдно. Хотя как выше писали, всё упирается в специфику тестов. Если там тесты вида “Тест1. Введите сумму 100, нажмите оплатить”, “Тест2. Введите сумму 200, нажмите оплатить” и т.д. повторять 100 раз с разными суммами, то таких конечно можно за раз сразу сто сделать, тут ума-то и не нужно. Вопрос тут только в другом будет - они вам эти тесты для чего нужны? Для галочки или для пользы?
2 лайка
Та вот тоже есть такое подозрение.
А ещё есть подозрение, что Яна ну абсолютно ничего не смыслит ни в тестировании, ни тем более в автоматизации оного. Поэтому вместо конструктивных переговоров с оценкой задач, предварительным планом (и вообще reasonaility писать тыщщу UI тестов OMG) переговоры у них из серии “угадай мелодию по 3-м нотам”: Яна говорит, что на тыщщу абстрактных кейсов надо 11 месяцев, а ей говорят, что можно за 3 уложиться. Что из этого получится, угадать несложно: договорятся на 6 месяцев, а потом проект затянется на 15 и ничем не закончится. Хорошо, если проект будет по T&M и за кривизну переговоров заплатит заказчик. Если пойдёт по fixed price - будет плохо.
Что можно (и нужно) сделать:
- Найти толкового автоматизатора. Или матёрого синьора, или ещё лучше - лида, но чтоб умел в hands-on.
- Скормить ему предварительную задачу.
- Ответить на тыщщу его вопросов, возможно, потягать на митинги с заказчиком, чтоб он вник в смысл проекта.
- Получить от него предварительную оценку проекта в человеко-часах, кол-ве тестов и их типам.
- Накинуть на человеко-часы +50% на нежданчики типа болезней, отпусков, недоступности заказчика, допусков к проекту, технических граблей, …
- Написать тест-план, базируясь на полученных данных.
- И вот с этой цифрой и планом уже идти к заказчику, не забыв взять с собой вот того чувака, который это всё расписал, чтобы он смог ответить на вопросы заказчика, почему это займёт именно столько часов, а не в 3 раза меньше, как его уверяли индусы из “рогов с копытами”.
1 лайк
- мы пишем норм тесты пассрейт которых очень редко падает за 94%
- готов
- в соответствии - я не говорила что у нас есть только UI тесты - мой вопрос был только про ui
- за кол-вом никто не гонится - за покрытием - да
- по скорости - естестесственно - все расспаралелено сначала на уровне раннеров в CI потом добавился грид - в целом скорость с часов 6 в начале сократилась до 30 минут
- техдолга вообще никогда нет
- пассрейт всегда высокий - а запуски каждый день - чинятся тесты до след. запуска в большей массе
Есть подозрение что Дима ну ничего не смыслит в общении с другими людьми тем более незнакомыми ему.
Переговоры и результаты их сюда не напишешь даже коротко да и вопрос был не про это.
И не про то как вести себя с заказчиком.
Да мой вопрос был абстрактным и ответ я тоже хотела получить абстрактный - и он никак бы не повлиял на мою работу - это только для того чтобы увидеть действительно ли при самых положительных обстоятельствах кто-то напишет скорость 1000 рейсов за 3 месяца или цифры будут намного больше. Вот и все.
Абстрактный проект с абстрактным временем.
Все остальные вопросы уже после - и естественно это битая истинна что нельзя автоматизировать все кейсы что дали подряд - естественно они будут отбираться по приоритетам фич, по аварийности, по необходимости их делать через UI и по анализу выявления багов у пользователей и тд.