Comments 96
Можно короче и универсальнее, как мне кажется:
— Серебрянной пули нет
— Надо использовать инструменты там, где это разумно
— Надо правильно расставлять приоритеты
— Серебрянной пули нет
— Надо использовать инструменты там, где это разумно
— Надо правильно расставлять приоритеты
Можно, но ваш коммент не убедит партнеров/руководство в принятии решения ЗА или ПРОТИВ автоматизированного решения. А эта статья убедит. Добавил в избранное.
Мне кажется вам не повезло с партнерами/руководством, если набор очевидных истин явяется аргументом для принятия решения. В каждом случае надо анализировать что вам надо и готовы ли вы за это заплатить требуемую цену. От прочтения данной статьи очень мало у кого прояснится в мозгу, имхо.Не в обиду автору, я понимаю что написание статьи это труд, за который спасибо. "Человек быстрее реагирует на изменяющиеся параметры, а автомат тестирует не уставая". [irony]Ну так-то — да.[/irony]
Если подходить формально, то в статье, по большей части, всё верно. Но есть нюансы, которые очень значительно влияют на общее впечатление и финальные выводы.
Автоматические тесты надо уметь писать. Если тестировать немного не то и не так, то они, действительно, будут "хрупкими" (часто ломаться), на их разработку/поддержку будет уходить намного больше времени, польза от них будет сомнительна, и (с точки зрения менеджмента) затраты на их разработку действительно не будут окупаться. Но ровно то же самое касается и разработки кода: если нанять слабых разработчиков, которые пишут не тот код и не так, как надо — вместо фич будут только баги, разработка может занимать в разы больше времени, и затраты на неё не будут окупаться.
Без юнит-тестов мы запускаем в продакшн очень много кода, который никто никогда не запускал. Программист его "скомпилировал в голове" когда писал, но при ручном тестировании большая часть веток if-ов (и даже целых функций) ни разу не выполнялась. Особенно это касается кода обработки разных ошибок (сеть, БД, данные в некорректном формате, etc.). А, как известно из опыта, если код ни разу не запускали — как правило он корректно работать не будет.
Преимущества автоматических тестов
Не упомянута ещё несколько очень важных преимуществ.
Наличие автоматизированных тестов очень сильно ускоряет добавление новых фич и рефакторинг — вместо того, чтобы тратить время на попытку продумать и оценить последствия изменения кода можно его просто изменить и запустить тесты, если они проходят, то с высокой вероятностью эти изменения ничего не поломали (при наличии адекватных тестов, которые ещё нужно уметь писать, разумеется).
Автоматизированные тесты очень сильно упрощают тестирование в разных окружениях — с разными версиями OS, библиотек, кросс-платформенное тестирование.
Причина в том, что проверить изменение руками гораздо быстрее, чем автоматизировать тот же тест.
Очевидно, если это изменение руками тестируется уже в 3-5-й раз, то к этому моменту написать автоматизированный тест было бы быстрее.
В каждый отдельный момент, решая что выгоднее, писать тесты или не писать, второе всегда предпочтительнее.
Это не так, из-за упущенного Вами и упомянутого мной выше преимущества автотестов — их наличие сильно ускоряет внесение (качественных и работающих, наверное стоит добавить) изменений в код.
Ситуация в корне меняется в длительной перспективе.
Проблема в том, что если не писать тесты с самого начала, то начать их писать на более поздних этапах будет намного сложнее и дороже. Одна из причин этого чисто техническая — для того, чтобы тесты было возможно написать нужно чтобы код приложения был специально адаптирован под тестирование, что означает необходимость дополнительного рефакторинга кода (а иногда и архитектуры) если код изначально не писался с учётом необходимости его тестировать (а ещё давно замечено, что архитектура и код заметно улучшаются когда пишутся с учётом тестирования, и это ещё одна причина почему тесты стоит писать с самого начала). Другая причина чисто психологическая — тесты писать значительно менее приятно, чем основной код, поэтому когда возникает задача "у нас есть 100500 строк кода без тестов, надо покрыть их тестами" — руки просто опускаются, плюс всегда и у разработчиков и у менеджмента возникает вредная и некорректная мыслишка "до сих пор ведь всё работало без тестов, значит они особо и не нужны". Всё это сильно убивает и мотивацию, и продуктивность.
В результате экономить на написании тестов имеет смысл только если пишется какой-то реально одноразовый код, который никто и никогда не будет запускать в продакшне.
И замедляем не на 10%, а вдвое, втрое или даже больше.
Если тестировать то, что нужно, и так, как нужно — на тесты уходит примерно столько же времени, сколько и на код. Т.е. формально разработка замедляется вдвое, но это не учитывает вышеупомянутый фактор ускорения разработки благодаря наличию автотестов, а он начинает заметно сказываться на более поздних этапах, когда из-за увеличения общей сложности приложения скорость внесения изменений при отсутствии автотестов очень сильно падает. Если же на автотесты в среднем тратится вдвое больше времени чем на код — это хороший признак того, что скорее всего вы что-то не то или не так тестируете.
Но не все так просто.
Половина описанных в выводах статьи проблем связана скорее с неумением писать тесты, нежели объективными проблемами.
это жисть, а у вас идеальный мир, которого не существует.
Каждый сам выбирает мир, в котором ему жить.
Безусловно, существует много проектов, в которых автотесты никто не пишет. И коммерческий успех или провал проекта вряд ли зависит от наличия или отсутствия автотестов — по крайней мере я такой зависимости пока не замечал. Так что я не пытаюсь сказать, что автотесты это серебрянная пуля и мастхэв, и без них никуда — если вдруг Вы поняли мой комментарий в этом ключе.
Я писал про то, что разработка автотестов — это отдельный навык, которому нужно отдельно учиться, как учат новые языки, фреймворки и парадигмы программирования (причём это в равной степени касается и крутых гуру/стар-разработчиков и всех остальных). И что большая часть проблем, с которыми сталкиваются при написании автотестов, вызвана не автотестами как таковыми, а неумением их писать (что включает и умение адаптировать архитектуру и код проекта под нужды тестирования).
Если у вас разработчики такие, что пишут только баги, где гарантии, что они напишут тесты, которые хоть что-то тестят? При должном усердии можно и 100% покрытие тестами показать, без единого осмысленного assert.
>>начинает заметно сказываться на более поздних этапах, когда из-за увеличения общей сложности приложения скорость внесения изменений при отсутствии автотестов очень сильно падает.
В то же время очень сильно увеличивается время на переписывание существующих автотестов
В то же время очень сильно увеличивается время на переписывание существующих автотестов
Спасибо за развернутый комментарий,
тонкость в том что неумение писать тесты это тоже объективная проблема.
тонкость в том что неумение писать тесты это тоже объективная проблема.
Стоит еще добавить пункты, описывающие для кого делаются эти тесты. Почему делаются тесты для разработчиков и почему тесты реализовываются для конечного продукта. Про бенчмарки как исторический этап и тд. для полного раскрытия темы… ну на 90% )
Разработчики делятся на 2 категории: которые не пишут тесты и которые уже пишут тесты.
Точность — автоматические тесты проверяют ровно то, что описано в сценарии, во всех деталях и мелочах. Они не отвлекаются, не путают и не забывают.
Если бы ещё и сценарии писались бы точно, во всех деталях и мелочах, неутомимой машиной.
Вам надо протестировать формы в системе (Win-GUI, Web-GUI — не важно).
Проверить:
— штатную функциональность (типовое НСИ);
— защиту от дурака (не ту кнопку нажали);
— нагрузку (по данным и/или по юзерам);
Таких форм много (в корпоративных системах десятки и сотни).
Ваши конкретные предложения по автоматическому тестированию?
Проверить:
— штатную функциональность (типовое НСИ);
— защиту от дурака (не ту кнопку нажали);
— нагрузку (по данным и/или по юзерам);
Таких форм много (в корпоративных системах десятки и сотни).
Ваши конкретные предложения по автоматическому тестированию?
Не «НСИ», а «ПМИ» (сорри).
Нагрузку проверяет нагрузочное тестирование, оно ни к авто, ни к ручному особого отношения не имеет.
Штатное поведение как раз проще всего автоматизировать, особенно если UI не особо часто меняется. Тут важна стандартизация разработки — например, у каждого важного элемента должен быть уникальный, не меняющийся id. При таком раскладе можно написать один раз пачку тестов на селениуме (или CodedUITests в случае Win) и жить спокойно. А защита от дурака это уже негативные кейсы, их так же можно автоматизировать, как и штатное поведение, но уже с более низким приоритетом.
Штатное поведение как раз проще всего автоматизировать, особенно если UI не особо часто меняется. Тут важна стандартизация разработки — например, у каждого важного элемента должен быть уникальный, не меняющийся id. При таком раскладе можно написать один раз пачку тестов на селениуме (или CodedUITests в случае Win) и жить спокойно. А защита от дурака это уже негативные кейсы, их так же можно автоматизировать, как и штатное поведение, но уже с более низким приоритетом.
Нагрузку проверяет нагрузочное тестирование, оно ни к авто, ни к ручному особого отношения не имеет.
Вы меня заинтриговали (извините за сарказм), как же оно выполняется (или кем)? В вашем контексте «нагрузочное тестирование» это субъект, программа, технология или что?
у каждого важного элемента должен быть уникальный, не меняющийся id
О каком «важном элементе» идёт речь в данном контексте, кто и на каком этапе задаёт id, как гарантируется уникальность?
При таком раскладе можно написать один раз пачку тестов на селениуме
Тесты на селениуме? Очень интересно. А конкретный пример теста можно? Что-нибудь простое, например типа регистрации нового пользователя.
Тесты на селениуме? Очень интересно. А конкретный пример теста можно? Что-нибудь простое, например типа регистрации нового пользователя.
Пример
P.S. Как раз разработчик АСТ.
Спасибо.
А как быть в случае, если баг проявляется в процессе взаимодействия пользователя с формой.
Например — пользователь с таким именем уже зарегистрирован в системе.
Или — пароль не прошёл валидацию на сложность.
Или просто произошла ошибка при сохранении данных.
Сможет ли автоматический тест решать такие задачи?
А как быть в случае, если баг проявляется в процессе взаимодействия пользователя с формой.
Например — пользователь с таким именем уже зарегистрирован в системе.
Или — пароль не прошёл валидацию на сложность.
Или просто произошла ошибка при сохранении данных.
Сможет ли автоматический тест решать такие задачи?
Если такой автоматический тест был спроектирован, то имплементировать такой тест не сложнее чем любой другой(автотест). Этот вопрос скорее о квалификации тестировщика составлявшего список тест-кейсов.
Ок, понимаю, что мой код вам не понятен.
Пояснения: это не просто «селениум» и «тесты». Это полноценная АСТ (автоматизированная система тестирования). Она сложная и модульная (Микроядра->ядро->модули->тесты).
На скриншоте пример как раз модуля. Тест делает вызовы модулей. Модули делают обращения к подсистемам ядра. И вот уже в методах ядра идет вся «магия».
Если поле ввода не сработало по какой либо причине, то это будет зарегистрировано и занесено в лог.
Если пароль не прошел валидацию на сложность или данные внесены как-либо иначе не верно, то уже смотрим логику модуля, что отвечает за к примеру систему регистрации юзера на сайте — если это не допустимо, то тест рассчитывает на «не сохраняемость» этого юзера. И, в случае отказа, пишет что тест прошел верно. Если же юзер будет сохранен вопреки всему, то будет в отчетах указание соответствующей ошибки.
В довесок: если есть не критичные баги, то тест не будет завален, а АСТ будет пытаться продолжить выполнение проверок дальше (пример: нужно сделать проверку товара в каталоге… дата не сохранилась. На дальнейшие тесты влияет минимально — тестирование будет продолжено по веткам сценариев без аварийного завершения прогона).
Поэтому, подводя итоги — мы (качественные автоматизаторы) можем очень многое.
Пояснения: это не просто «селениум» и «тесты». Это полноценная АСТ (автоматизированная система тестирования). Она сложная и модульная (Микроядра->ядро->модули->тесты).
На скриншоте пример как раз модуля. Тест делает вызовы модулей. Модули делают обращения к подсистемам ядра. И вот уже в методах ядра идет вся «магия».
Если поле ввода не сработало по какой либо причине, то это будет зарегистрировано и занесено в лог.
Если пароль не прошел валидацию на сложность или данные внесены как-либо иначе не верно, то уже смотрим логику модуля, что отвечает за к примеру систему регистрации юзера на сайте — если это не допустимо, то тест рассчитывает на «не сохраняемость» этого юзера. И, в случае отказа, пишет что тест прошел верно. Если же юзер будет сохранен вопреки всему, то будет в отчетах указание соответствующей ошибки.
В довесок: если есть не критичные баги, то тест не будет завален, а АСТ будет пытаться продолжить выполнение проверок дальше (пример: нужно сделать проверку товара в каталоге… дата не сохранилась. На дальнейшие тесты влияет минимально — тестирование будет продолжено по веткам сценариев без аварийного завершения прогона).
Поэтому, подводя итоги — мы (качественные автоматизаторы) можем очень многое.
мы (качественные автоматизаторы) можем очень многое
Статью с таким названием я бы хотел прочитать.
А как быть, если просто нужен «качественный автоматизатор» тестов — какие к нему должны быть требования по скилам?
Статью с таким названием я бы хотел прочитать.
Уже 2 года как хочу ее написать. Однако есть два тормоза (время на это я нашел бы любой ценой как говорится):
Важный — разработка обошлась в серьезную сумму, много нервов и времени. Это закрытая информация.
Не важный — по-любому нахватаюсь кучу негатива в свой адрес, т.к. ПО явно не в мейнстримовом духе. Много не оптимального. Да и «временных» решений достаточно, чтобы хабраюзеры закидали камнями.
требования по скилам?
Был поваром в кафе. Потом работал программистом в университете. Через пол года работы там жизнь меня перекинула в текущую фирму. Пришел на собеседование. Вакансия была на php-программиста. Взяли, потом, на следующий день, сказали что буду тестировщиком. Через неделю-другую у меня от этого крыша поехала (ручное тестирование… при том, что я совсем не хотел этим заниматься). Предложил руководству автоматизировать. Мне встречно дали запрос «подготовить смету по этому делу» (как по деньгам/времени, так и по технологиям). Оказалось, что писать придется под java, которую я первый раз в жизни увидел. Сказал, что «смогу». Дали «добро». Через год АСТ v1 заработала.
Таки да, нагрузочное тестирование это отдельная ветвь тестирования, выполняется специальными программами типа JMeter. Пишется сценарий нагрузки или скармливаются логи реального сервера, запускается и начинается плавное увеличение нагрузки. Параллельно отслеживаются параметры нагружаемого приложения (загрузка цп, очередь к базе, время отклика итп). Обнаруживаются бутылочные горлышки и допиливаются, пока не будет достигнута стабильная работа тестируемого приложения при максимальной требуемой по ТЗ нагрузке.
Важными элементами называю элементы, с которыми может взаимодействовать юзер (в т.ч. виртуальный) — это кнопки, чекбоксы, текстбоксы и т.п. Уникальные id им может задавать разработчик, а может и платформа, насколько я знаю (я не вебдев). Уникальность нужна в пределах одной страницы/окна. И гарантироваться должна разработчиком.
Важными элементами называю элементы, с которыми может взаимодействовать юзер (в т.ч. виртуальный) — это кнопки, чекбоксы, текстбоксы и т.п. Уникальные id им может задавать разработчик, а может и платформа, насколько я знаю (я не вебдев). Уникальность нужна в пределах одной страницы/окна. И гарантироваться должна разработчиком.
Предложения:
1. Выявить проблемы
2. Определить возможные решения
3. Выбрать из возможных решений целесообразные
4. Воплотить!
P.S. Понимаю что мой ответ вас не устроит ;)
1. Выявить проблемы
2. Определить возможные решения
3. Выбрать из возможных решений целесообразные
4. Воплотить!
P.S. Понимаю что мой ответ вас не устроит ;)
P.S. Понимаю что мой ответ вас не устроит ;)
Дело не во мне. В статье затронута действительно актуальная тема, с которой, в той или иной степени, сталкиваются все компании-разработчики ПО. Я стараюсь задавать «уточняющие» и «наводящие» вопросы, которые позволят лучше раскрыть тему. Судя по статье — у вас есть успешный опыт атоматического тестирования.
Например, в компании, где я работаю, схема примерно такая: после этапа первичной разработки (разработка обычно ведётся на основании требований) составляется ПМИ, которое передаётся тестировщикам (их несколько человек и у них нет навыков разработки, но им приходится иметь дело с прикладной областью). Тестировщики пишут баг-репорты, которые исправляются. И так до устранения всех проблем. В общем-то ничего нового.
Обеспечивая качественное покрытие кода приложения тестами мы одновременно замедляем разработку как таковую. И замедляем не на 10%, а вдвое, втрое или даже больше.
Переход на автоматическое тестирование у нас тормознул, в том числе, и по этой причине.
И дело не только во времени. Нужны ещё дополнительные ресурсы (разработчики со спец. навыками) для разработки тестов. Но тесты покрывают далеко не все задачи тестирования. В итоге, стоимость и сроки разработки растут, а без ручного тестирования всё-равно не обойтись.
Но тесты покрывают далеко не все задачи тестирования
Согласен. Однако качественная платформа может дать очень жирный кусок. У нас примерно 80% функциональных тест-кейсов покрыто.
При этом создание/редактирование/удаление данных в основном нашем продукте (да, это CMS|CRM) покрыты на ~95-98%.
Тесты понимают работу с почтой, парсинг писем. Умеют в drag&drop. Читать консоль браузера и собирать js-ошибки из нее, записывая в лог.
а без ручного тестирования всё-равно не обойтись
Увы да, в одну каску тянуть разработку особо-изощренных тест-кейсов как лениво, так и сил нету. Поэтому что-то руками проверяется даже если это можно (и по хорошему нужно) автоматизировать.
Судя по статье — у вас есть успешный опыт атоматического тестирования.
Неудачный опыт тоже есть :)
Если серьезно, легко дать совет вида «пишите Unit-тесты!». К сожалению вам это вряд ли поможет если не навредит.
Говорить о каком то решении со стороны, не понимая специфики вашей работы, ваших ограничений, в ваших трудностей было бы неосмотрительно.
Вы говорите о ряде проблем:
1. Разработка тестов отнимает время — можете ли вы сократить накладные расходы при этом сохранив пользу от тестов?
2. Нужны разработчики со спец навыками — зачем они нужны? можете ли вы обучить имеющихся разработчиков? можете ли вы нанять необходимых разработчиков?
3. Тесты покрывают не все задачи — какие покрывают а какие нет? есть ли смысл связываться с тестированием ради проверки тех задач которые можно ими проверить? можно ли расширить область действия тестов?
Попробуйте задать себе вопросы в этом роде и подумайте как можно на них ответить.
Лучшее решение ваших проблем можете найти только вы сами.
Первые 2 пункта проверяются легко – Selenium-тестами :)
Нагрузка проверяется JMeter'ом (помимо него инструментов достаточно, тот же питоновый Locust например).
А больше всего мне интересно, как вы будете нагрузку в разрезе огромного количества юзеров тестировать руками.
Нагрузка проверяется JMeter'ом (помимо него инструментов достаточно, тот же питоновый Locust например).
А больше всего мне интересно, как вы будете нагрузку в разрезе огромного количества юзеров тестировать руками.
Мне известны примеры, когда в тестировании участвуют десятки тестировщиков. Сейчас эта тема вполне актуальна, когда речь идёт о важной системе в солидной компании.
Если ни один из этих десятков тестировщиков не может настроить JMeter который эмулирует нагрузку в миллионы пользователей – вопрос, стоит ли вообще работать в такой «солидной компании».
Для выявления некоторых (самых неприятных) багов, иногда бывает нужно смоделировать не просто нагрузку, а сложный прикладной поведенческий тест. Для этого приходится вникать и в прикладную область и разрабатывать мудрёные алгоритмы.
PS А вы всерьёз думали, что эти несчастные долбят как мартышки по клавишам?
PS А вы всерьёз думали, что эти несчастные долбят как мартышки по клавишам?
Я вот даже и не пойму, вы троллите или серьезно пишете :)
Ну да, нагрузку можно по-разному моделировать, по сценариям – тоже можно. А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю. Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).
Ну да, нагрузку можно по-разному моделировать, по сценариям – тоже можно. А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю. Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).
А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю.
Если вы имеете в виду — смоделировать нагрузочный тест как примитивную DDOS-атаку, то да — это будет делать скрипт.
Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).
Поведенческие тесты нужны тогда, когда надо выявить, например, скрытую/плавающую ошибку. Разработать, провести такой тест и получить положительный результат (выявить причину проблемы) — большая работа. В каждом конкретном случае такие тесты уникальны.
Кстати, сейчас востребованы услуги по тестированию ПО, которые предоставляются по схеме аутсоурсинга. Мне известна одна такая фирма. В штате у неё несколько десятков тестировщиков (с разными проф. навыками). У неё всегда есть заказы, а услуги далеко не всем по-карману.
Интересно :) Мне всегда казалось, что тестирование отдельно от разработки не продать.
Мне всегда казалось, что тестирование отдельно от разработки не продать.
Отлично продаётся. Главные потребители — банки и корпорации. У них сейчас сенокосная пора на мобильную разработку. А свой штат тестировщиков держать на окладе — зачем? Тестировщики востребованы только по мере появления нового ПО (и собственной и сторонней разработки).
Все передовые банки давно перешли на Agile, где тестировщик – неотъемлемая часть команды любой разработки. Отдельно сидящие тестировщики – это архаизм :)
Отдельно сидящие тестировщики – это архаизм :)
Качественное тестирование может обеспечить только внешняя, неаффелированная команда (это из области психологии — почему так, учёные пока объяснить не могут).
Тестировать надо (в солидных компаниях, которые привыкли заботиться о своей репутации) не только собственные разработки, но и любые ПО-продукты, которые там внедряют.
У меня был опыт работы во внешней команде, есть опыт разработки в команде с разработчиками – так вот скорость и качество разработки во втором случае это небо и земля. Внешняя команда играет в пинг-понг с разработчиками и не имеет общих интересов.
У каждой компании свои цели, мотивация и представления о расходах и качестве ПО.
Тестировщики, о которых вы говорите — входят в обязательный штат современной компании-разработчика ПО.
Внешнее тестировщики нужны, когда компания не хочет, чтобы её 100500 клиентов выступили в качестве тестировщиков.
Для внешнего тестирования отлично подходит аутсоурсинговая компания.
Тестировщики, о которых вы говорите — входят в обязательный штат современной компании-разработчика ПО.
Внешнее тестировщики нужны, когда компания не хочет, чтобы её 100500 клиентов выступили в качестве тестировщиков.
Для внешнего тестирования отлично подходит аутсоурсинговая компания.
Нагрузочное тестирование это отдельный пласт стэков технологий/решений, так что вполне ожидаемо, что для реализации этого вида тестирования нужны соответствующие специалисты.
Дать задачу автоматизатору написать простой нагрузочный скрипт конечно можно и большинство с задачей, я думаю, справятся.
Вот только правильно интерпретировать NFE(Non-Functional requirements) заказчика, с учетом контекста разрабатываемого решения(читай вникнуть в архитектуру, разобраться, вычислить потенциальные bottle-neck`и) может только опытный и квалифицированный человек.
Кроме того в нагрузочном тестировании существует своя специфика подходов, методологий и т.д.
И для полноценного нагрузочного тестирования, нужен человек, который понимает эту специфику и желательно имеет опыт работы с ней.
Мне казалось очевидным, что различные виды тестирования имеют свой набор специалистов.
Правда стоит отметить что это утверждение распостраняется не на все виды тестирования.
Дать задачу автоматизатору написать простой нагрузочный скрипт конечно можно и большинство с задачей, я думаю, справятся.
Вот только правильно интерпретировать 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%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.это вообще смешно, измерять можно покрытие логики тестами, а не сколько времени что-то тестировали
без тестов любое изменение чревато проблемами
с тестами любое изменение становятся проблемой. И тесты не бесплатны
не могу себе представить варианта где тесты могут стать проблемой, разве что для «эффективного» менеджера который обещал релиз через пару дней, а писать тесты займёт 3 дня
если изменение требует переписать кучу тестов, наверно это огромное изменение либо тесты как-то очень не эффективно написаны и это не вина тестов
если изменение требует переписать кучу тестов, наверно это огромное изменение либо тесты как-то очень не эффективно написаны и это не вина тестов
Вы слишком абстрактно смотрите на тестирование,
тестирование это исключительно прикладная область.
На эту тему есть отличная книга Perfect Software от Gerald M. Weinberg.
тестирование это исключительно прикладная область.
На эту тему есть отличная книга Perfect Software от Gerald M. Weinberg.
почему-то люди неосознанно ищут серебрянную пулю и даже административно вводят её (например 100% покрытие тестами обязательно).
В реальности же конечные требования известны только в космосе, медицине и военке. В остальных областях потребуется несколько раз всё переделать, прежде чем станут известны конечные требования и будут видны очертания результата.
И тесты очень сильно замедляют и удорожают эти изменения. Вместо быстрого прототипа люди пытаются делать решение на века со 100% покрытием. Даже если этого никому не нужно.
В реальности же конечные требования известны только в космосе, медицине и военке. В остальных областях потребуется несколько раз всё переделать, прежде чем станут известны конечные требования и будут видны очертания результата.
И тесты очень сильно замедляют и удорожают эти изменения. Вместо быстрого прототипа люди пытаются делать решение на века со 100% покрытием. Даже если этого никому не нужно.
Могу рассказать свою историю. На нынешнюю работу я пришёл из аутсорса и всяких мелких проектиков, где без тестов жилось нормально (ну а в аутсорсе и вовсе гигантский штат QA это средство извлечения прибыли). Так вот, здесь бизнес-логика покрыта юнит- и интеграционными тестами (на 76%), есть UI тесты а-ля регрессия и приёмочные (сертификационные) UI тесты. В итоге разработке тесты не мешают и её не замедляют (падают по делу и до продакшена плохой код не доходит), а вручную тестируются только новые фичи (регрессии как таковой нет).
UFO just landed and posted this here
Грамотно написано.
UFO just landed and posted this here
Работал в конторе где оптимизировали.
'Исправляя проблемы быстро, можно добиться гораздо более высокого качества продукта, '
Добились времени решение любой проблемы — менее одного бизнес дня.
Качество продукта было космическим.
Тестов в классическом понимании не было совсем. Были так называемые мониторинг тесты.
Любая функциональность пушит метрики в систему анализа. +Устанавливается система алертинга
(Что то не происходило в течении часа -> приводит к вызову программиста который на дежурстве)
+На продакшене постоянно крутились скрипты которые кликали сайт в браузере через web driver и тоже пушили метрики (Поэтому все им доверяли ибо если один пробег скрипта не прошел это не приводило к alerts. И качество их могло быть вполне себе 'на скорую руку')
Все это(метрики) также использовались дизайнерами чтобы понимать какой UX оптимизировать.
(Мы видим 1000 событий заполнил поле email но только 10 заполнил поле lastName -> давайте удалим этот lastName к чертям, людям все равно не нравится)
Обращение к customer support тоже было метрикой, так что если вдруг полетели заявки больше обычного — вот тебе и alert и программист сидит разбирается что почему.
Все это реально работало, при этом не требовало 100% покрытия, идеальных тестов и.т.п.
'Исправляя проблемы быстро, можно добиться гораздо более высокого качества продукта, '
Добились времени решение любой проблемы — менее одного бизнес дня.
Качество продукта было космическим.
Тестов в классическом понимании не было совсем. Были так называемые мониторинг тесты.
Любая функциональность пушит метрики в систему анализа. +Устанавливается система алертинга
(Что то не происходило в течении часа -> приводит к вызову программиста который на дежурстве)
+На продакшене постоянно крутились скрипты которые кликали сайт в браузере через web driver и тоже пушили метрики (Поэтому все им доверяли ибо если один пробег скрипта не прошел это не приводило к alerts. И качество их могло быть вполне себе 'на скорую руку')
Все это(метрики) также использовались дизайнерами чтобы понимать какой UX оптимизировать.
(Мы видим 1000 событий заполнил поле email но только 10 заполнил поле lastName -> давайте удалим этот lastName к чертям, людям все равно не нравится)
Обращение к customer support тоже было метрикой, так что если вдруг полетели заявки больше обычного — вот тебе и alert и программист сидит разбирается что почему.
Все это реально работало, при этом не требовало 100% покрытия, идеальных тестов и.т.п.
Спасибо за пример из реальной жизни :)
Это по сути пользователи за вас делали тесты.
Не, ну стандартный тестировщик у нас тоже был. Прежде чем от stage к prod перейти, человек все таки проверял что оно работает.
Просто за место: «О а давайте покроем все возможные сценарии тестами и потратим кучу времени на это.»
Было: «Так этот кусок программы должен приводить к рассылки инвайтов. Давайте пушить когда пользователь кликнул на кнопку и запишем если API ответит с ошибкой.»
Уходило на это час. И уверенность в качестве было.
Просто за место: «О а давайте покроем все возможные сценарии тестами и потратим кучу времени на это.»
Было: «Так этот кусок программы должен приводить к рассылки инвайтов. Давайте пушить когда пользователь кликнул на кнопку и запишем если API ответит с ошибкой.»
Уходило на это час. И уверенность в качестве было.
Уверенность в качестве это когда вы знаете, что API не ответит ошибкой при нормальном user flow.
То, о чём вы говорите — это уверенность в возможности быстро локализовать проблему.
Проблема «мониторинговых» тестов в том, что они алертят постфактум. Т.е. вы узнаете о проблеме только тогда, когда N пользователей вместо ожидаемого результата получат хрен.
Более того, в случае новой функциональности и всяких изощренных юсабилити экспериментов всё ещё сложнее — вы не всегда можете понять, то ли UX эксперимент не удался и конверсия просела, то ли пользователь не видит кнопку сабмита формы (условно) и уходит нахрен.
Пока вы это выясняете — пользователи испытывают баттхёрт. И вы их теряете (при условии, конечно, что у них есть альтернатива, но если её нет — можно и вообще не париться, и так схавают).
То, о чём вы говорите — это уверенность в возможности быстро локализовать проблему.
Проблема «мониторинговых» тестов в том, что они алертят постфактум. Т.е. вы узнаете о проблеме только тогда, когда N пользователей вместо ожидаемого результата получат хрен.
Более того, в случае новой функциональности и всяких изощренных юсабилити экспериментов всё ещё сложнее — вы не всегда можете понять, то ли UX эксперимент не удался и конверсия просела, то ли пользователь не видит кнопку сабмита формы (условно) и уходит нахрен.
Пока вы это выясняете — пользователи испытывают баттхёрт. И вы их теряете (при условии, конечно, что у них есть альтернатива, но если её нет — можно и вообще не париться, и так схавают).
Вот еще один плюс автотестов в копилку — они хороши, когда разработчик сам может их запустить на своей ветке. Он найдет регрессионный баг (т.е. увидит, что сломал что-то до него работающее), не вовлекая в процесс и не отнимая время у тестировщика, который найдет тот же баг, но руками и позднее, релиз инженера, который будет заниматься выкладкой этой задачи на препродакш, второго разработчика, который будет делать ревью кода и всех остальных в зависимости от того вашего флоу.
И того один человек написал тест и сэкономил время нескольким коллегам. :)
И того один человек написал тест и сэкономил время нескольким коллегам. :)
Ну не все так однозначно, тут тоже придется считать. Ведь время, которое потратит разработчик на тестирование, и соответственно не-писание новых нужных бизнесу фич, стоит вполне конкретных денег, которые могут быть больше или меньше затрат на тестировщика и всю эту остальную веселую компанию. Отдельные регрессионные тесты могут выполняться целую вечность, а для запуска других, порой, приходится ждать наступления определенной фазы (нет, не луны, а готовности других компонентов). Как бы то ни было, в порочном круге Software Release Life Cycle всему найдется свое место и свое время.
Стойте-стойте. А как же качество продукта? Или у вас производительность программиста исчисляется не в числе решенный задач, а в строках кода, которые он написал?
Задача программиста не писать код, а решать поставленные задачи с помощью написания кода. Как программист должен узнать, что задача решена и решена корректно, если у него нет инструмента проверки валидности логики?
Код, который запускается это далеко не тот же самый код, который работает корректно. Даже если вы пишете на Haskell и Scala.
Код, который работает корректно, это не всегда тот, код, который делает то, что нужно, и так как нужно. QA это комплексная проблема, которая решается только в комплексе.
Все заранее известно и разработка сводится к программированию лишь на уроках информатики. На практике приходится иметь дело с большим разнообразием функциональных и не функциональных требований, кроме валидности логики, прежде чем сдавать работу.
И потом, не стоит сбрасывать со счетов банальный человеческий фактор. Два глаза хорошо, а четыре еще лучше. :)
Все заранее известно и разработка сводится к программированию лишь на уроках информатики. На практике приходится иметь дело с большим разнообразием функциональных и не функциональных требований, кроме валидности логики, прежде чем сдавать работу.
И потом, не стоит сбрасывать со счетов банальный человеческий фактор. Два глаза хорошо, а четыре еще лучше. :)
UFO just landed and posted this here
особенно трудно, когда ручной тестировщик не понимает зачем ему нужно писать кейсы на автоматизацию проверок и зачем вообще нужны автотесты, ведь можно ручками все проверить!
Вот это преимущество автоматизированного тестирования
и это преимущество ручного
одно и то же.
Всеобъемлемость — автоматические тесты позволяют покрыть огромное количество сценариев и находить наведенные ошибки в таких далеких углах приложения, до которых ручной тестировщик никогда бы не добрался, кроме как случайно.
и это преимущество ручного
Креативность — ручное тестирование позволяет найти проблемы, которые заранее не были известны, более того, даже не подразумевались.
одно и то же.
UFO just landed and posted this here
Плюс поставить не могу, но хотел бы.
Статья поначалу затянула, а в конце удивила.
Возникло ощущение, что все в кашу. Обычно регрессионное тестирование и ручное происходят из единого описания сценариев тестирования. Тут нельзя спутать, какой сценарий не прошел. Если подходить системно, то картинка вся должна быть на виду. Автотест не прошел? Повторяем сценарий руками. По контексту ошибки и ручного прогона поймем что делать дальше.
А если как-то появилась толпа автотестов и они с ручным тестированием непонятно как пересекаются, то пора задуматься об управлении тестированием как процессе.
Статья поначалу затянула, а в конце удивила.
Возникло ощущение, что все в кашу. Обычно регрессионное тестирование и ручное происходят из единого описания сценариев тестирования. Тут нельзя спутать, какой сценарий не прошел. Если подходить системно, то картинка вся должна быть на виду. Автотест не прошел? Повторяем сценарий руками. По контексту ошибки и ручного прогона поймем что делать дальше.
А если как-то появилась толпа автотестов и они с ручным тестированием непонятно как пересекаются, то пора задуматься об управлении тестированием как процессе.
Как такое возможно? QA написавший тест всегда знает о чем он, если он уже покинул команду — есть description
Вы подразумеваете что тесты достаточно хорошо документированы и структурированы — в реальности это не всегда так.
Если у вас тестировщик без комментариев реджектит тикет потому что «упал какой-то тест
По хорошему, задача не должна доходить до ручного тестирования если есть упавшие тесты.
Это элемент культуры разработки, проявление разработчиком уважения к труду ручного тестировщка.
Зачем было создавать 20 тысяч?
Хороший вопрос! Но, мне кажется, не все задают его себе прежде чем написать 20 тысяч тестов :)
Что касается:
То для того, чтобы такого не было, нужно дробить огромные методы с убер-логикой на маленькие логически оформленные блоки (методы). Тогда каждый блок кода можно протестировать отдельно, и изменение одной строчки в убер-методе не приведет к необходимости переписывать 80 тестов.
нужно поправить 5 мест в основном коде и еще 80 в тестах
То для того, чтобы такого не было, нужно дробить огромные методы с убер-логикой на маленькие логически оформленные блоки (методы). Тогда каждый блок кода можно протестировать отдельно, и изменение одной строчки в убер-методе не приведет к необходимости переписывать 80 тестов.
и в случае какой-то мажорной правки придется выкидывать все эти 100500 маленьких оформленных блоков
А какая разница, что выкидывать — 100500 мелких блоков, или один большой, если надо выкидывать? А вот когда у вас есть метод на 200 строк кода, и вы вносите два изменения в начале и в конце — вам придется внести изменения во все 20 тестов, т.к. тестом покрыт весь метод от и до. Если в каждом из двух мелких изменений нужно проверить по 3 варианта развития событий, то ваши 20 тестов превратятся сначала в 60 тестов, а потом ещё в 210. Чтобы проверить все варианты событий. И вот вам надо внести правку в третье место, где тоже надо отследить 3 варианта развития событий…
Что делать? Если ваш большой метод разбит на части, и все они покрыты 20-ю тестами изначально, то каждая правка принесет по +3 теста на конкретный отдельный блок. Т.е. 20+3+3 = 26 тестов. Есть разница — 26 тестов или 210? Грубые подсчеты, конечно, но отражают действительность. Сложность поддержки тестов на отдельный метод растет в экспоненциальной прогрессии от кол-ва строк в нем.
Что делать? Если ваш большой метод разбит на части, и все они покрыты 20-ю тестами изначально, то каждая правка принесет по +3 теста на конкретный отдельный блок. Т.е. 20+3+3 = 26 тестов. Есть разница — 26 тестов или 210? Грубые подсчеты, конечно, но отражают действительность. Сложность поддержки тестов на отдельный метод растет в экспоненциальной прогрессии от кол-ва строк в нем.
без проблем, можно каждый if поместить в отдельную функцию и тестировать её.
Количество кода от этого возрастет. Сложность тоже.
И в чем смысл писать тест на if? Проверять что глаза меня не обманывают? Что компилятор не сломался?
Количество кода от этого возрастет. Сложность тоже.
И в чем смысл писать тест на if? Проверять что глаза меня не обманывают? Что компилятор не сломался?
А я разве призывал каждый if выносить в отдельный метод и тестировать его? Это вы сами придумали и обвиняете меня в своих фантазиях. Это вы, а не я, придумал мифические 100500 методов. Если вы профан в грамотной структуризации кода и не понимаете, зачем нужны тесты, то не надо с такой примитивной позицией прыгать по комментами и строчить ахинею, пытаясь доказать неизвестно что.
повторю, сказанное vdasus 7 февраля 2017 в 14:13
+5
— Серебрянной пули нет
— Надо использовать инструменты там, где это разумно
— Надо правильно расставлять приоритеты
Автотесты нужны, в частности, при обнаружении эффекта накопления-тепла, зарядов,- что почти невозможно
обнаружить вручную,
особенно в процессорах графической, спектральной и т.д. обработки
+5
— Серебрянной пули нет
— Надо использовать инструменты там, где это разумно
— Надо правильно расставлять приоритеты
Автотесты нужны, в частности, при обнаружении эффекта накопления-тепла, зарядов,- что почти невозможно
обнаружить вручную,
особенно в процессорах графической, спектральной и т.д. обработки
Совершенно непонятно, о каких именно тестах написана статья. В тексте явно упоминается selenium, «вернуть задачу к разработчикам», хрупкость тестов при смене интерфейса, в преимущество ручных тестов вписана «гибкость» на примере тестирования в сафари. Т.е. вроде как речь об автоматизации работы QA.
И тут же, в ту же кучу — тесты до кода, правка тестов самими разработчиками, упоминания юнит тестов, «Тесты — такой же код» — т.е. явно не автоматизация работы QA, а именно юнит-тесты. Ну или в крайнем случае интеграционные. Юнит тесты призваны экономить время разработчиков. QA вообще не должно быть никакого дела до наличия или отсутствия юнит-тестов. Фраза «вернуть задачу к разработчикам при красном юнит тесте» — не имеет смысла — билд просто не должнен доходить до QA при красных юнит/интеграционных тестах.
Юнит-тесты — не альтернатива ручному тестированию. И, тем более, не аналог и не замена автоматизированному тестированию UI, вроде selenium. Это просто другой вид тестирования. А вы вписали в общий список все достоинства и все недостатки разных видов тестирования, даже тех, которые вообще в зону ответственности QA не входит. И перемешали. Не хватает только пунктов «selenium не умеет самостоятельно проводить penetration test-ы» и «юнит-тестами тяжело протестировать документацию» :)
С таким же успехом можно было расписать достоинства и недостатки JavaScript, достоинства .NET/Java, lua-скриптов, powershell, SQL, а потом перемешать это в один список «Блеск и нищета написания кода».
Т.е. вроде как была идея написать интересный противоречивый пост с интригой и открытой концовкой. Но выглядит так, как будто статью писал не лидер backend разработки, а маркетолог, которому выдали брошюру «разные виды тестирования для чайников» :(
И тут же, в ту же кучу — тесты до кода, правка тестов самими разработчиками, упоминания юнит тестов, «Тесты — такой же код» — т.е. явно не автоматизация работы QA, а именно юнит-тесты. Ну или в крайнем случае интеграционные. Юнит тесты призваны экономить время разработчиков. QA вообще не должно быть никакого дела до наличия или отсутствия юнит-тестов. Фраза «вернуть задачу к разработчикам при красном юнит тесте» — не имеет смысла — билд просто не должнен доходить до QA при красных юнит/интеграционных тестах.
Юнит-тесты — не альтернатива ручному тестированию. И, тем более, не аналог и не замена автоматизированному тестированию UI, вроде selenium. Это просто другой вид тестирования. А вы вписали в общий список все достоинства и все недостатки разных видов тестирования, даже тех, которые вообще в зону ответственности QA не входит. И перемешали. Не хватает только пунктов «selenium не умеет самостоятельно проводить penetration test-ы» и «юнит-тестами тяжело протестировать документацию» :)
С таким же успехом можно было расписать достоинства и недостатки JavaScript, достоинства .NET/Java, lua-скриптов, powershell, SQL, а потом перемешать это в один список «Блеск и нищета написания кода».
Т.е. вроде как была идея написать интересный противоречивый пост с интригой и открытой концовкой. Но выглядит так, как будто статью писал не лидер backend разработки, а маркетолог, которому выдали брошюру «разные виды тестирования для чайников» :(
Ну кстати да, тут разные уровни и виды тестирования в кучу. Боюсь что проблема описанная в статье происходит от слабого понимания темы.
Вы зря делите полезность тестов для QA по технологическому признаку.
То что отдельная проверка реализована по принципам unit тестирования, а не как selenium тест,
совершенно не значит что такой тест будет не понятен и бесполезен QA. Может быть этот то что нужно.
Польза от теста ручному тестированию определяется не технологией использованной при
написании конкретного теста, а его осмысленностью и выразительностью.
Точно также, любой тест на любой технологии может быть написал плохо и создавать больше проблем чем приносить пользы.
Тесты это тесты.
Конечно! Жалко не все так делают :)
То что отдельная проверка реализована по принципам unit тестирования, а не как selenium тест,
совершенно не значит что такой тест будет не понятен и бесполезен QA. Может быть этот то что нужно.
Польза от теста ручному тестированию определяется не технологией использованной при
написании конкретного теста, а его осмысленностью и выразительностью.
Точно также, любой тест на любой технологии может быть написал плохо и создавать больше проблем чем приносить пользы.
Тесты это тесты.
билд просто не должнен доходить до QA при красных юнит/интеграционных тестах.
Конечно! Жалко не все так делают :)
Я не делю тесты по полезности для QA — это вообще не имеет смысла. Тесты пишутся (или прогоняются, если они ручные) не ради QA. Они пишутся ради обеспечения качества продукта. За качество надо платить, в основном, временем разработчиков (кодеров и тестировщиков).
Но вот ваша статья не только делит полезность тестов для разработчиков по технологическому признаку. Вы прямо противопоставляете принципиально разные виды тестирования, и выдаете из этого целую статью.
Точно так же можно написать статью о том, что «SQL по сравнению с JavaScript имеет как достоинства, так и явные недостатки», с кучей очень обоснованных доводов в пользу как SQL, так и JS.
Но вот ваша статья не только делит полезность тестов для разработчиков по технологическому признаку. Вы прямо противопоставляете принципиально разные виды тестирования, и выдаете из этого целую статью.
По сравнению с ручным тестированием, автоматизированное имеет как достоинства так и явные недостатки
Точно так же можно написать статью о том, что «SQL по сравнению с JavaScript имеет как достоинства, так и явные недостатки», с кучей очень обоснованных доводов в пользу как SQL, так и JS.
QA вообще не должно быть никакого дела до наличия или отсутствия юнит-тестов.
Вот это вот очень интересно :) А разработчик сам придумает все покрытие? Уметь писать код != уметь тестировать, а тестировать свое же еще сложнее. В идеале QA накидает кейсов, разработчик напишет юниты, QA их отревьюит/дополнит, и только после этого можно считать что ваш кусок тестами закрыт.
Юнит-тесты (если они именно юнит, а не интеграционные) не пишутся по тесткейсам от QA. Юнит-тесты покрывают небольшие куски кода — отдельные методы, отдельные классы, отдельные вызовы в коде.
«SomeService при вызове SaveSomething, при условии что зависимость ISomeRepo вернет минимум 5 строк, в вызове GetSomeItems() заполнит поле SomeField у сохраняемого объекта значением SomeValue» — вот что проверяет юнит тест. Это просто проверка на наличие какого-то условия или какого-то вызова в коде.
QA обычно ничего не знаю о классах и об отдельных методах. Поэтому QA не может полноценно ревьювить и дополнять юнит-тесты. И дело не только в знании конкретного ЯП или фреймворка. Дело в том, что количество юнит тестов должно соответствовать количеству проверок и прочих методов принятия решений в коде. Собственно, в этом и состоит работа разработчика — переложить требования с человеческого (в виде User Story, документации, чего угодно) на язык if-ов и while-ов.
Современные языки программирования хорошо приспособлены для описания бизнес-логики. Они позволяют делать это гораздо компактнее русского или английского языков. Поэтому полноценное описание функционала (спецификация), если она действительно описывает весь функционал, должна несколько раз превышать по объему код приложения. А т.к. нет способов поддерживать и рефакторить текст спецификации с той же легкостью, что и код приложения — то написание такой «полноценной» спецификации должно занимать намного больше времени, чем написание кода. Именно поэтому все спецификации обычно далеки от полноты, и попытки «сгенерировать код по спеке» обречены на провал.
То же самое с тесткейсами для юнит-тестов. Их должно быть столько же, сколько проверок. Более того, написание кейсов для юнит-тестов QA, заранее, подразумевает что QA настолько хорошо представляет себе структуру приложения, что может точно сказать в каком методе, где именно и как именно будет написан каждый if. Если у вас QA так круты — то разработчики вам не нужны. Ну и объем таких тексткейсов будет точно так же превышать объем кода.
Поэтому да, для юнит-тестов разработчик сам придумывает покрытие. Точно так же, как он сам придумывает, где к коде написать if. И проверяют юнит-тесты именно наличие if-а или наличие вызова. Загораясь красным, когда кто-то лажанет при мерже, или неудачно подрефакторит. Или просто случайно выкосит проверку.
Те тесты, которые (иногда) пишутся по кейсам (или могут быть представлены в виде кейсов), по принципу один кейс — один тест — это или интеграционные или функциональные тесты. Т.е. это или selenium и прочие тыкалки интерфейса, тесты на всю систему в сборе (включая базу), или тесты «на бэкенд в сборе + базу».
«SomeService при вызове SaveSomething, при условии что зависимость ISomeRepo вернет минимум 5 строк, в вызове GetSomeItems() заполнит поле SomeField у сохраняемого объекта значением SomeValue» — вот что проверяет юнит тест. Это просто проверка на наличие какого-то условия или какого-то вызова в коде.
QA обычно ничего не знаю о классах и об отдельных методах. Поэтому QA не может полноценно ревьювить и дополнять юнит-тесты. И дело не только в знании конкретного ЯП или фреймворка. Дело в том, что количество юнит тестов должно соответствовать количеству проверок и прочих методов принятия решений в коде. Собственно, в этом и состоит работа разработчика — переложить требования с человеческого (в виде User Story, документации, чего угодно) на язык if-ов и while-ов.
Современные языки программирования хорошо приспособлены для описания бизнес-логики. Они позволяют делать это гораздо компактнее русского или английского языков. Поэтому полноценное описание функционала (спецификация), если она действительно описывает весь функционал, должна несколько раз превышать по объему код приложения. А т.к. нет способов поддерживать и рефакторить текст спецификации с той же легкостью, что и код приложения — то написание такой «полноценной» спецификации должно занимать намного больше времени, чем написание кода. Именно поэтому все спецификации обычно далеки от полноты, и попытки «сгенерировать код по спеке» обречены на провал.
То же самое с тесткейсами для юнит-тестов. Их должно быть столько же, сколько проверок. Более того, написание кейсов для юнит-тестов QA, заранее, подразумевает что QA настолько хорошо представляет себе структуру приложения, что может точно сказать в каком методе, где именно и как именно будет написан каждый if. Если у вас QA так круты — то разработчики вам не нужны. Ну и объем таких тексткейсов будет точно так же превышать объем кода.
Поэтому да, для юнит-тестов разработчик сам придумывает покрытие. Точно так же, как он сам придумывает, где к коде написать if. И проверяют юнит-тесты именно наличие if-а или наличие вызова. Загораясь красным, когда кто-то лажанет при мерже, или неудачно подрефакторит. Или просто случайно выкосит проверку.
Те тесты, которые (иногда) пишутся по кейсам (или могут быть представлены в виде кейсов), по принципу один кейс — один тест — это или интеграционные или функциональные тесты. Т.е. это или selenium и прочие тыкалки интерфейса, тесты на всю систему в сборе (включая базу), или тесты «на бэкенд в сборе + базу».
Не смешивайте функциональные тест-кейсы от QA и кейсы, которые нужно проверить для отдельной функции и куска кода. Я про первые и не писал. Вы все правильно расписали про условные if и ветки и про их покрытие. Вопрос в том, что разработчик – человек, и может что-то забыть, а QA это увидит при код-ревью и подскажет. Или даст идей, что проверить. Или увидит, что тест ничего не проверяет на самом деле, или проверяет неправильно (и код работает неправильно). Затем и нужен. И да, QA должен хорошо знать приложение и код, чтобы уметь так делать.
Да, QA может подсказать. Но другие разработчкими справляются с этим намного лучше и быстрее. Т.е. гораздо эффективнее ввести peer code review (через те же пулл реквесты) и получить заодно повышение code ownership, чем надеятся что QA смогут что-то в коде увидеть, и тем более заранее написать кейсы на юнит-тесты (это вообще нереально в более-менее нетривиальном приложении).
Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю — 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.
это вообще смешно, измерять можно покрытие логики тестами, а не сколько времени что-то тестировали
принцип Паретто никто не отменял еще. (потратив всего 20% времени на тестирование мы находим — 80% дефектов, и нужно потратить еще 80% времени чтобы найти оставшиеся 20% дефектов).
в принципе это аргумент в пользу ручного тестировария.
но в контексте итеративной модели разработки, когда релизится нужно каждые две недели — а время на регрессию — постоянно растет — трудно обойтись без автотестов (в противном случае тайм ту аркет увеличивается).
Прихожу к выводу, что если у вас сразу много денег и план на 10 лет вперед по развитию продукта — то вкладывайтесь в автоматизацию тестирования.
Если у вас стартап, где важны быстрота выхода первой бетты или продукт типа сделал раз и забыл — то нет смысла тратить время.
Если у вас стартап, где важны быстрота выхода первой бетты или продукт типа сделал раз и забыл — то нет смысла тратить время.
У вас очень странные выводы.
Если у вас стартап, который требует динамичного развития, вы уверены, что у вас есть ресурсы гонять 5 часовую регрессию руками?
Если у вас стартап, который активно набирает обороты, уверены ли вы, что стоит жертвовать качеством ради ускорения релизов на 10-15% времени? (И, что важнее, так ли в этом уверены ваши пользователи?)
Во всём нужен баланс.
Если у вас стартап, который требует динамичного развития, вы уверены, что у вас есть ресурсы гонять 5 часовую регрессию руками?
Если у вас стартап, который активно набирает обороты, уверены ли вы, что стоит жертвовать качеством ради ускорения релизов на 10-15% времени? (И, что важнее, так ли в этом уверены ваши пользователи?)
Во всём нужен баланс.
[irony]Буду краток. Удачи вам, на регрессии.[/irony]
Говорят, что статику плохо тестировать. :)
Что думают хабровчане? :)
Что думают хабровчане? :)
Sign up to leave a comment.
Блеск и нищета автоматизации тестирования