Комментарии 96
— Серебрянной пули нет
— Надо использовать инструменты там, где это разумно
— Надо правильно расставлять приоритеты
Можно, но ваш коммент не убедит партнеров/руководство в принятии решения ЗА или ПРОТИВ автоматизированного решения. А эта статья убедит. Добавил в избранное.
Если подходить формально, то в статье, по большей части, всё верно. Но есть нюансы, которые очень значительно влияют на общее впечатление и финальные выводы.
Автоматические тесты надо уметь писать. Если тестировать немного не то и не так, то они, действительно, будут "хрупкими" (часто ломаться), на их разработку/поддержку будет уходить намного больше времени, польза от них будет сомнительна, и (с точки зрения менеджмента) затраты на их разработку действительно не будут окупаться. Но ровно то же самое касается и разработки кода: если нанять слабых разработчиков, которые пишут не тот код и не так, как надо — вместо фич будут только баги, разработка может занимать в разы больше времени, и затраты на неё не будут окупаться.
Без юнит-тестов мы запускаем в продакшн очень много кода, который никто никогда не запускал. Программист его "скомпилировал в голове" когда писал, но при ручном тестировании большая часть веток if-ов (и даже целых функций) ни разу не выполнялась. Особенно это касается кода обработки разных ошибок (сеть, БД, данные в некорректном формате, etc.). А, как известно из опыта, если код ни разу не запускали — как правило он корректно работать не будет.
Преимущества автоматических тестов
Не упомянута ещё несколько очень важных преимуществ.
Наличие автоматизированных тестов очень сильно ускоряет добавление новых фич и рефакторинг — вместо того, чтобы тратить время на попытку продумать и оценить последствия изменения кода можно его просто изменить и запустить тесты, если они проходят, то с высокой вероятностью эти изменения ничего не поломали (при наличии адекватных тестов, которые ещё нужно уметь писать, разумеется).
Автоматизированные тесты очень сильно упрощают тестирование в разных окружениях — с разными версиями OS, библиотек, кросс-платформенное тестирование.
Причина в том, что проверить изменение руками гораздо быстрее, чем автоматизировать тот же тест.
Очевидно, если это изменение руками тестируется уже в 3-5-й раз, то к этому моменту написать автоматизированный тест было бы быстрее.
В каждый отдельный момент, решая что выгоднее, писать тесты или не писать, второе всегда предпочтительнее.
Это не так, из-за упущенного Вами и упомянутого мной выше преимущества автотестов — их наличие сильно ускоряет внесение (качественных и работающих, наверное стоит добавить) изменений в код.
Ситуация в корне меняется в длительной перспективе.
Проблема в том, что если не писать тесты с самого начала, то начать их писать на более поздних этапах будет намного сложнее и дороже. Одна из причин этого чисто техническая — для того, чтобы тесты было возможно написать нужно чтобы код приложения был специально адаптирован под тестирование, что означает необходимость дополнительного рефакторинга кода (а иногда и архитектуры) если код изначально не писался с учётом необходимости его тестировать (а ещё давно замечено, что архитектура и код заметно улучшаются когда пишутся с учётом тестирования, и это ещё одна причина почему тесты стоит писать с самого начала). Другая причина чисто психологическая — тесты писать значительно менее приятно, чем основной код, поэтому когда возникает задача "у нас есть 100500 строк кода без тестов, надо покрыть их тестами" — руки просто опускаются, плюс всегда и у разработчиков и у менеджмента возникает вредная и некорректная мыслишка "до сих пор ведь всё работало без тестов, значит они особо и не нужны". Всё это сильно убивает и мотивацию, и продуктивность.
В результате экономить на написании тестов имеет смысл только если пишется какой-то реально одноразовый код, который никто и никогда не будет запускать в продакшне.
И замедляем не на 10%, а вдвое, втрое или даже больше.
Если тестировать то, что нужно, и так, как нужно — на тесты уходит примерно столько же времени, сколько и на код. Т.е. формально разработка замедляется вдвое, но это не учитывает вышеупомянутый фактор ускорения разработки благодаря наличию автотестов, а он начинает заметно сказываться на более поздних этапах, когда из-за увеличения общей сложности приложения скорость внесения изменений при отсутствии автотестов очень сильно падает. Если же на автотесты в среднем тратится вдвое больше времени чем на код — это хороший признак того, что скорее всего вы что-то не то или не так тестируете.
Но не все так просто.
Половина описанных в выводах статьи проблем связана скорее с неумением писать тесты, нежели объективными проблемами.
Каждый сам выбирает мир, в котором ему жить.
Безусловно, существует много проектов, в которых автотесты никто не пишет. И коммерческий успех или провал проекта вряд ли зависит от наличия или отсутствия автотестов — по крайней мере я такой зависимости пока не замечал. Так что я не пытаюсь сказать, что автотесты это серебрянная пуля и мастхэв, и без них никуда — если вдруг Вы поняли мой комментарий в этом ключе.
Я писал про то, что разработка автотестов — это отдельный навык, которому нужно отдельно учиться, как учат новые языки, фреймворки и парадигмы программирования (причём это в равной степени касается и крутых гуру/стар-разработчиков и всех остальных). И что большая часть проблем, с которыми сталкиваются при написании автотестов, вызвана не автотестами как таковыми, а неумением их писать (что включает и умение адаптировать архитектуру и код проекта под нужды тестирования).
В то же время очень сильно увеличивается время на переписывание существующих автотестов
тонкость в том что неумение писать тесты это тоже объективная проблема.
Точность — автоматические тесты проверяют ровно то, что описано в сценарии, во всех деталях и мелочах. Они не отвлекаются, не путают и не забывают.
Если бы ещё и сценарии писались бы точно, во всех деталях и мелочах, неутомимой машиной.
Проверить:
— штатную функциональность (типовое НСИ);
— защиту от дурака (не ту кнопку нажали);
— нагрузку (по данным и/или по юзерам);
Таких форм много (в корпоративных системах десятки и сотни).
Ваши конкретные предложения по автоматическому тестированию?
Штатное поведение как раз проще всего автоматизировать, особенно если UI не особо часто меняется. Тут важна стандартизация разработки — например, у каждого важного элемента должен быть уникальный, не меняющийся id. При таком раскладе можно написать один раз пачку тестов на селениуме (или CodedUITests в случае Win) и жить спокойно. А защита от дурака это уже негативные кейсы, их так же можно автоматизировать, как и штатное поведение, но уже с более низким приоритетом.
Нагрузку проверяет нагрузочное тестирование, оно ни к авто, ни к ручному особого отношения не имеет.
Вы меня заинтриговали (извините за сарказм), как же оно выполняется (или кем)? В вашем контексте «нагрузочное тестирование» это субъект, программа, технология или что?
у каждого важного элемента должен быть уникальный, не меняющийся id
О каком «важном элементе» идёт речь в данном контексте, кто и на каком этапе задаёт id, как гарантируется уникальность?
При таком раскладе можно написать один раз пачку тестов на селениуме
Тесты на селениуме? Очень интересно. А конкретный пример теста можно? Что-нибудь простое, например типа регистрации нового пользователя.
Тесты на селениуме? Очень интересно. А конкретный пример теста можно? Что-нибудь простое, например типа регистрации нового пользователя.
P.S. Как раз разработчик АСТ.
А как быть в случае, если баг проявляется в процессе взаимодействия пользователя с формой.
Например — пользователь с таким именем уже зарегистрирован в системе.
Или — пароль не прошёл валидацию на сложность.
Или просто произошла ошибка при сохранении данных.
Сможет ли автоматический тест решать такие задачи?
Пояснения: это не просто «селениум» и «тесты». Это полноценная АСТ (автоматизированная система тестирования). Она сложная и модульная (Микроядра->ядро->модули->тесты).
На скриншоте пример как раз модуля. Тест делает вызовы модулей. Модули делают обращения к подсистемам ядра. И вот уже в методах ядра идет вся «магия».
Если поле ввода не сработало по какой либо причине, то это будет зарегистрировано и занесено в лог.
Если пароль не прошел валидацию на сложность или данные внесены как-либо иначе не верно, то уже смотрим логику модуля, что отвечает за к примеру систему регистрации юзера на сайте — если это не допустимо, то тест рассчитывает на «не сохраняемость» этого юзера. И, в случае отказа, пишет что тест прошел верно. Если же юзер будет сохранен вопреки всему, то будет в отчетах указание соответствующей ошибки.
В довесок: если есть не критичные баги, то тест не будет завален, а АСТ будет пытаться продолжить выполнение проверок дальше (пример: нужно сделать проверку товара в каталоге… дата не сохранилась. На дальнейшие тесты влияет минимально — тестирование будет продолжено по веткам сценариев без аварийного завершения прогона).
Поэтому, подводя итоги — мы (качественные автоматизаторы) можем очень многое.
мы (качественные автоматизаторы) можем очень многое
Статью с таким названием я бы хотел прочитать.
А как быть, если просто нужен «качественный автоматизатор» тестов — какие к нему должны быть требования по скилам?
Статью с таким названием я бы хотел прочитать.
Уже 2 года как хочу ее написать. Однако есть два тормоза (время на это я нашел бы любой ценой как говорится):
Важный — разработка обошлась в серьезную сумму, много нервов и времени. Это закрытая информация.
Не важный — по-любому нахватаюсь кучу негатива в свой адрес, т.к. ПО явно не в мейнстримовом духе. Много не оптимального. Да и «временных» решений достаточно, чтобы хабраюзеры закидали камнями.
требования по скилам?
Был поваром в кафе. Потом работал программистом в университете. Через пол года работы там жизнь меня перекинула в текущую фирму. Пришел на собеседование. Вакансия была на php-программиста. Взяли, потом, на следующий день, сказали что буду тестировщиком. Через неделю-другую у меня от этого крыша поехала (ручное тестирование… при том, что я совсем не хотел этим заниматься). Предложил руководству автоматизировать. Мне встречно дали запрос «подготовить смету по этому делу» (как по деньгам/времени, так и по технологиям). Оказалось, что писать придется под java, которую я первый раз в жизни увидел. Сказал, что «смогу». Дали «добро». Через год АСТ v1 заработала.
Сказал, что «смогу». Дали «добро». Через год АСТ v1 заработала.
Сказал и сделал — вероятно это и есть самый главный скилл в любом деле. Спасибо, записал себе в ноут.
Да и «временных» решений достаточно, чтобы хабраюзеры закидали камнями.
Уверен, у вас получится. По-крайней мере, стоит попробовать.
Важными элементами называю элементы, с которыми может взаимодействовать юзер (в т.ч. виртуальный) — это кнопки, чекбоксы, текстбоксы и т.п. Уникальные id им может задавать разработчик, а может и платформа, насколько я знаю (я не вебдев). Уникальность нужна в пределах одной страницы/окна. И гарантироваться должна разработчиком.
1. Выявить проблемы
2. Определить возможные решения
3. Выбрать из возможных решений целесообразные
4. Воплотить!
P.S. Понимаю что мой ответ вас не устроит ;)
P.S. Понимаю что мой ответ вас не устроит ;)
Дело не во мне. В статье затронута действительно актуальная тема, с которой, в той или иной степени, сталкиваются все компании-разработчики ПО. Я стараюсь задавать «уточняющие» и «наводящие» вопросы, которые позволят лучше раскрыть тему. Судя по статье — у вас есть успешный опыт атоматического тестирования.
Например, в компании, где я работаю, схема примерно такая: после этапа первичной разработки (разработка обычно ведётся на основании требований) составляется ПМИ, которое передаётся тестировщикам (их несколько человек и у них нет навыков разработки, но им приходится иметь дело с прикладной областью). Тестировщики пишут баг-репорты, которые исправляются. И так до устранения всех проблем. В общем-то ничего нового.
Обеспечивая качественное покрытие кода приложения тестами мы одновременно замедляем разработку как таковую. И замедляем не на 10%, а вдвое, втрое или даже больше.
Переход на автоматическое тестирование у нас тормознул, в том числе, и по этой причине.
И дело не только во времени. Нужны ещё дополнительные ресурсы (разработчики со спец. навыками) для разработки тестов. Но тесты покрывают далеко не все задачи тестирования. В итоге, стоимость и сроки разработки растут, а без ручного тестирования всё-равно не обойтись.
Но тесты покрывают далеко не все задачи тестирования
Согласен. Однако качественная платформа может дать очень жирный кусок. У нас примерно 80% функциональных тест-кейсов покрыто.
При этом создание/редактирование/удаление данных в основном нашем продукте (да, это CMS|CRM) покрыты на ~95-98%.
Тесты понимают работу с почтой, парсинг писем. Умеют в drag&drop. Читать консоль браузера и собирать js-ошибки из нее, записывая в лог.
а без ручного тестирования всё-равно не обойтись
Увы да, в одну каску тянуть разработку особо-изощренных тест-кейсов как лениво, так и сил нету. Поэтому что-то руками проверяется даже если это можно (и по хорошему нужно) автоматизировать.
Судя по статье — у вас есть успешный опыт атоматического тестирования.
Неудачный опыт тоже есть :)
Если серьезно, легко дать совет вида «пишите Unit-тесты!». К сожалению вам это вряд ли поможет если не навредит.
Говорить о каком то решении со стороны, не понимая специфики вашей работы, ваших ограничений, в ваших трудностей было бы неосмотрительно.
Вы говорите о ряде проблем:
1. Разработка тестов отнимает время — можете ли вы сократить накладные расходы при этом сохранив пользу от тестов?
2. Нужны разработчики со спец навыками — зачем они нужны? можете ли вы обучить имеющихся разработчиков? можете ли вы нанять необходимых разработчиков?
3. Тесты покрывают не все задачи — какие покрывают а какие нет? есть ли смысл связываться с тестированием ради проверки тех задач которые можно ими проверить? можно ли расширить область действия тестов?
Попробуйте задать себе вопросы в этом роде и подумайте как можно на них ответить.
Лучшее решение ваших проблем можете найти только вы сами.
Нагрузка проверяется JMeter'ом (помимо него инструментов достаточно, тот же питоновый Locust например).
А больше всего мне интересно, как вы будете нагрузку в разрезе огромного количества юзеров тестировать руками.
PS А вы всерьёз думали, что эти несчастные долбят как мартышки по клавишам?
Ну да, нагрузку можно по-разному моделировать, по сценариям – тоже можно. А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю. Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).
А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю.
Если вы имеете в виду — смоделировать нагрузочный тест как примитивную DDOS-атаку, то да — это будет делать скрипт.
Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).
Поведенческие тесты нужны тогда, когда надо выявить, например, скрытую/плавающую ошибку. Разработать, провести такой тест и получить положительный результат (выявить причину проблемы) — большая работа. В каждом конкретном случае такие тесты уникальны.
Кстати, сейчас востребованы услуги по тестированию ПО, которые предоставляются по схеме аутсоурсинга. Мне известна одна такая фирма. В штате у неё несколько десятков тестировщиков (с разными проф. навыками). У неё всегда есть заказы, а услуги далеко не всем по-карману.
Мне всегда казалось, что тестирование отдельно от разработки не продать.
Отлично продаётся. Главные потребители — банки и корпорации. У них сейчас сенокосная пора на мобильную разработку. А свой штат тестировщиков держать на окладе — зачем? Тестировщики востребованы только по мере появления нового ПО (и собственной и сторонней разработки).
Отдельно сидящие тестировщики – это архаизм :)
Качественное тестирование может обеспечить только внешняя, неаффелированная команда (это из области психологии — почему так, учёные пока объяснить не могут).
Тестировать надо (в солидных компаниях, которые привыкли заботиться о своей репутации) не только собственные разработки, но и любые ПО-продукты, которые там внедряют.
Тестировщики, о которых вы говорите — входят в обязательный штат современной компании-разработчика ПО.
Внешнее тестировщики нужны, когда компания не хочет, чтобы её 100500 клиентов выступили в качестве тестировщиков.
Для внешнего тестирования отлично подходит аутсоурсинговая компания.
Дать задачу автоматизатору написать простой нагрузочный скрипт конечно можно и большинство с задачей, я думаю, справятся.
Вот только правильно интерпретировать NFE(Non-Functional requirements) заказчика, с учетом контекста разрабатываемого решения(читай вникнуть в архитектуру, разобраться, вычислить потенциальные bottle-neck`и) может только опытный и квалифицированный человек.
Кроме того в нагрузочном тестировании существует своя специфика подходов, методологий и т.д.
И для полноценного нагрузочного тестирования, нужен человек, который понимает эту специфику и желательно имеет опыт работы с ней.
Мне казалось очевидным, что различные виды тестирования имеют свой набор специалистов.
Правда стоит отметить что это утверждение распостраняется не на все виды тестирования.
Аутентичность — большинство приложений мы пишем для людей, и именно поэтому люди лучше всего подходят для их тестирования.
Не согласен. Мало того что очень много приложений являются приложениями для приложений, так ещё и даже если приложение для людей, то они все равно не очень подходят для тестирования, например, API.
Гибкость — ручное тестирование можно проводить гораздо разнообразнее, и изменение способа тестирования практически ничего не стоит. Давайте протестируем в Safari — пожалуйста, на Chromebook — нет проблем, IE6 — придется запустить виртуальную машину, но тоже можно.
То же самое! У автора приложения состоят из UI-only?
Выразительность — мало найти проблему на уровне “ничего не работает!”, важно правильно объяснить, в чем она заключается и уметь ответить на дополнительные вопросы разработчика. И в этом люди также лучше автоматических тестов.
Опять таки, не всегда. Вот не работает API метод с такими-то параметрами. И человек и автотест предоставят только параметры и стектрейс, все.
Ограничивают рефакторинг. Тесты тоже нужно рефакторить, даже если бизнес-логика не меняется, и в коде происходят лишь косметические изменения. Это может привести к тому что нужно поправить 5 мест в основном коде и еще 80 в тестах. Каждый в такой ситуации задумается: а стоит ли делать что-то большее, чем переименование метода.
Тащем-то наоборот. Когда у тебя не мелкий проект, то рефакторинг без тестов — самоубийство. Обычно оставляют как есть и потом переписывают проект полностью. О том чтобы зарефакторить какой-нибудь core сервис и речи быть не может. С тестами все куда лучше.
Сизифов труд
тут вообще бред, если ты рефакторишь код, тебе не надо рефакторить много тестов by definition
Количество тестов обманчиво
1000 ситуаций это уже уделывает людей подчистую
В общем, какое-то мнение UI тестировщика.
Ведущий оператор баш консоли 1 разряда
А, ну или так, да.
в конце концов чтоб если тестер тестит руками может заодно и тест написать, если тестер как девелопер не очень то можно дать ревью тестов делать девелоперам
Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю — 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.это вообще смешно, измерять можно покрытие логики тестами, а не сколько времени что-то тестировали
без тестов любое изменение чревато проблемами
с тестами любое изменение становятся проблемой. И тесты не бесплатны
если изменение требует переписать кучу тестов, наверно это огромное изменение либо тесты как-то очень не эффективно написаны и это не вина тестов
тестирование это исключительно прикладная область.
На эту тему есть отличная книга Perfect Software от Gerald M. Weinberg.
В реальности же конечные требования известны только в космосе, медицине и военке. В остальных областях потребуется несколько раз всё переделать, прежде чем станут известны конечные требования и будут видны очертания результата.
И тесты очень сильно замедляют и удорожают эти изменения. Вместо быстрого прототипа люди пытаются делать решение на века со 100% покрытием. Даже если этого никому не нужно.
'Исправляя проблемы быстро, можно добиться гораздо более высокого качества продукта, '
Добились времени решение любой проблемы — менее одного бизнес дня.
Качество продукта было космическим.
Тестов в классическом понимании не было совсем. Были так называемые мониторинг тесты.
Любая функциональность пушит метрики в систему анализа. +Устанавливается система алертинга
(Что то не происходило в течении часа -> приводит к вызову программиста который на дежурстве)
+На продакшене постоянно крутились скрипты которые кликали сайт в браузере через web driver и тоже пушили метрики (Поэтому все им доверяли ибо если один пробег скрипта не прошел это не приводило к alerts. И качество их могло быть вполне себе 'на скорую руку')
Все это(метрики) также использовались дизайнерами чтобы понимать какой UX оптимизировать.
(Мы видим 1000 событий заполнил поле email но только 10 заполнил поле lastName -> давайте удалим этот lastName к чертям, людям все равно не нравится)
Обращение к customer support тоже было метрикой, так что если вдруг полетели заявки больше обычного — вот тебе и alert и программист сидит разбирается что почему.
Все это реально работало, при этом не требовало 100% покрытия, идеальных тестов и.т.п.
Просто за место: «О а давайте покроем все возможные сценарии тестами и потратим кучу времени на это.»
Было: «Так этот кусок программы должен приводить к рассылки инвайтов. Давайте пушить когда пользователь кликнул на кнопку и запишем если API ответит с ошибкой.»
Уходило на это час. И уверенность в качестве было.
То, о чём вы говорите — это уверенность в возможности быстро локализовать проблему.
Проблема «мониторинговых» тестов в том, что они алертят постфактум. Т.е. вы узнаете о проблеме только тогда, когда N пользователей вместо ожидаемого результата получат хрен.
Более того, в случае новой функциональности и всяких изощренных юсабилити экспериментов всё ещё сложнее — вы не всегда можете понять, то ли UX эксперимент не удался и конверсия просела, то ли пользователь не видит кнопку сабмита формы (условно) и уходит нахрен.
Пока вы это выясняете — пользователи испытывают баттхёрт. И вы их теряете (при условии, конечно, что у них есть альтернатива, но если её нет — можно и вообще не париться, и так схавают).
И того один человек написал тест и сэкономил время нескольким коллегам. :)
Стойте-стойте. А как же качество продукта? Или у вас производительность программиста исчисляется не в числе решенный задач, а в строках кода, которые он написал?
Задача программиста не писать код, а решать поставленные задачи с помощью написания кода. Как программист должен узнать, что задача решена и решена корректно, если у него нет инструмента проверки валидности логики?
Код, который запускается это далеко не тот же самый код, который работает корректно. Даже если вы пишете на Haskell и Scala.
Все заранее известно и разработка сводится к программированию лишь на уроках информатики. На практике приходится иметь дело с большим разнообразием функциональных и не функциональных требований, кроме валидности логики, прежде чем сдавать работу.
И потом, не стоит сбрасывать со счетов банальный человеческий фактор. Два глаза хорошо, а четыре еще лучше. :)
Всеобъемлемость — автоматические тесты позволяют покрыть огромное количество сценариев и находить наведенные ошибки в таких далеких углах приложения, до которых ручной тестировщик никогда бы не добрался, кроме как случайно.
и это преимущество ручного
Креативность — ручное тестирование позволяет найти проблемы, которые заранее не были известны, более того, даже не подразумевались.
одно и то же.
Статья поначалу затянула, а в конце удивила.
Возникло ощущение, что все в кашу. Обычно регрессионное тестирование и ручное происходят из единого описания сценариев тестирования. Тут нельзя спутать, какой сценарий не прошел. Если подходить системно, то картинка вся должна быть на виду. Автотест не прошел? Повторяем сценарий руками. По контексту ошибки и ручного прогона поймем что делать дальше.
А если как-то появилась толпа автотестов и они с ручным тестированием непонятно как пересекаются, то пора задуматься об управлении тестированием как процессе.
Как такое возможно? QA написавший тест всегда знает о чем он, если он уже покинул команду — есть description
Вы подразумеваете что тесты достаточно хорошо документированы и структурированы — в реальности это не всегда так.
Если у вас тестировщик без комментариев реджектит тикет потому что «упал какой-то тест
По хорошему, задача не должна доходить до ручного тестирования если есть упавшие тесты.
Это элемент культуры разработки, проявление разработчиком уважения к труду ручного тестировщка.
Зачем было создавать 20 тысяч?
Хороший вопрос! Но, мне кажется, не все задают его себе прежде чем написать 20 тысяч тестов :)
нужно поправить 5 мест в основном коде и еще 80 в тестах
То для того, чтобы такого не было, нужно дробить огромные методы с убер-логикой на маленькие логически оформленные блоки (методы). Тогда каждый блок кода можно протестировать отдельно, и изменение одной строчки в убер-методе не приведет к необходимости переписывать 80 тестов.
Что делать? Если ваш большой метод разбит на части, и все они покрыты 20-ю тестами изначально, то каждая правка принесет по +3 теста на конкретный отдельный блок. Т.е. 20+3+3 = 26 тестов. Есть разница — 26 тестов или 210? Грубые подсчеты, конечно, но отражают действительность. Сложность поддержки тестов на отдельный метод растет в экспоненциальной прогрессии от кол-ва строк в нем.
Количество кода от этого возрастет. Сложность тоже.
И в чем смысл писать тест на if? Проверять что глаза меня не обманывают? Что компилятор не сломался?
+5
— Серебрянной пули нет
— Надо использовать инструменты там, где это разумно
— Надо правильно расставлять приоритеты
Автотесты нужны, в частности, при обнаружении эффекта накопления-тепла, зарядов,- что почти невозможно
обнаружить вручную,
особенно в процессорах графической, спектральной и т.д. обработки
И тут же, в ту же кучу — тесты до кода, правка тестов самими разработчиками, упоминания юнит тестов, «Тесты — такой же код» — т.е. явно не автоматизация работы QA, а именно юнит-тесты. Ну или в крайнем случае интеграционные. Юнит тесты призваны экономить время разработчиков. QA вообще не должно быть никакого дела до наличия или отсутствия юнит-тестов. Фраза «вернуть задачу к разработчикам при красном юнит тесте» — не имеет смысла — билд просто не должнен доходить до QA при красных юнит/интеграционных тестах.
Юнит-тесты — не альтернатива ручному тестированию. И, тем более, не аналог и не замена автоматизированному тестированию UI, вроде selenium. Это просто другой вид тестирования. А вы вписали в общий список все достоинства и все недостатки разных видов тестирования, даже тех, которые вообще в зону ответственности QA не входит. И перемешали. Не хватает только пунктов «selenium не умеет самостоятельно проводить penetration test-ы» и «юнит-тестами тяжело протестировать документацию» :)
С таким же успехом можно было расписать достоинства и недостатки JavaScript, достоинства .NET/Java, lua-скриптов, powershell, SQL, а потом перемешать это в один список «Блеск и нищета написания кода».
Т.е. вроде как была идея написать интересный противоречивый пост с интригой и открытой концовкой. Но выглядит так, как будто статью писал не лидер backend разработки, а маркетолог, которому выдали брошюру «разные виды тестирования для чайников» :(
То что отдельная проверка реализована по принципам unit тестирования, а не как selenium тест,
совершенно не значит что такой тест будет не понятен и бесполезен QA. Может быть этот то что нужно.
Польза от теста ручному тестированию определяется не технологией использованной при
написании конкретного теста, а его осмысленностью и выразительностью.
Точно также, любой тест на любой технологии может быть написал плохо и создавать больше проблем чем приносить пользы.
Тесты это тесты.
билд просто не должнен доходить до QA при красных юнит/интеграционных тестах.
Конечно! Жалко не все так делают :)
Но вот ваша статья не только делит полезность тестов для разработчиков по технологическому признаку. Вы прямо противопоставляете принципиально разные виды тестирования, и выдаете из этого целую статью.
По сравнению с ручным тестированием, автоматизированное имеет как достоинства так и явные недостатки
Точно так же можно написать статью о том, что «SQL по сравнению с JavaScript имеет как достоинства, так и явные недостатки», с кучей очень обоснованных доводов в пользу как SQL, так и JS.
QA вообще не должно быть никакого дела до наличия или отсутствия юнит-тестов.
Вот это вот очень интересно :) А разработчик сам придумает все покрытие? Уметь писать код != уметь тестировать, а тестировать свое же еще сложнее. В идеале QA накидает кейсов, разработчик напишет юниты, QA их отревьюит/дополнит, и только после этого можно считать что ваш кусок тестами закрыт.
«SomeService при вызове SaveSomething, при условии что зависимость ISomeRepo вернет минимум 5 строк, в вызове GetSomeItems() заполнит поле SomeField у сохраняемого объекта значением SomeValue» — вот что проверяет юнит тест. Это просто проверка на наличие какого-то условия или какого-то вызова в коде.
QA обычно ничего не знаю о классах и об отдельных методах. Поэтому QA не может полноценно ревьювить и дополнять юнит-тесты. И дело не только в знании конкретного ЯП или фреймворка. Дело в том, что количество юнит тестов должно соответствовать количеству проверок и прочих методов принятия решений в коде. Собственно, в этом и состоит работа разработчика — переложить требования с человеческого (в виде User Story, документации, чего угодно) на язык if-ов и while-ов.
Современные языки программирования хорошо приспособлены для описания бизнес-логики. Они позволяют делать это гораздо компактнее русского или английского языков. Поэтому полноценное описание функционала (спецификация), если она действительно описывает весь функционал, должна несколько раз превышать по объему код приложения. А т.к. нет способов поддерживать и рефакторить текст спецификации с той же легкостью, что и код приложения — то написание такой «полноценной» спецификации должно занимать намного больше времени, чем написание кода. Именно поэтому все спецификации обычно далеки от полноты, и попытки «сгенерировать код по спеке» обречены на провал.
То же самое с тесткейсами для юнит-тестов. Их должно быть столько же, сколько проверок. Более того, написание кейсов для юнит-тестов QA, заранее, подразумевает что QA настолько хорошо представляет себе структуру приложения, что может точно сказать в каком методе, где именно и как именно будет написан каждый if. Если у вас QA так круты — то разработчики вам не нужны. Ну и объем таких тексткейсов будет точно так же превышать объем кода.
Поэтому да, для юнит-тестов разработчик сам придумывает покрытие. Точно так же, как он сам придумывает, где к коде написать if. И проверяют юнит-тесты именно наличие if-а или наличие вызова. Загораясь красным, когда кто-то лажанет при мерже, или неудачно подрефакторит. Или просто случайно выкосит проверку.
Те тесты, которые (иногда) пишутся по кейсам (или могут быть представлены в виде кейсов), по принципу один кейс — один тест — это или интеграционные или функциональные тесты. Т.е. это или selenium и прочие тыкалки интерфейса, тесты на всю систему в сборе (включая базу), или тесты «на бэкенд в сборе + базу».
Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю — 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.
это вообще смешно, измерять можно покрытие логики тестами, а не сколько времени что-то тестировали
принцип Паретто никто не отменял еще. (потратив всего 20% времени на тестирование мы находим — 80% дефектов, и нужно потратить еще 80% времени чтобы найти оставшиеся 20% дефектов).
в принципе это аргумент в пользу ручного тестировария.
но в контексте итеративной модели разработки, когда релизится нужно каждые две недели — а время на регрессию — постоянно растет — трудно обойтись без автотестов (в противном случае тайм ту аркет увеличивается).
Если у вас стартап, где важны быстрота выхода первой бетты или продукт типа сделал раз и забыл — то нет смысла тратить время.
Если у вас стартап, который требует динамичного развития, вы уверены, что у вас есть ресурсы гонять 5 часовую регрессию руками?
Если у вас стартап, который активно набирает обороты, уверены ли вы, что стоит жертвовать качеством ради ускорения релизов на 10-15% времени? (И, что важнее, так ли в этом уверены ваши пользователи?)
Во всём нужен баланс.
Что думают хабровчане? :)
Блеск и нищета автоматизации тестирования