Comments 34
Я так понимаю, вы описали не сами тесты, а их классы. А что по поводу конкретных видов acceptance-тестов?
Предположим, программист оправдывается тем, что хочет повысить качество и надёжность продукта. Но, необходимый уровень качества и надёжности уже заложен в продукт на этапе бизнес-планирования, риски оценены и застрахованы. Получается, что своими действиями (повторное тестирование) программист сохранит 1 клиента, когда без этих действий он бы принёс (за счёт разработки новой функциональности) 2 новых клиентов. Вопрос: зачем тратить ресурсы на то, что не приносит прибыль (или даже убытки)?
Это означает, что программист пишет код, а тестировщик тестирует код.
Давайте по другому посмотрим на вопрос. 50 автоматизированных тестовых последовательностей вызовов конечных точек web API отрабатывает за 27 секунд. В каждой последовательности в среднем 3 обращения к web API. То есть суммарно это около 150 HTTP запросов. Сколько времени понадобится ручному тестировщику, чтобы выполнить вручную эти 50 тестовых сценариев и оценить их результаты визуально?
1. кому-то придумать,
2. кому-то автоматизировать,
3. кому-то выполнить и оценить результаты (они ведь не автоматические).
Во-вторых, почему тестировщик обязательно должен выполнять всё вручную? Он что, слишком тупой? По-вашему, только программисты разбираются во всех этих девопсах?
В третьих, сценарии и юнит-тесты — это одно, а контроль качества — это другое. Все необходимые сценарии, критерии и нормы закладываются ещё до того, как программист начинает что-то писать. Возможно, программист захочет протестировать эти 50 API endpoints, а менеджеру важны лишь 20 из них, а остальные — это доп. функциональность, которая не влияет на покупательную способность (а лишь на лояльность клиентов). Возможно, рынок и так уже захвачен или наоборот, компания решила покинуть рынок, снять сливки (привет, iphone). Получается:
1. программист сделал дополнительные 50 тестов
2. программист выполнил 30 лишних тестов
3. кпд тестирования = 20/(20+50) = 30%.
3. кому-то выполнить и оценить результаты (они ведь не автоматические).
Мне кажется вы тут ошиблись. Смысл автоматизированных тестов — это возможность их работы без участия человека. Нажали кнопку и на выходи получили знание — тесты прошли или нет.
критерии и нормы закладываются ещё до того, как программист начинает что-то писать
Вы описываете waterfall подход?
У меня таких проектов очень давно не было, сейчас везде agile и lean подходы. Ничего заранее не делается, кроме бизнес историй, да и те по мере надобности детализируються.
Смысл автоматизированных тестов — это возможность их работы без участия человека.
Нет, это смысл автоматических тестов. А автоматизированные тесты предполагают разомкнутый процесс тестирования, контролируемый и управляемый человеком.
1. Нажал кнопку — всё сломалось.
2. Починил — некоторые тесты не прошли проверку.
3. Создал тикет/задачу.
4. Дождался фикса и по новой с п. 1.
Вы описываете waterfall подход?
Не совсем. Просто классическое планирование бизнеса и его процессов, которое включает контроль качества и анализ рисков.
Возможно, программист захочет протестировать эти 50 API endpoints, а менеджеру важны лишь 20 из них, а остальные — это доп. функциональность, которая не влияет на покупательную способность
Странное на мой взгляд допущение. То есть мы предполагаем что программист программирует то, что ему хочется, в отрыве от требований? Ну взял просто реализовал вместо 30 нужных бизнес-функций, которые описаны в требованиях, еще 20 дополнительных, которые ему показались прикольными? А менеджер взял ему за это заплатил еще?
Вы ведь тоже не перестаёте ходить в магазин после ежегодного роста цен на 10% или резкого повышения тарифов на городской транспорт.
С другой стороны, возможно, это 30 задач из бета версии, которую пока не планируют выпускать на рынок, а просто тихо-мирно тестируют на клиентах.
А быть может, необходимо срочно закрыть 20 важнейших задач до конца года.
Вопрос: зачем программист повторно тестирует код, если за это уже платят другому человеку?
Конечная цель же не платить человеку, а разработать качественный софт. Где-то мы сравнили два подхода и подсчитали, что выгодней разделить разработку и тестирование. Именно поэтому у нас появился тестировщик.
Тут очень много вопросов к сравнили и подсчитали. Что, как, какие сценарии рассматривались.
В целом, тестов никогда не бывает много. Конечное качество продукта достигается эшелонированием разных подходов. Они дополняют друг друга. И юнит тесты и акцептант тесты и ручное тестирование — они независимо ценны.
Вопрос: зачем тратить ресурсы на то, что не приносит прибыль (или даже убытки)?
Опять это вопрос к бизнесу, и это сильно зависит от проекта и конкретных обстоятельств.
Приведу случай из практики. Бизнес тратит 100т денег каждый месяц на разработку проекта в течении полтора года, подписывает контракт на поставку проекта. Готовый продукт имеет проблему, по контракту бизнесу приходиться выплатить компенсацию в размере 10 миллионов денег.
Противоположный случай можно придумать — сайт Василия Пупкина. Ни тестировать, ни заходить на него нет никакого смысла.
Большенство интересуемся нас случаем будут по средине, я думаю.
Конечная цель же не платить человеку, а разработать качественный софт.
Ха ха ха. Вы, явно, не владелец бизнеса, а работаете на какую-то компанию.
Тут очень много вопросов к сравнили и подсчитали.
И юнит тесты и акцептант тесты и ручное тестирование — они независимо ценны.
Опять это вопрос к бизнесу
Я не спорю с тестированием и с TDD, не говорю о бесполезности тестирования программистами своего ПО. Я говорю о ситуации, когда начальник сознательно заложил (или не заложил, или неполностью заложил, или заложил отсутствие в цену ПО) тесты тому или иному работнику.
И я говорю, что, возможно, бизнесу всё-таки стоит больше использовать тесты чем вероятности.
В целом могу сказать, что вместо тестов начальники любят оперировать показателями надёжности (они даже в ГОСТах записаны). Самое адекватное и широко используемое средство. Не программист в тестах не разбирается, ему гораздо понятнее фраза: «ПО сломается в вероятностью 0,99995,» или даже: «Сервер будет простаивать не более 1 часа в год.»
Но у всех начальники разные.
Какой показатель указывает на это?
Субъективный. А если к примеру отчитаться о 10 часах дебага? Это будет упущенная выгода? Или менеджер должен быть счастлив?
Я всегда сначала пишу тесты, потом код. И считаю что для любого кода нужно и можно сначала писать тесты. Не важно серверные это приложения или клиентские. При разработке бэкендов у меня всегда есть модульные тесты и тесты API, которые я обычно пишу на Javascript + Node.js. Если говорить про разработку фронтендов, то в этом случае я обычно сначала пишу модульные тесты для компонентов, благо все современные фреймворки это позволяют, а затем пишу тестовые сценарии для пользовательского интерфейса, используя Selenium-Webdriver.
Разработка тестов — это отдельный навык, и если у разработчика он отсутствует, то он не сможет писать хорошие тесты, и не захочет их писать. И это нормально на мой взгляд ибо никто не любит делать то, что у него плохо получается.
На мой субъективный взгляд и опыт TDD не очень модная тема в отрасли. Я много общался с разработчиками из разных команд. Это были и крупные компании и совсем маленькие коллективы. Никто не сознался в том, что пишет тесты. Я лично знаю лишь пару программистов, которые всегда пишут тесты, потом код. Так что считаю что мы вымирающий вид. Технологические динозавры. Потому что сам подход разработки через тестирование был придуман Кентом Беком достаточно давно, если судить даже по человеческим меркам.
Так что считаю что мы вымирающий вид. Технологические динозавры.Не соглашусь. У нас, по сравнению с остальными есть преимущество в качестве и в экономике проекта. Эволюционно именно команды использующие TDD или просто автоматические тесты выигрывают на длинной дистанции.
Эволюционно именно команды использующие TDD или просто автоматические тесты выигрывают на длинной дистанции.
Коллега! Это неоспоримый факт! На длинной дистанции мы молодцы! Но где они? Эти команды? Лично я не знаю ни одной такой команды.
Вообще не видел бизнес-процесса ориентированного на сколько-нибудь длительный срок. Все известные мне предприниматели практикуют в рыночной среде стратегию "быстрого перепихона".
Вообще не видел бизнес-процесса ориентированного на сколько-нибудь длительный срок
Тут не совсем понятно, бизнес не рассчитывает на окупаемость вложений? Ресурсы вкладываются просто так?
Тут не совсем понятно, бизнес не рассчитывает на окупаемость вложений? Ресурсы вкладываются просто так?
Поторопился и неправильно сформулировал.
Последние 7 лет программирую в восновном финансовые приложения и автоматизацию для бизнеса. Несколько новых проектов подряд в виде стартапов. Управленческий подход такой — "быстро, за полгода пишем сложную бизнес систему без всяких тестов, успешно выводим ее на рынок, потом, когда cash flow наладится, будем приводить все в порядок". Вот это я обозначил термином "быстрый перепихон".
Подход имеет право существовать. Заказчик — барин.
Интересно было бы узнать как управленец в целом видит разработку, управление инженерными рисками, и как он это все оценивает.
Если у вас такие проекты идут постоянно, то можно попробовать порефликсировать на тему, что можно улучшить в разработке, не в ущерб приоритетам управленца. Возможно, добавить какие то практики будет не так страшно.
И, я думаю, будет прав. Написание юнит-тестов должно быть включено в эстимейт. У меня на практике получается, что при TDD вместо ручного тестирования после каждой итерации, время на разработку уходит такое же или лишь немногим больше, чем без тестов. Естественно, стараюсь покрывать happy path и ожидаемые ошибки.
Для современных историй, когда работаешь на одном месте год, осваиваешь новую для себя технологию, дописываешь соответствующую строчку в резюме и уходишь в новую компанию с повышением (а оставшиеся ещё несколько лет разгребают твоё legacy), затем
Бизнес, как правило, вольно или невольно (по глупости) выбирает именно второй вариант, не поощряя первый, ну да туда ему и дорога, в принципе.
Мы не то, что бы против тестов. Просто тесты — очень дорогое удовольствие, не прижились. Не дают почти никакой отдачи. Ну вот у нас — так.
Из особенностей кода. Код очень сильно связан. Копипасту максимально рефакторим. Стараемся, что бы код как можно раньше 'высыпался', есть заметное число ассертов и еще некоторые техники, помогающие максимально улучшить код без тестов.
Ссылку на софт если интересно, кину в личку.
Одними юнит тестами качество проекта не обеспечишь, даже в микросервисной архитектуре, не говоря про монолит. Главная боль это регресс пользовательских историй при сложной бизнес-логике, когда десятки-сотни памраметров влияют на поведение. Кроме того, продуманность архитектуры и тестируемость проекта.
Для решения подобной проблемы стоит активно использовать паттерны и принципы.
Для больших кусков с огромным числом исходов и вариаций поведения весьма сложно написать unit-тест
Ну так бейте большие куски на маленькие, тестируемые unit-ы, а уж потом собирайте из них большие куски, для которых тоже сначала пишите тесты. Single Responsibility Principle очень удобная штука.
Распределите огромное число исходов по обработчикам, из которых соберете потом цепочку ответственности. Хотя я предпочитаю плоский набор методов, который складывает результаты вызовов в контейнер состояния. Цепочки таки геморройней собирать и тестировать.
Опять же, скорость и время не всегда приоритетные показатели, качество продукта и стоимость его содержания (поддержки) может быть приоритетней.
Тут программисту важно понимать, экономические последствия своих решений. Если это proof of concept, то его нужно сделать быстро, не заботясь о качестве. Эта работа — одноразовая. Если нам нужно сделать быстро, качественно и дешево, то ищем другой проект ;-).
Есть и другой аспект, а как ценить влияние тестов на качество архитектуры проекта? А они влияют. Скажем, если хочется сгруппировать тесты, то скорее всего нарушен принцип Single responsibility и можно изменить композицию продакшн юнитов. Если количество тест кейсов больше 7, то с продакшен юнитом что то не так. Тесты помогают вывести улучшенную версию кода. Но архитектура проекта — это внутренний показатель (попробуй его еще оцени) и напрямую его не видно.
Тестирование и экономика проекта