Тесты, не для того, чтобы находить ошибки, а для того, чтобы быть уверенным в том, что код ведет себя так, как предполагается. Особенно это актуально в случаях, когда требования заказчика часто меняются, и код приходится дорабатывать и рефакторить.
Не смотря на это я не раз имел возможность убедиться в том, что и автотесты находят ошибки. Если вы не сталкивались, то существуют случаи, когда ошибка проявляется не каждый раз, в лишь при некоторых обстоятельствах. При этом у автоматических тестов, которые запускаются десятки раз в сутки, шансов обнаружить такую ошибку соответственно в десятки раз больше, нежели при ручном тестировании.
Поэтому я и написал "уже наверное можно", а не "уже точно можно". Я считаю что в задачах, которые относительно недорого формализуются нет смысла полагаться на ручной труд. Это заведомо проигрышная стратегия.
Ошибки верстки для проектов, в которых я принимал участие, составляли не более 3% от общего объема проблем. Причем часть из них отлично обнаруживается в процессе функционального тестирования тем же Selenium-ом (наложение-перекрытие элементов управления). Ну а "Pixel Perfect" для меня неактуален. Я в таких проектах участия не принимаю
Кстати, на текущем уровне развития автоматизации 50 тестов через браузер вручную прогнать быстрее живым человеком.
Вы это серьезно? Продемонстрировать можете? У меня вот есть видео с куском из 22-ух e2e тестов, выполняемых на почти старинном ноутбуке, записанное год назад. Selenium год назад делал это за 34 секунды. Можете показать что-нибудь подобное, что делает ручной тестировщик быстрее?
Какой такой "автоматизатор"? Я как разработчик пишу сначала тесты, потом код. Когда начинается проект, я настраиваю новое задание в CI сервисе (Jenkins), которое загружает мой код из GIT репозитория после каждого его обновления, и автоматически собирает приложение, запускает тесты, загружает данные и снова запускает тесты. При этом мне не нужен никакой специальный дополнительный автоматизатор. Один раз настроил и оно работает. Один раз написал тест, и он при каждом прогоне будет гарантированно выполняться и проверять продолжает ли приложение работать как ожидается.
Когда мы обнаруживаем какой-то новый сценарий использования приложения, для которого у нас еще нет теста, мы просто добавляем новый тест к существующим наборам.
У меня сейчас в бэкенде, в проекте, который стартовал два месяца назад, только модульных тестов 1100. Больше сотни тестов REST API, которые ежедневно выполняются по нескольку десятков раз. Какая тут мне может быть польза от ручного тестировщика?
Когда я занимался фронтендами, у меня в небольшом относительно проекте было порядка 50 e2e сценариев (Selenium), которые проверяли основную функциональность SPA Web приложения. При разработке, в течение дня я иногда запускал эти сценарии по нескольку десятков раз. Если бы я делал это руками, у меня бы дня рабочего не хватало чтобы только тесты прогнать. Вы правда думаете что ручной тестировщик сможет адекватно протестировать 50 сценариев, 10 раз за день?
"Думать" да, не автоматизируется, а "оценка рисков" автоматизируется вполне успешно сплошь и рядом.
Где вы увидели у меня призыв к немедленной тотальной автоматизации? Я написал "ВСЕ, что МОЖЕТ быть автоматизировано".
Насчет сопоставления стоимости ручного и автоматизированного тестирования я не понял. Вы предполагаете что автоматизированный сценарий тестирования интерфейса, написанный с использованием какого-нибудь Selenium-а, будет в долгосрочной перспективе в эксплуатации обходиться дороже, нежели ручной тестировщик?
В наше время много чего уже известно о природе и психологии человеческой, однако знания эти не мешают нанимателям практиковать устаревшие, но любимые ими методы управления.
Есть еще вопрос, который я задаю потенциальным нанимателям после стажировки в одной достаточно крупной софтверной компании.
Используются ли при учете рабочего времени системы журнализации и записи действий разработчика за компьютером? Удивительно было после первого рабочего дня обнаружить в автоматизированном табеле уведомление — "Учтено 6,5 часов. Необходимо доработать 1,5 часа".
Мне кажется автоматизированно тестировать в наше время можно что угодно. Было бы желание и средства. Ну а сделать с нуля классный проект, особенно если он масштабный, на мой взгляд невозможно, если нет никаких автоматизированных средств контроля качества.
По-моему в тестировании достаточно следовать всего одному принципу — "Все, что может быть автоматизировано, должно быть автоматизировано"… тогда и другие подходы придумывать не придется… некогда будет.
Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.
В каких интересно командах ценятся "долгие и бессмысленные коммуникации"?
На мой взгляд это совершенно правильное стремление развивать культуру инженерных коммуникаций на базе формальных описаний, а не пустопорожних рассуждений. Особенно если посмотреть на все это со стороны, которая платит за разработку. Меньше всего хочется оплачивать бесконечные и бесполезные совещания и планерки.
На мой взгляд как раз мода на черные корпуса была. Мой первый 486-ой был в черном корпусе. Сложнее было купить монитор в черном корпусе, но даже в Тюмени, в относительно небольшом компьютерном салоне мне такой нашли.
Такое нереальное количество времени на запуск модульных тестов требуется только тогда, когда все разработчики все поведение раскладывают именно в Angular компоненты. Поэтому сокращение количества времени на выполнение модульных тестов обычно дает банальное разделение ответственности, упоминающееся в SOLID. Все поведение, не использующее ничего из пространства имен angular, реализуем в отдельных классах, которые затем используем уже собственно в компонентах. При таком раскладе необязательно и в броузерах тесты запускать вовсе. А компоненты являются просто фасадами и адаптерами для низлежащего, уже протестированного поведения.
Ну и в каких командах разработчики счастливее? В тех, что используют TDD, или в тех, где TDD не используется?
Считаете ли вы важной возможность повторного использования кода? Практикуется ли повторное использование кода, в том числе кода, написанного другой командой?
Тесты, не для того, чтобы находить ошибки, а для того, чтобы быть уверенным в том, что код ведет себя так, как предполагается. Особенно это актуально в случаях, когда требования заказчика часто меняются, и код приходится дорабатывать и рефакторить.
Не смотря на это я не раз имел возможность убедиться в том, что и автотесты находят ошибки. Если вы не сталкивались, то существуют случаи, когда ошибка проявляется не каждый раз, в лишь при некоторых обстоятельствах. При этом у автоматических тестов, которые запускаются десятки раз в сутки, шансов обнаружить такую ошибку соответственно в десятки раз больше, нежели при ручном тестировании.
Поэтому я и написал "уже наверное можно", а не "уже точно можно". Я считаю что в задачах, которые относительно недорого формализуются нет смысла полагаться на ручной труд. Это заведомо проигрышная стратегия.
Ошибки верстки для проектов, в которых я принимал участие, составляли не более 3% от общего объема проблем. Причем часть из них отлично обнаруживается в процессе функционального тестирования тем же Selenium-ом (наложение-перекрытие элементов управления). Ну а "Pixel Perfect" для меня неактуален. Я в таких проектах участия не принимаю
Вы это серьезно? Продемонстрировать можете? У меня вот есть видео с куском из 22-ух e2e тестов, выполняемых на почти старинном ноутбуке, записанное год назад. Selenium год назад делал это за 34 секунды. Можете показать что-нибудь подобное, что делает ручной тестировщик быстрее?
Какой такой "автоматизатор"? Я как разработчик пишу сначала тесты, потом код. Когда начинается проект, я настраиваю новое задание в CI сервисе (Jenkins), которое загружает мой код из GIT репозитория после каждого его обновления, и автоматически собирает приложение, запускает тесты, загружает данные и снова запускает тесты. При этом мне не нужен никакой специальный дополнительный автоматизатор. Один раз настроил и оно работает. Один раз написал тест, и он при каждом прогоне будет гарантированно выполняться и проверять продолжает ли приложение работать как ожидается.
Когда мы обнаруживаем какой-то новый сценарий использования приложения, для которого у нас еще нет теста, мы просто добавляем новый тест к существующим наборам.
У меня сейчас в бэкенде, в проекте, который стартовал два месяца назад, только модульных тестов 1100. Больше сотни тестов REST API, которые ежедневно выполняются по нескольку десятков раз. Какая тут мне может быть польза от ручного тестировщика?
Когда я занимался фронтендами, у меня в небольшом относительно проекте было порядка 50 e2e сценариев (Selenium), которые проверяли основную функциональность SPA Web приложения. При разработке, в течение дня я иногда запускал эти сценарии по нескольку десятков раз. Если бы я делал это руками, у меня бы дня рабочего не хватало чтобы только тесты прогнать. Вы правда думаете что ручной тестировщик сможет адекватно протестировать 50 сценариев, 10 раз за день?
"Думать" да, не автоматизируется, а "оценка рисков" автоматизируется вполне успешно сплошь и рядом.
Где вы увидели у меня призыв к немедленной тотальной автоматизации? Я написал "ВСЕ, что МОЖЕТ быть автоматизировано".
Насчет сопоставления стоимости ручного и автоматизированного тестирования я не понял. Вы предполагаете что автоматизированный сценарий тестирования интерфейса, написанный с использованием какого-нибудь Selenium-а, будет в долгосрочной перспективе в эксплуатации обходиться дороже, нежели ручной тестировщик?
В наше время много чего уже известно о природе и психологии человеческой, однако знания эти не мешают нанимателям практиковать устаревшие, но любимые ими методы управления.
Есть еще вопрос, который я задаю потенциальным нанимателям после стажировки в одной достаточно крупной софтверной компании.
Используются ли при учете рабочего времени системы журнализации и записи действий разработчика за компьютером? Удивительно было после первого рабочего дня обнаружить в автоматизированном табеле уведомление — "Учтено 6,5 часов. Необходимо доработать 1,5 часа".
Мне кажется автоматизированно тестировать в наше время можно что угодно. Было бы желание и средства. Ну а сделать с нуля классный проект, особенно если он масштабный, на мой взгляд невозможно, если нет никаких автоматизированных средств контроля качества.
Это круто! Я собеседовался раз пятьдесят и мне всегда говорили что писать тесты разработчикам некогда.
По-моему в тестировании достаточно следовать всего одному принципу — "Все, что может быть автоматизировано, должно быть автоматизировано"… тогда и другие подходы придумывать не придется… некогда будет.
Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.
И как? В скольких из сорока компаний все разработчики пишут тесты?
В каких интересно командах ценятся "долгие и бессмысленные коммуникации"?
На мой взгляд это совершенно правильное стремление развивать культуру инженерных коммуникаций на базе формальных описаний, а не пустопорожних рассуждений. Особенно если посмотреть на все это со стороны, которая платит за разработку. Меньше всего хочется оплачивать бесконечные и бесполезные совещания и планерки.
На мой взгляд как раз мода на черные корпуса была. Мой первый 486-ой был в черном корпусе. Сложнее было купить монитор в черном корпусе, но даже в Тюмени, в относительно небольшом компьютерном салоне мне такой нашли.
Такое нереальное количество времени на запуск модульных тестов требуется только тогда, когда все разработчики все поведение раскладывают именно в Angular компоненты. Поэтому сокращение количества времени на выполнение модульных тестов обычно дает банальное разделение ответственности, упоминающееся в SOLID. Все поведение, не использующее ничего из пространства имен angular, реализуем в отдельных классах, которые затем используем уже собственно в компонентах. При таком раскладе необязательно и в броузерах тесты запускать вовсе. А компоненты являются просто фасадами и адаптерами для низлежащего, уже протестированного поведения.
В очередной раз убедился что не все, что порой хочется сказать обязательно писать… и публиковать...
Бальзам на душу. А я то уж думал что у меня одного такое положительное ощущение от использования TDD.
Улучшает ли использование TDD внутренний дизайн приложений? Позволяет ли качество написанных тестов считать их исполняемой документацией по коду?
Ну и в каких командах разработчики счастливее? В тех, что используют TDD, или в тех, где TDD не используется?
Считаете ли вы важной возможность повторного использования кода? Практикуется ли повторное использование кода, в том числе кода, написанного другой командой?
А тесты в процессе разработки пишутся по TDD? Или потом, когда весь код уже написан?