Comments 7
разработчик не занимается тестированием…
На самом деле разработчик проверяет, соответствует ли реализация функциональности
словесная эквилибристика дает +100 к карме менеджеру, особенно в Agile
Кажется, что слова Agile и Менеджер отражены вами в негативной коннотации с небольшим урезанием контекста :)
Почему же эквилибристика, если понятие тестирования включает гораздо большее, чем проверка ТЗ. В этом как раз есть важная необходимость проверки разработчиком именно "договорённостей, к которым пришла команда на PBR’ах", потому что опытный разработчик все равно проверяет свою сборку перед тем как отдать ее на полноценное тестирование. Подобное фиксирование ожиданий от фичи как раз помогает разработчику убедиться в том, что он сделал именно как ожидалось, а тестирование уже все равно будет дополнять эти проверки.
Более того, тестирование так же включает в себя еще этапы, помимо Quality Control на последнем этапе.
«опытный разработчик все равно проверяет» — что значит «все равно», кому все равно?
" тестирования включает гораздо большее, чем проверка ТЗ" — если речь про мизер то и оставьте его там где много.
«помогает разработчику убедиться в том, что он сделал именно как ожидалось» — для этого есть MVP, раннее тестирование, аналитическая проработка, KPI возвратов на доработку итд итп
Всё так, прошли очень похожий путь, сейчас все довольны. В статье надо бы отразить два очень важных момента:
Разработчиков необходимо не только вдохновить на описанный процесс, но и обучить базовым концепциям тестирования. Пары демо и воркшопа "покрываем фичу вместе" вполне хватит.
В данном сетапе на AQA ложится задача по поддержке тестовой инфраструктуры в максимально комфортном для разработчика виде. Чтобы тесты писались и запускались очень быстро, не было ложных падений, результаты прогона были наглядными. И сами разработчики были снабжены гайдами и примерами по используемым фрэймворкам, чтобы написание и прогон автотестов не становилось для них болью.
Также могу порекомендовать старую, но всё ещё актуальную книжку "Как тестируют в Google", особенно первые несколько глав. Они как раз про "тесты для разработчика" и роли в команде.
Спасибо за дополнение)
Вы абсолютно правы с концепциями тестирования, просто это следующий этап после внедрения описанных практик) Разработчики проникаются и понимают важность этого и сами приходят за подобными мастерклассами, инструкциями и чек-листами проверок.
Потом вообще можно их научить самих добавлять новые кейсы в регрессионные сценарии после реализации новой фичи, и проходить регресс какого-либо сервиса (автоматизированный и даже нет).
Про книгу "Как тестируют в Google" я тоже думал упомянуть, но это было бы слишком перегружено уже в рамках одной статьи. Есть вероятность, что я напишу продолжение этой. Расскажу к чему пришли сейчас, почему мне это интересно, и какие еще инсайты мы словили с командой.
Команда — это небольшая группа людей с комплементарными навыками, которые преданы общей миссии/видению, разделяют общие цели и следуют подходу, за который они несут коллективную ответственность.
А деньги-то они коллективно получают, или, каждый — свою получку?
И зависят ли эти денги напрямую от «качества и результата»?
Если нет, то объективно это — не команда, а группа наемных работников, в которой каждый материально заинтересован работать на свой персональный результат.
А потому, втюхать им идею, что они — команда с общими интересами (да ещё и — общими с владельцем бизнеса) — это фактически означает обмануть людей, с какими бы благими намерениями это ни делалось.
Либо, эти практики надо дополнять правильным — т.е. материальным — стимулированием разработчиков работать на общий резульат. Но тут уже мне представляются неизбежными проблемы с общей корпоративной культурой. Да и неустранимое антагонистическое противоречие между интересами наемных работников и владельца бизнеса — заключающееся в том, что расределение дохода предприятия на оплату труда и на прибыль владельца есть «игра с нулевой суммой» — это тоже серьезное препятствие.
Так что, эджайл — это, может, и хорошо, а деньги — лучше.
Спасибо за комментарий)
На самом деле прям долго думал, как на него ответить, потому что очень неоднозначная тема и рассуждения в разных частях комментария.
Я согласен с тем, что вы абсолютно конструктивно и аргументировано пишете про то, что "мы команда мы все движемся к одной цели мы все ответственны за качество одинаково", но кто-то это может делать за 60 тысяч а кто-то за 360, и такие случаи встречаются очень часто в мире айти. Люди по разному себя продают и хайринг это тоже бизнес)
При этом я очень старался в самой статье изложить свою позицию, что это немного несвязанные вещи — мотивация идти на работу и инструменты делать работу лучше в команде.
И зависят ли эти денги напрямую от «качества и результата»?
Да, ответ простой — как у вас в компании принято и какие есть для этого инструменты мотивации помимо денежных.
А потому, втюхать им идею, что они — команда с общими интересами (да ещё и — общими с владельцем бизнеса) — это фактически означает обмануть людей
Аргумент про "аджайл == обмануть людей" очень часто слышу именно от российских инженеров, потому что даже в Индии это уже просто инструмент, а не способ оценки своей стоимости, хотя полную статистику я не проводил, но когда работал там, я много интересных историй видел, но они не связаны с культурой аджайла.
В целом сложно сильное зерно в том, что вы говорите, есть. Но я даже не знаю, что на это ответить) Потому что я не могу судить за всех и за отношение к работе других. Я просто хочу делать свою работу хорошо и быть полезным, чтобы оглянуться назад я мог увидеть, что вот результаты моего труда и вот мой вклад.
Надеюсь, вы меня понимаете :)
Очень странные дела: когда процессы в команде и правда помогают