Комментарии 34
Очень много букв, не осилил.
Осилил, но ничего не понял. Кто может пояснить, что тут имеется ввиду под "автоматизацией тестов"? Тесты выполняемые при CI?
Автоматизация тестирования - процесс написания кода на языке программирования для проверки работоспособности приложения методом выполнения некоторых последовательностей действий над частями приложения, которые в идеале должны приводить к ожидаемым результатам.
Частями приложения в зависимости от типа теста могут быть: одиночные функции, API методы, интерфейс.
Где и как такие тесты должны выполняться (и кем должны имплементироваться) - зависит от многих факторов, в частности от той самой пирамиды: насколько легко пишется тест, насколько долго он выполняется, насколько сложное окружение ему нужно для выполнения.
Автоматизация тестирования - процесс написания кода на языке программирования для проверки работоспособности приложения методом выполнения некоторых последовательностей действий над частями приложения, которые в идеале должны приводить к ожидаемым результатам.
А где тут автоматизация? Чем это определение отличается от тестирования? Вообще странно, 'автоматизация - это процесс написания кода'
Почему 'в идеале? Это не обязательно?
Ставь лайк, если пилил ui-ные автотесты, ибо заказчик тестирования просил именно так, а спустя время вся работа превратилась в поддержку этих тестов, и лучшим способом закончить всё это стало увольнение :D
Мне нормально статья зашла. Всё верно - во многих командах разработки телега уже бежит впереди лошади.
Тема знакомая. Это с незапамятных времен так...
Однажы довелось видеть комманду где из-запервернутой тестовой пирамиды вообще команда только и занималась починкой 2e2 тестов и медленно релизила что-то.
Причем качество релизов никак не становилось лучше... Через 3-4 года их проект просто закрыли - ребята и девчата, все не могли проделиверить фичи с приемлимой скоростью.
Но продолжаю наблюдать игнор юнит тестов и прыжок сразу в мануальное прокликивание или автомазирование прокликивания...
Это конечно тесно связано и с организационными причинами. Происходит в основном там, где нанимают таку ОТДЕЛьНУЮ роль как "тестировщик". И девелоперу становится "удобно". Веть за качество и за тесты у нас "тестировщик" отвечает... и сама организация нанимающая отдельных людей для это-го естественно это так и видит как норму.
Не воспринимайте близко, но по моим наблюдениям, в восточной европе (аутсорсинг) прям это любимая тема..
Т.е. отдельного человека для тестирования быть не должно?
Тогда и аналитиков выкинуть нужно, чтоб разработчикам не было 'удобно', и ещё добрую половину команды.
Одного разработчика оставить, короче
Зависит очень от совта продукта и прочего...
Есть области где это Ок и работает отлично.
У меня лично нет проблем хоть с масажистами в комманде. Когда девелоперы сделали свою работу написали юниттесты, тесты интеграции... и вы смотрите на это и вам все ещё надо ловить определныные проблемы качества более дорогими тестами с выделеными спецами фля это-го, то ради бога... Но не перепрыгивайте базовые вещи
Да в любой разработке на заказ автотесты пытаются продать как отдельную услугу. Хотя ежу понятно, что это должно быть частью методики разработки. Как дом не строят без строительных лесов. Заказчик же не говорит: "За леса платить не буду!". Потому что это тупо часть технологии изготовления. Почему в АйТи не так - я к сожалению не могу найти вменяемого ответа.
То, что ты не умеешь делать это дешево, потому что у тебя слабый "DevOps", это твоя проблема. Крутые компании тем и отличаются, что вложились, настроили DevOps конвеер для типовых задач и теперь стоимость производства у них более конкурентная чем у других.
Я бы ослабил утверждение статьи - дело не в правильном или неправильном подходах, а в поиске баланса между стоимостью поддержки и потенциальным риском.
Если E2E-тесты покрывают только базовые сценарии, то рано или поздно что-нибудь "взорвётся" в других сценариях. Наличие юнит-тестов от этого не застрахует, т. к. обязательно возникнет какой-нибудь неучтённый особый случай (как правило - что-нибудь нестандартное на стыке разных компонент системы).
Поэтому смысл в "избыточных" (в терминах статьи) E2E-тестах всё равно есть. Но, конечно, до тех пор, пока в компании/команде хватает ресурсов на их написание и поддержку.
Да. Причем потенциально — для каждого отдельного теста, и покрываемой им функциональности. Потому что иначе можно например дойти до того, что начать покрывать тестами совершенно рутинный и тупой код, в котором багов вообще не бывает, где трудозатраты будут, а профита не будет никогда.
Проблема в том, что e2e ломаются раньше, чем что то найдут.
это проблема кривых рук автотестеров (чаще) и окружения (реже).
Те варианты, когда разрабу проще удалить всю форму и натыкать новых кнопок, да ещё и описание у них text1 text2 вместо было name, family вы вообще не рассматриваете? Тут вина тестировщика в чем? А потом ui система автоматизации. попросту пишет не удалось найти форму, лови error.
Это проблема того, что девы не видят выхлопа тестов. В противном случае они сохраняют идшки, зная что могут быть причиной падений тестов.
Ну а поправить идшки в форме это вообще не проблема. Вот если меняется флоу, то сложнее. Тут все зависит как написаны тесты, поправить в 1 месте не проблема.
Вначале я сам ставил идшки в ios коде. Через пол года, когда авто тесты стали находить быстро регресии, програмисты сами стали помогать и сохранять идшки.
Сейчас у нас 870 тестов мобильных тестов под ios и столько же под android.
Представьте как обслуживать это? Так вот у нас всего 2 авто тестера на эти мобильные, апи (сейчас очень много его), веб и т.д.
Все зависит от того как написано, так и обслуживаться будет.
В некоторых компаниях тесты пишут сами разработчики. Тогда у него повышается мотивация писать код так, чтобы тесты не ломались. И повышается ответственность за баги.
В статье ещё не упомянут важный фактор, который, имхо, тоже повышает приоритет мелких тестов: стоимость фикса.
Unit-тест, написанный разработчиком, сломается ещё на его локальной машине (при рефакторинге, например), и будет починен ещё до попадания кода в репозиторий
В клиент-серверной или сервисной архитектуре тест на API (написанный уже скорее всего QA-автоматизатором) сломается до того, как его попытаются интегрировать в себя другие части системы.
А E2E тест выполняющийся на околопродакшновом окружении фиксить вообще тяжело. Необходимо будет понять, что из частей системы вообще сломалось, затем воспроизвести это поведение поближе к девелоперам (что может быть не очень просто при росте количества шагов в E2E тесте), починить, пройти ревью/мержи/делпой на нужное окружение и дождаться следующего запуска тех самых E2E тестов.
К счастью повезло не работать в таких командах, где такая шняга практикуется.
Обычно, если занимались e2e тестами, то их писали сами разработчики, и править их приходилось не часто.
Но их было достаточно много и они покрывали практически все основные сценарии.
Это несколько раз очень сильно помогало при масштабных рефакторингах и миграции с .net framework на .net core.
По времени работы — если все запускать последовательно, то очень долго, но такое только в ci/cd делается — там и распараллеливание есть, что даёт достаточно хороший отклик в несколько минут после запуска.
Утверждение, что юнит тесты являются самыми дешевыми - очень спорное. Как и то, что интеграционные и e2e разработчик не может запустить на своей машине в эпоху docker/k8s
Можете пояснить про юнит тесты? Почему они не дешёвые?
Вы про написание/поддержку/запуск?
Разработка и поддержка не так уж и дешева, особенно с учетом того, что интеграционные и e2e все равно писать. Из плюсов только быстрое выполнение.
На мой взгляд, unit-тесты целесообразны только для хитрой mission critical бизнес-логики. Все остальное приложение должно максимально покрываться интеграционными/e2e тестами.
Но если есть куча ресурсов или если разрабатывается core сервис или библиотека, то, конечно, имеет смысл весь код unit-тестами покрыть
Может быть проблема не в e2e тестах, а в том, что пишут их иногда левой пяткой, что ведет к сложной поддержке, поломкам и т.п.
Наверное не открою Америку, если скажу, что хороший фреймворк интеграционного тестирования -- это такой же программный продукт как и то, что он тестирует. И требования к качеству кода, архитектуре и документации у него, соответственно, должны быть такими же строгими. Тогда и ломаться раз в день не будет и поддержка станет легче.
Согласен с автором в том, что все надо оценивать с позиции стоимости (написания и поддержки) и ценности (сэкономленное время QA и разработчиков, стабильность продукта), но тезис "не автоматизируйте test cases" явно неверный. Правильно: думайте, прежде чем автоматизировать, а если автоматизируете - то делайте это хорошо.
все верно! я видел толпы автоматчиков, работу которых никто в фирме не понимает, кроме них самих.
1) любые тесты должны быть такими, чтобы их запускали ВСЕ члены команды. Мануальщики в первую очередь, программеры во вторую, а сами автоматчики в последнюю.
2) качество описания ошибки в тесте должно быть таким, чтобы ваша жена (врач, учитель и т.д.) поняли не зная вашего продукта. Не поняли, вы показываете стактрейс или строку кода, где упало - это никому не понятно и не нужно кроме вас самих.
3) наличие видео крайне повышает комфортность и полезность (хотя вначале так не кажется пока не начнешь пользоваться). Ясно, что с АПИ так не получится, а вот web + mobile видео обязательно давно.
4) большинство регрессий должно быть найдено, до того как мануальщики пытаются скачать новый билд и запустить (грубо. понятно что скажем мобильные тесты помедленнее).
Есть еще класс тестов это юнит, проверяемые через ui, проверяют только одну функцию - вообще жесть. Зато удобно ручнику - в день написал 20 тк, и «автоматизатору» - в день написал 15 e2e.
Во-первых мне традиционно не нравятся QA, которые лезут в юнит-тесты. Вы ещё доктесты начните обсуждать.
Во-вторых, главным достоинством хороших тестов является их изолированность. Они идут со своим кодом и пока этот код не трогается, не ломаются.
Из этого можно сделать вывод, что большинстов интеграционных или e2e тестов плохие, потому что они всё время ломаются даже если оригинальный код не менялся. Микроскопическое множество хороших опирается на RFC, нарушение которых - уже проблема другой команды.
Очень много букв, ... осилил
Мысли автора очень трезвые, но озвучивать Правду Этого порядка - это дело Героев или Святых. Боссы , для которых прибыль превыше всего эту статью не одобрят (QA для них - это статья расходов да и только). Но те, кому важно Качество - да, да, и ещё раз Да!
Это автотестирование порой превращается в полный абсурд. Есть деятели, которым похоже просто нравится писать эти тесты, отчитываясь о проделанной работе. Нередко я вижу, когда для кода в 10 строк городится на порядок больше строк юнитестов со сложностью, которая, опять же на порядок выше сложности собственно самой функциональности. Дальше, изменение в одну строчку в функциональности, ведет к на порядок более сложным правкам в тестах. В результате, отлаживаеть приходится уже даже не функциональность (о которой давно все забыли), а юнитесты, которые пытаются заставить как-то работать.
Я не знаю как это победить. Потому что оппоненты всегда пускаются в пространные рассуждения о том, что я недооцениваю важность юнитестов и т.д. и т.п. Менедженов все эти наукообразные рассуждения со множеством бессмысленных слэнговых словечек часто убеждат.
А вы аппелируйте к тому, что тесты НЕ должны все все покрывать. Ибо система которая тестирует любое приложение на 100% всегда сложнее самого приложения.
Кому надо, чтобы затраты на тестирования были больше создания? Есть конечно варианты: космос, медицина, системы управления - если ваша апка к ним не относится, вы не должны покрывать все случаи. Это дорого.
Это отлично в теории, на практике может быть совсем не так. Что предлагается взамен? Могу только предположить, что в какой-то мере UI можно попробовать тестировать с API-моками типа cy.intercept() в Cypress. Это даже может быть похоже на рельную работу в чем-то. От тестирования UI нельзя избавиться просто, не снижая покрытия. Плюс есть проблемы, которые нельзя легко обнаружить без настоящего API, например, проблемы производительности, это придется планировать отдельно.
Плюс говорится о том, что в основном e2e-тесты представляют собой набор действий, которые выполнял бы тестер в ручную, тогда как надо тестировать функционал, а не сценарии. Тут я тоже не понял, что предлагается взамен.
Единственное, что мне пришло в голову по этому поводу,- это попробовать что-то вроде State Transition Diagram как источник функциональных переходов для e2e-тестов. Это будут не совсем те тесты, но, по идее, может быть интересно посмотреть, как это работает. Не факт, что будет лучше. Оно может для чего-то подойти, но… тестинг штука контексто-зависимая.
Итого, что имеем в остатке:
1. Юнит-тесты (пишут программисты)
2. API-тесты на живом сервисе или через мок базы (контрактное и функциональное)
3. Интеграционное тестирование
4. Отдельное тестирование UI по переходам?
Даже не знаю. У кого какие идеи есть?
Не автоматизируйте test cases