Комментарии 11
Автор вообще понимает, что такое эффективность? Статья про результативность. Результативность и эффективность - это разные вещи. P. S. Название статьи не соответствует содержанию
Я понимаю, что это разные вещи. Но они связанны. Статья про и то и другое. Чем более эффективные изменения были внедрены, тем лучше итоговая результативность, например.
Ваш репост говорит об обратном. Поясняю: эффективность - это результат с учётом затрат, которые вы понесли для достижения этого результата. Таким образом, говоря об эффективности, вам нужно было оценить и привезти в статье затраты ресурсов для достижения вашей результативности. Чего не было сделано... Говоря по простому, у вас может быть блестящая результативность, но, какой "кровью" она достигнута...
Третий пример как раз по верхам показывает как можно оценить затраты ресурсов вплоть до человекочасов и написанных строк кода даже :)
Важно понимать, что статья вводная и всё охватить в ней сложно. Целью было показать инструмент и его возможности. При дальнейшем интересе я с радостью поделюсь деталями в следующих статьях. Скажите, что было бы вам наиболее интересно освятить впервую очередь?
красиво! хорошие выводы. у вас ревьюиры рандомно выбираются?
За каждым микросервисом закреплен список мейнтейнеров. Бот выбирает рандомно ревьюера из этого списка. Если нужно два ревьюера (в шарповом стеке решили, что нужно два, например), то второй выбирается рандомно среди всех доступных (т.е. не в отпуске/больничном/другое). Ревьюера можно поменять руками. Бот пингует ревьюеров в личке - при назначении на него пуллреквеста и раз в час до получения апрува.
По сути, разные части проекта теперь тестируются разработчиками
Как отнеслись к этому разработчики?
даже появились Major баги. Это и понятно — разработчики не такие опытные в тестировании, но этот эффект сгладили со временем
Круто будет, если в 2х словах напишешь - как:)
Как отнеслись к этому разработчики?
По-разному :) Самая распространенная реакция очевидно "почему я должен тестировать?". Помогает доносить цель такого изменения и валидировать результат. Просто так такое внедрять, конечно, не стоит.
Если тема всё еще интересна - могу в подробно ее раскрыть в следующих статьях, там есть чем поделиться :)
Ну а если супер кратко, то разработчики теперь больше запариваются над качеством и задачи быстрее оказываются на проде. Достаточно пройти ревью и дождаться прогона тестов, а потом уже канарейка и раскатка новой версии на 100%. А QA больше фокусируются на e2e сценариях и написании автотестов.
В нашей команде в итоге сейчас на 6 разработчиков 1 QA.
Круто будет, если в 2х словах напишешь - как:)
Я во время внедрения в девтеста в нашем направлении сам еще писал код и на собственном опыте это ощутил. Сначала огребал из-за неопытности, а затем стал очень дотошно покрывать код фунциональными тестами. Еще стал более ответственно относиться к тестированию - ведь ответственность полностью на мне. Также мы перестроили процесс разработки и подходов к тестированию в целом.
Ну то есть это не просто докидывание ответственности разработчикам, это более комплексный проект.
кстати, у нас еще в апреле как раз будет доклад про девтестинг на Dump'e.
Подписываюсь под выводами статьи. Главное- держать фокус команды на продукте, а не на метриках.
Где моя эффективность, босс? Как использовать метрики в управлении командой