По просьбам трудящихся, которые не хотят светить своим мнением в чате - анонимный формуляр
https://forms.gle/9YprgbD7swr2sZrt7

Спасибо за ваши мнения!

Кроме банальности про пирамиду, я вижу это как повышение селф ответственности за свой код

Плюсую.
Это уменьшает возможность каких-то очевидных ошибок.
Из своей практики: у меня был разработчик, который покрывал свой код тестами на 100% -  это помогало ему писать код практически без багов, он был в нем уверен 🤷🏻‍♀️

1. возможность запускать части кода без запуска всей системы
2. документация к коду
3. помощь в проектировании
4. быстрая обратная связь от вносимых изменений
5. уверенность в вносимых изменениях

Чтобы другие разработчики не показывали пальцами и громко не смеялись после коммита в мастер. Это важная часть shame-driven девелопмент в компаниях с "инженерной культурой разработки". (по крайней мере, с юнит-тестами ты всегда можешь сказать, что ты сделал все что мог.)

чо как там про интеграционные тесты? 😜

1. Unit-тестирование помогает улучшить качество кода (код становится понятнее, потому что сами модули становятся тестируемыми)
2. Меньше риск, что рефакторинг поломал старый функционал.
3. Разработчик задумывается о том, как именно должен работать его код, поэтому на ранних этапах обращается к аналитику за уточнениями и не ленится понимать, зачем именно он пишет этот модуль и что конкретно он должен делать.
4. Старается не писать излишний код, потому что его придется тоже покрывать тестами.
5. Рабочие тесты добавляют уверенности в своем коде и в себе как в специалисте.
6. Меньше получает по башке от тестировщиков - потому что меньше багов.
7. У разработчика выше зарплата и больше перспектив, потому что многие компании требуют написание юнит-тестов.

Юнит тесты помогают разработчику убедиться, что его изменение в коде не повлияло на поведение всего остального кода настолько сильно, что какой-то отдельно взятый юнит кода стал абсолютно бессмысленным по мнению автора юнит теста.

На качество кода, а, тем более продукта, они абсолютно не влияют.

Они никому не нужны, тестировщики тоже

вот это наброс! =)

я тебя запомнил

Я тоже. Айда вместе работать!

Вот это ближе к правде

1 убеждаются, что он работает как ожидается
2 дизайн кода под нужное поведение (привет TDD, думаю о том, как это должно работать и использоваться)
3 закрепление поведения методов и функций,  (страховка от неожиданных изменений)
4 уменьшение страха перед изменениями,
5 разделение ответственности за работу кода (отход от : я пишу - а ты проверяешь)
6 замедляют доставку до прода - разработчик успевает передумать между коммитом и доставкой в прод
7 увеличивают стоимость изменений кода - если это не важно и нужно, разработчик 100 раз подумает поменять что-нибудь (никаких спонтанных изменений в коде, и это прекрасно!)

Это показывает, что задача, которую они сделали работает и работает так как надо/ожидается.
Другое дело, что не все можно и нужно покрывать юнит тестами. По моему опыту, в больших системах проблемы вылезают обычно на более высоких уровнях, но это уже отдельная дискуссия

Коллеги, посоветуйте, пожалуйста, test management tool, чтобы поддерживала синхронизацию со спринтами в Jira и автоматизацию.

Заказчик хочет видеть отчеты о тестировании в Джире — по спринтам и по отдельной story. Раньше пользовались майндкартами и Testpad, их перестало устраивать, хотят синхронизацию! 😅

Я сейчас рассматриваю Testy, Zephyr,  Testflo, Sguash, XRay. Может что ещё что-то упустила?

а автотесты есть?
Вон в @allure_ru напиши, спроси триал. Они пилят EE версию, с функционалом на замену testrail

Adaptavist

Adapta действительно хороша, если какие-либо вопросы к атласиан, то можно ещё SpiraTest рассмотреть, он интегрируется с Jira, но с определёнными плясками с бубном ) поэтому АТМ очень даже неплохое решение (Adaptavist Test Menedgment - как раз утилитка Jira)