Comments 10
не пробовали хоть немного измерить улучшения? взять пару еще не реализованных тестов и двух сферических тестировщиков (в идеале либо знающих оба языка, либо "одинаково" знающих), и пусть реализуют оба теста (но один на жаве, второй на го). что быстрее, что приятнее, что читаемее, что расширяемее?
Согласен, не хватает каких-то метрик, по которым можно было бы оценить, что и насколько в итоге улучшилось.
Но предложенный @kingarold вариант оценки кажется слишком необъективным. Начать хотя бы с того, как определить "одинаковость" знания двух разных языков. Ну и читаемость с приятностью - чистая вкусовщина.
Привет. Спасибо за комментарии.
Началось с того, что я решил попробовать написать тест на голом Go, то есть без использования каких-либо библиотек, связанных с созданием e2e тестов. Потом я то же самое проделал с использованием и сравнил. Во втором случае время на разработку уменьшилось, но оно и понятно, так как много логики спрятано внутри библиотеки. (p.s. до принятия решения по разработке CUTE).
На счет замеров: такого не было, да и провести было бы трудно, так как сейчас мы максимально сделали всё, чтобы старт был простым. Мы написали полностью инструкцию, как освоить библиотеку и как писать тесты, да и примеров тестов создалось немало за прошедший год.
В соседние команды люди выходили без бэграунда в Go, достаточно быстро осваивались, но опять же это все очень субъективно и трудно оценить.
А сравнивали стоимость разработки своего фреймворка с выигрышем от использования go?
С учетом стоимости переобучения, сложностей найма новых тестировщиков (тестирование на go - не самый популярный подход), стоимостью поддержки своего инструментария?
Вообще не очень понятна польза от перехода в написании тестов на go.
Привет, спасибо за вопрос.
Наверное в идеальном мире в вакууме хотелось бы все покрыть метриками и считать профит от того или иного действия, но не всегда на практике это легко и прозрачно.
На моем примере: я — основной разработчик CUTE, пишу документацию и помогаю с вопросами. Безусловно, это определенный кост для компании, так как вместо этого я мог бы катить бизнес-фичи, заниматься RnD или просто искать носки.
Поэтому мой подход отчасти прыжок веры: условно говоря, мои 3 часа разработки CUTE потенциально сокращают работу тестировщика на 10 минут, но таких сокращений может быть сотни, так как тестов создается много. Мне хочется верить, что в этом случае мы всё же наточили пилу, чтобы потом ей быстрее пилить)
Если говорить про обучение, то оно будет всегда и везде независимо от стека, так как у всех компаний есть своя специфика и контекст. В нашей команде специфика — CUTE и Go.
Отдельно замечу, что CUTE изначально была небольшой утилитой для нашей команды, но сейчас она применяется и другими командами по их собственному желанию, а некоторые идут дальше и переходят с Python на Go, посмотрев на наш пример.
И почему у вас тесты начинают писать после реализации задачи, а не после планирования? По идее уже все необходимые API должны быть к этому времени согласованы, зачем тогда ждать? Глядишь, в этом случае и времени на автотесты хватило бы.
На сколько сложнее стал найм тестировщиков, учитывая то, что на рынке готовых автотестировщиков на Go значительно меньше, чем автотестировщиков из популярной троицы?
Строим процессы тестирования в команде через огонь, воду и собственные фреймворки