Принято считать, что наличие автоматических тестов — это безусловное благо. Если разработчики пишут тесты — это хорошо, чем больше тестов, тем лучше. При этом, в реальности их чаще не пишут, а все тестирование делают вручную.
Не стоит списывать такое положение дел на некомпетентность, глупость или банальную лень разработчиков. По сравнению с ручным тестированием, автоматизированное имеет как достоинства так и явные недостатки. Если бы были одни только плюсы, и говорить было бы не о чем.
Преимущества автоматических тестов
Автоматизированное тестирование имеет ряд существенных преимуществ по сравнению с ручным тестированием.
Дешевизна — прогон автоматических тестов всегда дешевле ручной проверки на несколько порядков. Разработка автоматических тестов конечно дороже разового ручного тестирования.
Неутомимость — автоматические тесты можно запускать снова и снова, у них неограниченный рабочий день, они не устают, и не болеют.
Скорость — автоматические тесты выполняются на порядки быстрее, чем те же проверки, выполненные вручную. Конечно, бывают и сравнительно медленные тесты, но это скорее исключение, подтверждающее правило.
Точность — автоматические тесты проверяют ровно то, что описано в сценарии, во всех деталях и мелочах. Они не отвлекаются, не путают и не забывают.
Всеобъемлемость — автоматические тесты позволяют покрыть огромное количество сценариев и находить наведенные ошибки в таких далеких углах приложения, до которых ручной тестировщик никогда бы не добрался, кроме как случайно.
Преимущества ручного тестирования
Ручное тестирование, тем не менее, превосходит автоматизированное по многим аспектам.
Проворность — проверить что-то вручную в первый раз легко и быстро. Автоматический тест нужно прежде разработать. Практически всегда это гораздо медленнее ручной проверки.
Гибкость — ручное тестирование можно проводить гораздо разнообразнее, и изменение способа тестирования практически ничего не стоит. Давайте протестируем в Safari — пожалуйста, на Chromebook — нет проблем, IE6 — придется запустить виртуальную машину, но тоже можно.
Адаптируемость — умение быстро подстраиваться под изменения. Когда продукт серьезно меняется, и все начинает работать совсем не так, как раньше, ручные тестировщики легко могут забыть, как они тестировали прежде. Они просто будут тестировать то, что есть сейчас. Автоматические тесты в той же ситуации выдадут тысячи ошибок, и их придется исправить, прежде чем двигаться дальше.
Креативность — ручное тестирование позволяет найти проблемы, которые заранее не были известны, более того, даже не подразумевались.
Осмысленность — хотя каждая вещь в отдельности может быть абсолютно корректна, люди гораздо легче понимают, что вместе эти вещи не имеют никакого смысла.
Выразительность — мало найти проблему на уровне “ничего не работает!”, важно правильно объяснить, в чем она заключается и уметь ответить на дополнительные вопросы разработчика. И в этом люди также лучше автоматических тестов.
Аутентичность — большинство приложений мы пишем для людей, и именно поэтому люди лучше всего подходят для их тестирования.
Блеск парадоксов тестирования
Говоря о тестировании, и тем более о полном тестировании, мы немного лукавим. Очевидно что проверить все невозможно.
Все что мы можем сделать на практике, это осуществить некоторое достаточное тестирование. В результате мы с определенной долей вероятности сможем утверждать что большинство пользователей не столкнутся с проблемами.
Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю — 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.
Исправляя проблемы быстро, можно добиться гораздо более высокого качества продукта, нежели вкладывая все имеющиеся ресурсы в достижение полного покрытия тестами. Соль в том чтобы найти баланс в приложении сил.
Ручное тестирование дает гораздо больше отдачи, если разрабатывать нужно быстро, особенно если приложение меняется инкрементально, в локальных предсказуемых частях. Причина в том, что проверить изменение руками гораздо быстрее, чем автоматизировать тот же тест.
Автоматическое тестирование дает очень маленькую отдачу на коротких дистанциях. В каждый отдельный момент, решая что выгоднее, писать тесты или не писать, второе всегда предпочтительнее.
Ситуация в корне меняется в длительной перспективе. Код приложения необходимо рефакторить, чтобы он не умер. Когда программисты все переделали — тестировщики должны все проверить. Полный цикл регрессионных тестов. Неделя? Две? Месяц? Или еще хуже: программисты обновили версию ключевой библиотеки. День работы, вроде все компилируется — отлично! И все равно тестировщики должны проверить все. Безумие. Пройдя через такое несколько раз, любой будет готов пойти на что угодно, лишь бы избежать подобных ситуаций в будущем. Для обеспечения стабильного базового уровня качества необходимо вкладываться в автоматизацию тестирования.
К сожалению, автоматические тесты не всегда являются решением, иногда они сами становятся проблемой.
Нищета автоматизации тестирования
Проблема: нужно уметь проверять приложение полностью и быстро, ничего не упуская, много раз подряд.
Решение: написать автоматические тесты, которые все это делают.
Но не все так просто.
Написание тестов — это разработка, точно такая же, как и разработка основной бизнес-логики. Она требует ресурсов и квалификации. Обеспечивая качественное покрытие кода приложения тестами мы одновременно замедляем разработку как таковую. И замедляем не на 10%, а вдвое, втрое или даже больше.
Скорость — понятие относительное. Каждый конкретный тест, конечно, выполняется очень быстро, особенно чистые unit-тесты, когда все проверки происходят локально. Интеграционные тесты, REST-тесты тоже сравнительно быстрые. Что такое 100 миллисекунд, ну пусть даже 1 секунда, даже десятки секунд для selenium тестов — ерунда по сравнению с ручным тестированием. Но когда количество тестов хоть сколько-нибудь существенно, быстрые тесты оказываются очень даже медленными. Прогон тестов за 5 минут? Полчаса? Три часа? Два дня? Еще даже не добившись полноценного покрытия бизнес-логики, всерьез встает вопрос о том как запускать не все тесты, или запускать тесты не каждый раз — иначе уже автоматические тесты начинают тормозить разработку.
Примечание: Тесты можно существенно ускорить, вложившись в железо — выделить под них отдельный сервер, 10 серверов, 50 и т. д. Некоторые компании могут позволить себе и 1000 тестовых серверов, но далеко не все.
Инструментарий плох. Ни одна из мейнстримных платформ программирования не проектировалась с целью обеспечить возможность максимально просто и полноценно разрабатывать тесты. В Java все тестовые фреймворки являются сторонними библиотеками. Запуск тестов, осуществление проверок, создание mock-объектов — все это есть, но по частям и вне платформы. В Go тестовый фреймворк уже добавили в экосистему языка изначально, но это только запуск тестов. Выбор подходящего инструментария для написания тестов это отдельная проблема, требующая решения.
Не такие уж они и хорошие. Тесты — такой же код, написанный такими же разработчиками. Они тоже содержат ошибки и все те же проблемы, что и любой другой код. Бывает, что тест ничего не проверяет. Бывает, что тесты тоже нужно рефакторить. Бывает, что по упавшему тесту очень трудно понять, в чем проблема. Бывает, что тесты падают просто так, когда ошибки на самом деле нет.
Блокируют изменения. По своей природе тесты призваны проверять, что ничего не изменилось. Если что-то начало работать не так — это баг. Но когда бизнес-логика меняется, даже если изменение корректно и полностью соответствует новым требованиям — тесты об этом ничего не знают. Изменений нескольких правил может привести к необходимости исправить десятки, если не сотни тестов, особенно если покрытие действительно хорошее.
Ограничивают рефакторинг. Тесты тоже нужно рефакторить, даже если бизнес-логика не меняется, и в коде происходят лишь косметические изменения. Это может привести к тому что нужно поправить 5 мест в основном коде и еще 80 в тестах. Каждый в такой ситуации задумается: а стоит ли делать что-то большее, чем переименование метода.
Сизифов труд — вот во что превращается разработка через тестирование, когда тесты пишутся до написания кода или хотя бы по ходу дела. Любой грамотный разработчик рефакторит код в процессе его написания по мере того, как он все глубже разбирается в проблеме и понимает, как реализовать решение лучшим образом. Но если он пишет тесты одновременно с кодом, кроме изменений в коде ему приходится менять еще и тесты. А в отличии от рефакторинга готового кода, рефакторинг кода в работе обычно гораздо масштабнее, значит и требуемые изменения в тестах будут соответствующими. И так — много раз еще до того, как код уйдет на ревью. Половину рабочего времени в мусор — легко.
Количество тестов обманчиво: 3000 тестов в сумме — на веб-интерфейс, REST API, бизнес-логику и юнит-тесты — могут проверять с натяжкой 1000 ситуаций. Все остальное — дублирование.
Автоматическая регрессия не отменяет ручную вопреки главной задумке. Все потому что автоматические тесты проверяют много чего, но далеко не все. Но что конкретно они проверяют, а что нет — никто не знает. Нам нужно проверить регистрацию. А еще у нас есть 18 927 тестов. Если какой-то из них красный — «все хорошо», можно вернуть задачу к разработчикам — пусть разбираются. Если все тесты зеленые — это ничего не значит до тех пор, пока человек, отвечающий за ручное тестирование, не будет уверен, что из логики регистрации проверяется автоматически, а что все еще нужно проверить вручную. А тестов почти двадцать тысяч — в этом невозможно разобраться. Результат — проверить вручную нужно все.
Неудивительно что некоторые уходят из разработки продавать пластиковые окна, обучать бильярду или варить кофе (и это все реальные случаи).
О том, какие выводы мы в Wrike сделали из собственных и чужих ошибок, расскажу в следующем посте.
Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Ведущий оператор баш консоли 1 разряда
Комментарии (96)
powerman
07.02.2017 14:50+4Если подходить формально, то в статье, по большей части, всё верно. Но есть нюансы, которые очень значительно влияют на общее впечатление и финальные выводы.
Автоматические тесты надо уметь писать. Если тестировать немного не то и не так, то они, действительно, будут "хрупкими" (часто ломаться), на их разработку/поддержку будет уходить намного больше времени, польза от них будет сомнительна, и (с точки зрения менеджмента) затраты на их разработку действительно не будут окупаться. Но ровно то же самое касается и разработки кода: если нанять слабых разработчиков, которые пишут не тот код и не так, как надо — вместо фич будут только баги, разработка может занимать в разы больше времени, и затраты на неё не будут окупаться.
Без юнит-тестов мы запускаем в продакшн очень много кода, который никто никогда не запускал. Программист его "скомпилировал в голове" когда писал, но при ручном тестировании большая часть веток if-ов (и даже целых функций) ни разу не выполнялась. Особенно это касается кода обработки разных ошибок (сеть, БД, данные в некорректном формате, etc.). А, как известно из опыта, если код ни разу не запускали — как правило он корректно работать не будет.
Преимущества автоматических тестов
Не упомянута ещё несколько очень важных преимуществ.
Наличие автоматизированных тестов очень сильно ускоряет добавление новых фич и рефакторинг — вместо того, чтобы тратить время на попытку продумать и оценить последствия изменения кода можно его просто изменить и запустить тесты, если они проходят, то с высокой вероятностью эти изменения ничего не поломали (при наличии адекватных тестов, которые ещё нужно уметь писать, разумеется).
Автоматизированные тесты очень сильно упрощают тестирование в разных окружениях — с разными версиями OS, библиотек, кросс-платформенное тестирование.
Причина в том, что проверить изменение руками гораздо быстрее, чем автоматизировать тот же тест.
Очевидно, если это изменение руками тестируется уже в 3-5-й раз, то к этому моменту написать автоматизированный тест было бы быстрее.
В каждый отдельный момент, решая что выгоднее, писать тесты или не писать, второе всегда предпочтительнее.
Это не так, из-за упущенного Вами и упомянутого мной выше преимущества автотестов — их наличие сильно ускоряет внесение (качественных и работающих, наверное стоит добавить) изменений в код.
Ситуация в корне меняется в длительной перспективе.
Проблема в том, что если не писать тесты с самого начала, то начать их писать на более поздних этапах будет намного сложнее и дороже. Одна из причин этого чисто техническая — для того, чтобы тесты было возможно написать нужно чтобы код приложения был специально адаптирован под тестирование, что означает необходимость дополнительного рефакторинга кода (а иногда и архитектуры) если код изначально не писался с учётом необходимости его тестировать (а ещё давно замечено, что архитектура и код заметно улучшаются когда пишутся с учётом тестирования, и это ещё одна причина почему тесты стоит писать с самого начала). Другая причина чисто психологическая — тесты писать значительно менее приятно, чем основной код, поэтому когда возникает задача "у нас есть 100500 строк кода без тестов, надо покрыть их тестами" — руки просто опускаются, плюс всегда и у разработчиков и у менеджмента возникает вредная и некорректная мыслишка "до сих пор ведь всё работало без тестов, значит они особо и не нужны". Всё это сильно убивает и мотивацию, и продуктивность.
В результате экономить на написании тестов имеет смысл только если пишется какой-то реально одноразовый код, который никто и никогда не будет запускать в продакшне.
И замедляем не на 10%, а вдвое, втрое или даже больше.
Если тестировать то, что нужно, и так, как нужно — на тесты уходит примерно столько же времени, сколько и на код. Т.е. формально разработка замедляется вдвое, но это не учитывает вышеупомянутый фактор ускорения разработки благодаря наличию автотестов, а он начинает заметно сказываться на более поздних этапах, когда из-за увеличения общей сложности приложения скорость внесения изменений при отсутствии автотестов очень сильно падает. Если же на автотесты в среднем тратится вдвое больше времени чем на код — это хороший признак того, что скорее всего вы что-то не то или не так тестируете.
Но не все так просто.
Половина описанных в выводах статьи проблем связана скорее с неумением писать тесты, нежели объективными проблемами.
kentastik
07.02.2017 15:19-1это жисть, а у вас идеальный мир, которого не существует.
powerman
07.02.2017 15:43+5Каждый сам выбирает мир, в котором ему жить.
Безусловно, существует много проектов, в которых автотесты никто не пишет. И коммерческий успех или провал проекта вряд ли зависит от наличия или отсутствия автотестов — по крайней мере я такой зависимости пока не замечал. Так что я не пытаюсь сказать, что автотесты это серебрянная пуля и мастхэв, и без них никуда — если вдруг Вы поняли мой комментарий в этом ключе.
Я писал про то, что разработка автотестов — это отдельный навык, которому нужно отдельно учиться, как учат новые языки, фреймворки и парадигмы программирования (причём это в равной степени касается и крутых гуру/стар-разработчиков и всех остальных). И что большая часть проблем, с которыми сталкиваются при написании автотестов, вызвана не автотестами как таковыми, а неумением их писать (что включает и умение адаптировать архитектуру и код проекта под нужды тестирования).
algot
07.02.2017 22:28>>начинает заметно сказываться на более поздних этапах, когда из-за увеличения общей сложности приложения скорость внесения изменений при отсутствии автотестов очень сильно падает.
В то же время очень сильно увеличивается время на переписывание существующих автотестов
dm_wrike
07.02.2017 22:29Спасибо за развернутый комментарий,
тонкость в том что неумение писать тесты это тоже объективная проблема.
7veta
07.02.2017 14:52Стоит еще добавить пункты, описывающие для кого делаются эти тесты. Почему делаются тесты для разработчиков и почему тесты реализовываются для конечного продукта. Про бенчмарки как исторический этап и тд. для полного раскрытия темы… ну на 90% )
Blumfontein
07.02.2017 15:04+2Разработчики делятся на 2 категории: которые не пишут тесты и которые уже пишут тесты.
Shtucer
07.02.2017 15:06+2Точность — автоматические тесты проверяют ровно то, что описано в сценарии, во всех деталях и мелочах. Они не отвлекаются, не путают и не забывают.
Если бы ещё и сценарии писались бы точно, во всех деталях и мелочах, неутомимой машиной.
Comdiv
08.02.2017 19:15В этом направлении есть определённые подвижки, например, property based testing.
apelserg
07.02.2017 16:24+1Вам надо протестировать формы в системе (Win-GUI, Web-GUI — не важно).
Проверить:
— штатную функциональность (типовое НСИ);
— защиту от дурака (не ту кнопку нажали);
— нагрузку (по данным и/или по юзерам);
Таких форм много (в корпоративных системах десятки и сотни).
Ваши конкретные предложения по автоматическому тестированию?dmitry_dvm
07.02.2017 17:30Нагрузку проверяет нагрузочное тестирование, оно ни к авто, ни к ручному особого отношения не имеет.
Штатное поведение как раз проще всего автоматизировать, особенно если UI не особо часто меняется. Тут важна стандартизация разработки — например, у каждого важного элемента должен быть уникальный, не меняющийся id. При таком раскладе можно написать один раз пачку тестов на селениуме (или CodedUITests в случае Win) и жить спокойно. А защита от дурака это уже негативные кейсы, их так же можно автоматизировать, как и штатное поведение, но уже с более низким приоритетом.apelserg
07.02.2017 18:13Нагрузку проверяет нагрузочное тестирование, оно ни к авто, ни к ручному особого отношения не имеет.
Вы меня заинтриговали (извините за сарказм), как же оно выполняется (или кем)? В вашем контексте «нагрузочное тестирование» это субъект, программа, технология или что?
у каждого важного элемента должен быть уникальный, не меняющийся id
О каком «важном элементе» идёт речь в данном контексте, кто и на каком этапе задаёт id, как гарантируется уникальность?
При таком раскладе можно написать один раз пачку тестов на селениуме
Тесты на селениуме? Очень интересно. А конкретный пример теста можно? Что-нибудь простое, например типа регистрации нового пользователя.
Skerrigan
08.02.2017 03:40Тесты на селениуме? Очень интересно. А конкретный пример теста можно? Что-нибудь простое, например типа регистрации нового пользователя.
Пример
apelserg
08.02.2017 13:24Спасибо.
А как быть в случае, если баг проявляется в процессе взаимодействия пользователя с формой.
Например — пользователь с таким именем уже зарегистрирован в системе.
Или — пароль не прошёл валидацию на сложность.
Или просто произошла ошибка при сохранении данных.
Сможет ли автоматический тест решать такие задачи?
imps
08.02.2017 20:07Если такой автоматический тест был спроектирован, то имплементировать такой тест не сложнее чем любой другой(автотест). Этот вопрос скорее о квалификации тестировщика составлявшего список тест-кейсов.
Skerrigan
09.02.2017 06:16Ок, понимаю, что мой код вам не понятен.
Пояснения: это не просто «селениум» и «тесты». Это полноценная АСТ (автоматизированная система тестирования). Она сложная и модульная (Микроядра->ядро->модули->тесты).
На скриншоте пример как раз модуля. Тест делает вызовы модулей. Модули делают обращения к подсистемам ядра. И вот уже в методах ядра идет вся «магия».
Если поле ввода не сработало по какой либо причине, то это будет зарегистрировано и занесено в лог.
Если пароль не прошел валидацию на сложность или данные внесены как-либо иначе не верно, то уже смотрим логику модуля, что отвечает за к примеру систему регистрации юзера на сайте — если это не допустимо, то тест рассчитывает на «не сохраняемость» этого юзера. И, в случае отказа, пишет что тест прошел верно. Если же юзер будет сохранен вопреки всему, то будет в отчетах указание соответствующей ошибки.
В довесок: если есть не критичные баги, то тест не будет завален, а АСТ будет пытаться продолжить выполнение проверок дальше (пример: нужно сделать проверку товара в каталоге… дата не сохранилась. На дальнейшие тесты влияет минимально — тестирование будет продолжено по веткам сценариев без аварийного завершения прогона).
Поэтому, подводя итоги — мы (качественные автоматизаторы) можем очень многое.apelserg
09.02.2017 11:27мы (качественные автоматизаторы) можем очень многое
Статью с таким названием я бы хотел прочитать.
А как быть, если просто нужен «качественный автоматизатор» тестов — какие к нему должны быть требования по скилам?Skerrigan
09.02.2017 11:50Статью с таким названием я бы хотел прочитать.
Уже 2 года как хочу ее написать. Однако есть два тормоза (время на это я нашел бы любой ценой как говорится):
Важный — разработка обошлась в серьезную сумму, много нервов и времени. Это закрытая информация.
Не важный — по-любому нахватаюсь кучу негатива в свой адрес, т.к. ПО явно не в мейнстримовом духе. Много не оптимального. Да и «временных» решений достаточно, чтобы хабраюзеры закидали камнями.
требования по скилам?
Был поваром в кафе. Потом работал программистом в университете. Через пол года работы там жизнь меня перекинула в текущую фирму. Пришел на собеседование. Вакансия была на php-программиста. Взяли, потом, на следующий день, сказали что буду тестировщиком. Через неделю-другую у меня от этого крыша поехала (ручное тестирование… при том, что я совсем не хотел этим заниматься). Предложил руководству автоматизировать. Мне встречно дали запрос «подготовить смету по этому делу» (как по деньгам/времени, так и по технологиям). Оказалось, что писать придется под java, которую я первый раз в жизни увидел. Сказал, что «смогу». Дали «добро». Через год АСТ v1 заработала.apelserg
09.02.2017 12:27Сказал, что «смогу». Дали «добро». Через год АСТ v1 заработала.
Сказал и сделал — вероятно это и есть самый главный скилл в любом деле. Спасибо, записал себе в ноут.
Да и «временных» решений достаточно, чтобы хабраюзеры закидали камнями.
Уверен, у вас получится. По-крайней мере, стоит попробовать.
dmitry_dvm
08.02.2017 13:09Таки да, нагрузочное тестирование это отдельная ветвь тестирования, выполняется специальными программами типа JMeter. Пишется сценарий нагрузки или скармливаются логи реального сервера, запускается и начинается плавное увеличение нагрузки. Параллельно отслеживаются параметры нагружаемого приложения (загрузка цп, очередь к базе, время отклика итп). Обнаруживаются бутылочные горлышки и допиливаются, пока не будет достигнута стабильная работа тестируемого приложения при максимальной требуемой по ТЗ нагрузке.
Важными элементами называю элементы, с которыми может взаимодействовать юзер (в т.ч. виртуальный) — это кнопки, чекбоксы, текстбоксы и т.п. Уникальные id им может задавать разработчик, а может и платформа, насколько я знаю (я не вебдев). Уникальность нужна в пределах одной страницы/окна. И гарантироваться должна разработчиком.
dm_wrike
07.02.2017 22:35+1Предложения:
1. Выявить проблемы
2. Определить возможные решения
3. Выбрать из возможных решений целесообразные
4. Воплотить!
P.S. Понимаю что мой ответ вас не устроит ;)apelserg
08.02.2017 13:02+1P.S. Понимаю что мой ответ вас не устроит ;)
Дело не во мне. В статье затронута действительно актуальная тема, с которой, в той или иной степени, сталкиваются все компании-разработчики ПО. Я стараюсь задавать «уточняющие» и «наводящие» вопросы, которые позволят лучше раскрыть тему. Судя по статье — у вас есть успешный опыт атоматического тестирования.
Например, в компании, где я работаю, схема примерно такая: после этапа первичной разработки (разработка обычно ведётся на основании требований) составляется ПМИ, которое передаётся тестировщикам (их несколько человек и у них нет навыков разработки, но им приходится иметь дело с прикладной областью). Тестировщики пишут баг-репорты, которые исправляются. И так до устранения всех проблем. В общем-то ничего нового.
Обеспечивая качественное покрытие кода приложения тестами мы одновременно замедляем разработку как таковую. И замедляем не на 10%, а вдвое, втрое или даже больше.
Переход на автоматическое тестирование у нас тормознул, в том числе, и по этой причине.
И дело не только во времени. Нужны ещё дополнительные ресурсы (разработчики со спец. навыками) для разработки тестов. Но тесты покрывают далеко не все задачи тестирования. В итоге, стоимость и сроки разработки растут, а без ручного тестирования всё-равно не обойтись.Skerrigan
09.02.2017 12:02Но тесты покрывают далеко не все задачи тестирования
Согласен. Однако качественная платформа может дать очень жирный кусок. У нас примерно 80% функциональных тест-кейсов покрыто.
При этом создание/редактирование/удаление данных в основном нашем продукте (да, это CMS|CRM) покрыты на ~95-98%.
Тесты понимают работу с почтой, парсинг писем. Умеют в drag&drop. Читать консоль браузера и собирать js-ошибки из нее, записывая в лог.
а без ручного тестирования всё-равно не обойтись
Увы да, в одну каску тянуть разработку особо-изощренных тест-кейсов как лениво, так и сил нету. Поэтому что-то руками проверяется даже если это можно (и по хорошему нужно) автоматизировать.
dm_wrike
10.02.2017 02:36Судя по статье — у вас есть успешный опыт атоматического тестирования.
Неудачный опыт тоже есть :)
Если серьезно, легко дать совет вида «пишите Unit-тесты!». К сожалению вам это вряд ли поможет если не навредит.
Говорить о каком то решении со стороны, не понимая специфики вашей работы, ваших ограничений, в ваших трудностей было бы неосмотрительно.
Вы говорите о ряде проблем:
1. Разработка тестов отнимает время — можете ли вы сократить накладные расходы при этом сохранив пользу от тестов?
2. Нужны разработчики со спец навыками — зачем они нужны? можете ли вы обучить имеющихся разработчиков? можете ли вы нанять необходимых разработчиков?
3. Тесты покрывают не все задачи — какие покрывают а какие нет? есть ли смысл связываться с тестированием ради проверки тех задач которые можно ими проверить? можно ли расширить область действия тестов?
Попробуйте задать себе вопросы в этом роде и подумайте как можно на них ответить.
Лучшее решение ваших проблем можете найти только вы сами.
rmpl
08.02.2017 12:19Первые 2 пункта проверяются легко – Selenium-тестами :)
Нагрузка проверяется JMeter'ом (помимо него инструментов достаточно, тот же питоновый Locust например).
А больше всего мне интересно, как вы будете нагрузку в разрезе огромного количества юзеров тестировать руками.apelserg
08.02.2017 13:34Мне известны примеры, когда в тестировании участвуют десятки тестировщиков. Сейчас эта тема вполне актуальна, когда речь идёт о важной системе в солидной компании.
rmpl
08.02.2017 13:39Если ни один из этих десятков тестировщиков не может настроить JMeter который эмулирует нагрузку в миллионы пользователей – вопрос, стоит ли вообще работать в такой «солидной компании».
apelserg
08.02.2017 14:08Для выявления некоторых (самых неприятных) багов, иногда бывает нужно смоделировать не просто нагрузку, а сложный прикладной поведенческий тест. Для этого приходится вникать и в прикладную область и разрабатывать мудрёные алгоритмы.
PS А вы всерьёз думали, что эти несчастные долбят как мартышки по клавишам?rmpl
08.02.2017 16:02Я вот даже и не пойму, вы троллите или серьезно пишете :)
Ну да, нагрузку можно по-разному моделировать, по сценариям – тоже можно. А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю. Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).apelserg
08.02.2017 16:50+1А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю.
Если вы имеете в виду — смоделировать нагрузочный тест как примитивную DDOS-атаку, то да — это будет делать скрипт.
Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).
Поведенческие тесты нужны тогда, когда надо выявить, например, скрытую/плавающую ошибку. Разработать, провести такой тест и получить положительный результат (выявить причину проблемы) — большая работа. В каждом конкретном случае такие тесты уникальны.
Кстати, сейчас востребованы услуги по тестированию ПО, которые предоставляются по схеме аутсоурсинга. Мне известна одна такая фирма. В штате у неё несколько десятков тестировщиков (с разными проф. навыками). У неё всегда есть заказы, а услуги далеко не всем по-карману.rmpl
08.02.2017 19:02Интересно :) Мне всегда казалось, что тестирование отдельно от разработки не продать.
apelserg
08.02.2017 19:25Мне всегда казалось, что тестирование отдельно от разработки не продать.
Отлично продаётся. Главные потребители — банки и корпорации. У них сейчас сенокосная пора на мобильную разработку. А свой штат тестировщиков держать на окладе — зачем? Тестировщики востребованы только по мере появления нового ПО (и собственной и сторонней разработки).rmpl
09.02.2017 11:56Все передовые банки давно перешли на Agile, где тестировщик – неотъемлемая часть команды любой разработки. Отдельно сидящие тестировщики – это архаизм :)
apelserg
09.02.2017 12:58Отдельно сидящие тестировщики – это архаизм :)
Качественное тестирование может обеспечить только внешняя, неаффелированная команда (это из области психологии — почему так, учёные пока объяснить не могут).
Тестировать надо (в солидных компаниях, которые привыкли заботиться о своей репутации) не только собственные разработки, но и любые ПО-продукты, которые там внедряют.rmpl
09.02.2017 13:15У меня был опыт работы во внешней команде, есть опыт разработки в команде с разработчиками – так вот скорость и качество разработки во втором случае это небо и земля. Внешняя команда играет в пинг-понг с разработчиками и не имеет общих интересов.
apelserg
09.02.2017 13:43У каждой компании свои цели, мотивация и представления о расходах и качестве ПО.
Тестировщики, о которых вы говорите — входят в обязательный штат современной компании-разработчика ПО.
Внешнее тестировщики нужны, когда компания не хочет, чтобы её 100500 клиентов выступили в качестве тестировщиков.
Для внешнего тестирования отлично подходит аутсоурсинговая компания.
imps
08.02.2017 20:24+1Нагрузочное тестирование это отдельный пласт стэков технологий/решений, так что вполне ожидаемо, что для реализации этого вида тестирования нужны соответствующие специалисты.
Дать задачу автоматизатору написать простой нагрузочный скрипт конечно можно и большинство с задачей, я думаю, справятся.
Вот только правильно интерпретировать NFE(Non-Functional requirements) заказчика, с учетом контекста разрабатываемого решения(читай вникнуть в архитектуру, разобраться, вычислить потенциальные bottle-neck`и) может только опытный и квалифицированный человек.
Кроме того в нагрузочном тестировании существует своя специфика подходов, методологий и т.д.
И для полноценного нагрузочного тестирования, нужен человек, который понимает эту специфику и желательно имеет опыт работы с ней.
Мне казалось очевидным, что различные виды тестирования имеют свой набор специалистов.
Правда стоит отметить что это утверждение распостраняется не на все виды тестирования.
Fen1kz
07.02.2017 16:38-1Аутентичность — большинство приложений мы пишем для людей, и именно поэтому люди лучше всего подходят для их тестирования.
Не согласен. Мало того что очень много приложений являются приложениями для приложений, так ещё и даже если приложение для людей, то они все равно не очень подходят для тестирования, например, API.
Гибкость — ручное тестирование можно проводить гораздо разнообразнее, и изменение способа тестирования практически ничего не стоит. Давайте протестируем в Safari — пожалуйста, на Chromebook — нет проблем, IE6 — придется запустить виртуальную машину, но тоже можно.
То же самое! У автора приложения состоят из UI-only?
Выразительность — мало найти проблему на уровне “ничего не работает!”, важно правильно объяснить, в чем она заключается и уметь ответить на дополнительные вопросы разработчика. И в этом люди также лучше автоматических тестов.
Опять таки, не всегда. Вот не работает API метод с такими-то параметрами. И человек и автотест предоставят только параметры и стектрейс, все.
Ограничивают рефакторинг. Тесты тоже нужно рефакторить, даже если бизнес-логика не меняется, и в коде происходят лишь косметические изменения. Это может привести к тому что нужно поправить 5 мест в основном коде и еще 80 в тестах. Каждый в такой ситуации задумается: а стоит ли делать что-то большее, чем переименование метода.
Тащем-то наоборот. Когда у тебя не мелкий проект, то рефакторинг без тестов — самоубийство. Обычно оставляют как есть и потом переписывают проект полностью. О том чтобы зарефакторить какой-нибудь core сервис и речи быть не может. С тестами все куда лучше.
Сизифов труд
тут вообще бред, если ты рефакторишь код, тебе не надо рефакторить много тестов by definition
Количество тестов обманчиво
1000 ситуаций это уже уделывает людей подчистую
В общем, какое-то мнение UI тестировщика.
Ведущий оператор баш консоли 1 разряда
А, ну или так, да.
jetcar
07.02.2017 17:41тесты это своего рода компилятор для логики, без тестов любое изменение чревато проблемами, да они всё не проверят, чтото могут пропустить где-то лишний раз ругнуться, но аутомейшен тестеры это теже девелоперы и уже много где получают не меньше, так что качество тестов зависят от их профессионализма
в конце концов чтоб если тестер тестит руками может заодно и тест написать, если тестер как девелопер не очень то можно дать ревью тестов делать девелоперам
Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю — 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.
это вообще смешно, измерять можно покрытие логики тестами, а не сколько времени что-то тестировалиy90a19
07.02.2017 17:55без тестов любое изменение чревато проблемами
с тестами любое изменение становятся проблемой. И тесты не бесплатныjetcar
07.02.2017 18:08не могу себе представить варианта где тесты могут стать проблемой, разве что для «эффективного» менеджера который обещал релиз через пару дней, а писать тесты займёт 3 дня
если изменение требует переписать кучу тестов, наверно это огромное изменение либо тесты как-то очень не эффективно написаны и это не вина тестов
dm_wrike
07.02.2017 22:42Вы слишком абстрактно смотрите на тестирование,
тестирование это исключительно прикладная область.
На эту тему есть отличная книга Perfect Software от Gerald M. Weinberg.
jetcar
08.02.2017 10:23удачи вам в разработке с таким подходом, тестирование это обязательная часть процесса, кроме тех случаев где нужна только красивая картинка и можно свалить оставив всё без поддержки
y90a19
07.02.2017 17:49+1почему-то люди неосознанно ищут серебрянную пулю и даже административно вводят её (например 100% покрытие тестами обязательно).
В реальности же конечные требования известны только в космосе, медицине и военке. В остальных областях потребуется несколько раз всё переделать, прежде чем станут известны конечные требования и будут видны очертания результата.
И тесты очень сильно замедляют и удорожают эти изменения. Вместо быстрого прототипа люди пытаются делать решение на века со 100% покрытием. Даже если этого никому не нужно.
KReal
07.02.2017 18:08+1Могу рассказать свою историю. На нынешнюю работу я пришёл из аутсорса и всяких мелких проектиков, где без тестов жилось нормально (ну а в аутсорсе и вовсе гигантский штат QA это средство извлечения прибыли). Так вот, здесь бизнес-логика покрыта юнит- и интеграционными тестами (на 76%), есть UI тесты а-ля регрессия и приёмочные (сертификационные) UI тесты. В итоге разработке тесты не мешают и её не замедляют (падают по делу и до продакшена плохой код не доходит), а вручную тестируются только новые фичи (регрессии как таковой нет).
VMichael
07.02.2017 18:20+1Если было бы все очевидно, например нужно все покрывать тестами, однозначно, тогда не было бы холиваров на эту тему.
Везде, где выгода не очевидна, возникают дискуссии.
И вопрос покрытия тестами не очевиден.
Например, если при создании системы, обнаружилось, что она не очень то и нужна.
Попробовали, выкинули.
То при покрытии такого дела тестами, затраты удвоили.
И кому это надо?
Или стартап.
Если все покрывать тестами, то, как вариант, конечно, можно не дожить до момента, когда заработает твой генератор денег и обанкротиться.
Т.е. жизнь вариативна.
Считать нужно всегда.
А статья классная, автор — молодец.apelserg
07.02.2017 18:35+1Статья написана в разделе «разработка». Логично было бы предположить, что будет раскрыта тема разработки автоматических тестов на примерах.
dadyjo
07.02.2017 18:52Вопрос быть автотестам или не быть, это вопрос оценки рисков потерь связанных с работой тестируемого ПО.
Если от этого ПО зависит работа на марсохода или работа банковской системы то явно что автотесты жизненно необходимы. Но если программой пользуется десяток другой человек, есть бэкапы и пользователь сообщит об ошибках если с ними столкнется то с написанием автотестов будет связываться только отъявленный перфекционист :)
viru0
07.02.2017 18:54+3Работал в конторе где оптимизировали.
'Исправляя проблемы быстро, можно добиться гораздо более высокого качества продукта, '
Добились времени решение любой проблемы — менее одного бизнес дня.
Качество продукта было космическим.
Тестов в классическом понимании не было совсем. Были так называемые мониторинг тесты.
Любая функциональность пушит метрики в систему анализа. +Устанавливается система алертинга
(Что то не происходило в течении часа -> приводит к вызову программиста который на дежурстве)
+На продакшене постоянно крутились скрипты которые кликали сайт в браузере через web driver и тоже пушили метрики (Поэтому все им доверяли ибо если один пробег скрипта не прошел это не приводило к alerts. И качество их могло быть вполне себе 'на скорую руку')
Все это(метрики) также использовались дизайнерами чтобы понимать какой UX оптимизировать.
(Мы видим 1000 событий заполнил поле email но только 10 заполнил поле lastName -> давайте удалим этот lastName к чертям, людям все равно не нравится)
Обращение к customer support тоже было метрикой, так что если вдруг полетели заявки больше обычного — вот тебе и alert и программист сидит разбирается что почему.
Все это реально работало, при этом не требовало 100% покрытия, идеальных тестов и.т.п.snowglobe
08.02.2017 19:16Это по сути пользователи за вас делали тесты.
viru0
09.02.2017 18:39Не, ну стандартный тестировщик у нас тоже был. Прежде чем от stage к prod перейти, человек все таки проверял что оно работает.
Просто за место: «О а давайте покроем все возможные сценарии тестами и потратим кучу времени на это.»
Было: «Так этот кусок программы должен приводить к рассылки инвайтов. Давайте пушить когда пользователь кликнул на кнопку и запишем если API ответит с ошибкой.»
Уходило на это час. И уверенность в качестве было.azShoo
14.02.2017 18:42Уверенность в качестве это когда вы знаете, что API не ответит ошибкой при нормальном user flow.
То, о чём вы говорите — это уверенность в возможности быстро локализовать проблему.
Проблема «мониторинговых» тестов в том, что они алертят постфактум. Т.е. вы узнаете о проблеме только тогда, когда N пользователей вместо ожидаемого результата получат хрен.
Более того, в случае новой функциональности и всяких изощренных юсабилити экспериментов всё ещё сложнее — вы не всегда можете понять, то ли UX эксперимент не удался и конверсия просела, то ли пользователь не видит кнопку сабмита формы (условно) и уходит нахрен.
Пока вы это выясняете — пользователи испытывают баттхёрт. И вы их теряете (при условии, конечно, что у них есть альтернатива, но если её нет — можно и вообще не париться, и так схавают).
nizkopal
07.02.2017 19:16+1Вот еще один плюс автотестов в копилку — они хороши, когда разработчик сам может их запустить на своей ветке. Он найдет регрессионный баг (т.е. увидит, что сломал что-то до него работающее), не вовлекая в процесс и не отнимая время у тестировщика, который найдет тот же баг, но руками и позднее, релиз инженера, который будет заниматься выкладкой этой задачи на препродакш, второго разработчика, который будет делать ревью кода и всех остальных в зависимости от того вашего флоу.
И того один человек написал тест и сэкономил время нескольким коллегам. :)
funca
07.02.2017 23:55+1Ну не все так однозначно, тут тоже придется считать. Ведь время, которое потратит разработчик на тестирование, и соответственно не-писание новых нужных бизнесу фич, стоит вполне конкретных денег, которые могут быть больше или меньше затрат на тестировщика и всю эту остальную веселую компанию. Отдельные регрессионные тесты могут выполняться целую вечность, а для запуска других, порой, приходится ждать наступления определенной фазы (нет, не луны, а готовности других компонентов). Как бы то ни было, в порочном круге Software Release Life Cycle всему найдется свое место и свое время.
wert_lex
08.02.2017 12:50Стойте-стойте. А как же качество продукта? Или у вас производительность программиста исчисляется не в числе решенный задач, а в строках кода, которые он написал?
Задача программиста не писать код, а решать поставленные задачи с помощью написания кода. Как программист должен узнать, что задача решена и решена корректно, если у него нет инструмента проверки валидности логики?
Код, который запускается это далеко не тот же самый код, который работает корректно. Даже если вы пишете на Haskell и Scala.
funca
09.02.2017 00:40Код, который работает корректно, это не всегда тот, код, который делает то, что нужно, и так как нужно. QA это комплексная проблема, которая решается только в комплексе.
Все заранее известно и разработка сводится к программированию лишь на уроках информатики. На практике приходится иметь дело с большим разнообразием функциональных и не функциональных требований, кроме валидности логики, прежде чем сдавать работу.
И потом, не стоит сбрасывать со счетов банальный человеческий фактор. Два глаза хорошо, а четыре еще лучше. :)
guai
07.02.2017 19:54Сколько ни читал статей про тестирование, в каждой тестируется helloWorld, а потом: «всё, дальше должно быть и ежу понятно, дерзай» :)
choo-joykin
07.02.2017 21:02+1особенно трудно, когда ручной тестировщик не понимает зачем ему нужно писать кейсы на автоматизацию проверок и зачем вообще нужны автотесты, ведь можно ручками все проверить!
osiraben
07.02.2017 21:02Вот это преимущество автоматизированного тестирования
Всеобъемлемость — автоматические тесты позволяют покрыть огромное количество сценариев и находить наведенные ошибки в таких далеких углах приложения, до которых ручной тестировщик никогда бы не добрался, кроме как случайно.
и это преимущество ручного
Креативность — ручное тестирование позволяет найти проблемы, которые заранее не были известны, более того, даже не подразумевались.
одно и то же.dm_wrike
07.02.2017 22:53Нет, автоматические тесты проверят то что заранее было запланировано проверить.
При ручном тестировании можно сообразить проверить то что никогда раньше не проверялось потому что никто об этом не думал раньше.
В этом разница.
Shustrik_N
07.02.2017 21:02+2Последний абзац крайне странный.
Все потому что автоматические тесты… что конкретно они проверяют, а что нет — никто не знает.
Как такое возможно? QA написавший тест всегда знает о чем он, если он уже покинул команду — есть description, как-минимум. В противном случае нет никакого смысла запускать какой-либо тест, если нет возможности проанализировать результат, неизвестно тест всегда проходит потому что эта фича работает корректно, или этот тест сломан и всегда дает положительный результат.
А еще у нас есть 18 927 тестов. Если какой-то из них красный — «все хорошо», можно вернуть задачу к разработчикам
Если у вас тестировщик без комментариев реджектит тикет потому что «упал какой-то тест из какого-то тест-комплекта», не конкретизируя какой и ему за это ничего не будет — совершенно непонятно как у вас происходит разработка в принципе. Тестировали авторизацию, упал тест на отображение календарика — тестировщик реджектит тикет авторизации, так что ли?
А тестов почти двадцать тысяч — в этом невозможно разобраться. Результат — проверить вручную нужно все.
Зачем было создавать 20 тысяч? Если они достались по-наследству, то зачем вообще тратить время их запускать, никто не понимает о чем эти тесты и не понимает в результатах тестирования, зачем такое тестирование? Возможно все ваши 20 тысяч давно сломаны и выдают положительный результат, вне зависимости от того есть баг или нет.
Автоматизация призвана избавить manual QA от рутинной работы, если какая-то фича устоялась, живет много релизов подряд ее надо автоматизировать, в противном случае вынуждая тестировщиков руками проверять продукт каждый раз, их внимание просто рассеивается и на 5й регресс они ничего не видят.Vkuvaev
07.02.2017 21:40+1Плюс поставить не могу, но хотел бы.
Статья поначалу затянула, а в конце удивила.
Возникло ощущение, что все в кашу. Обычно регрессионное тестирование и ручное происходят из единого описания сценариев тестирования. Тут нельзя спутать, какой сценарий не прошел. Если подходить системно, то картинка вся должна быть на виду. Автотест не прошел? Повторяем сценарий руками. По контексту ошибки и ручного прогона поймем что делать дальше.
А если как-то появилась толпа автотестов и они с ручным тестированием непонятно как пересекаются, то пора задуматься об управлении тестированием как процессе.dm_wrike
07.02.2017 23:05Обычно регрессионное тестирование и ручное происходят из единого описания сценариев тестирования.
Хорошо если регрессионное и ручное тестирование идyт из одного источника,
но это далеко не всегда так.
Возможно вы привыкли к хорошему :)
dm_wrike
07.02.2017 22:59Как такое возможно? QA написавший тест всегда знает о чем он, если он уже покинул команду — есть description
Вы подразумеваете что тесты достаточно хорошо документированы и структурированы — в реальности это не всегда так.
Если у вас тестировщик без комментариев реджектит тикет потому что «упал какой-то тест
По хорошему, задача не должна доходить до ручного тестирования если есть упавшие тесты.
Это элемент культуры разработки, проявление разработчиком уважения к труду ручного тестировщка.
Зачем было создавать 20 тысяч?
Хороший вопрос! Но, мне кажется, не все задают его себе прежде чем написать 20 тысяч тестов :)
speller
07.02.2017 21:03Что касается:
нужно поправить 5 мест в основном коде и еще 80 в тестах
То для того, чтобы такого не было, нужно дробить огромные методы с убер-логикой на маленькие логически оформленные блоки (методы). Тогда каждый блок кода можно протестировать отдельно, и изменение одной строчки в убер-методе не приведет к необходимости переписывать 80 тестов.y90a19
10.02.2017 09:33и в случае какой-то мажорной правки придется выкидывать все эти 100500 маленьких оформленных блоков
speller
10.02.2017 10:20А какая разница, что выкидывать — 100500 мелких блоков, или один большой, если надо выкидывать? А вот когда у вас есть метод на 200 строк кода, и вы вносите два изменения в начале и в конце — вам придется внести изменения во все 20 тестов, т.к. тестом покрыт весь метод от и до. Если в каждом из двух мелких изменений нужно проверить по 3 варианта развития событий, то ваши 20 тестов превратятся сначала в 60 тестов, а потом ещё в 210. Чтобы проверить все варианты событий. И вот вам надо внести правку в третье место, где тоже надо отследить 3 варианта развития событий…
Что делать? Если ваш большой метод разбит на части, и все они покрыты 20-ю тестами изначально, то каждая правка принесет по +3 теста на конкретный отдельный блок. Т.е. 20+3+3 = 26 тестов. Есть разница — 26 тестов или 210? Грубые подсчеты, конечно, но отражают действительность. Сложность поддержки тестов на отдельный метод растет в экспоненциальной прогрессии от кол-ва строк в нем.y90a19
10.02.2017 16:23без проблем, можно каждый if поместить в отдельную функцию и тестировать её.
Количество кода от этого возрастет. Сложность тоже.
И в чем смысл писать тест на if? Проверять что глаза меня не обманывают? Что компилятор не сломался?speller
13.02.2017 05:48А я разве призывал каждый if выносить в отдельный метод и тестировать его? Это вы сами придумали и обвиняете меня в своих фантазиях. Это вы, а не я, придумал мифические 100500 методов. Если вы профан в грамотной структуризации кода и не понимаете, зачем нужны тесты, то не надо с такой примитивной позицией прыгать по комментами и строчить ахинею, пытаясь доказать неизвестно что.
bor33
07.02.2017 21:03+1повторю, сказанное vdasus 7 февраля 2017 в 14:13
+5
— Серебрянной пули нет
— Надо использовать инструменты там, где это разумно
— Надо правильно расставлять приоритеты
Автотесты нужны, в частности, при обнаружении эффекта накопления-тепла, зарядов,- что почти невозможно
обнаружить вручную,
особенно в процессорах графической, спектральной и т.д. обработки
PashaPash
07.02.2017 21:18+3Совершенно непонятно, о каких именно тестах написана статья. В тексте явно упоминается selenium, «вернуть задачу к разработчикам», хрупкость тестов при смене интерфейса, в преимущество ручных тестов вписана «гибкость» на примере тестирования в сафари. Т.е. вроде как речь об автоматизации работы QA.
И тут же, в ту же кучу — тесты до кода, правка тестов самими разработчиками, упоминания юнит тестов, «Тесты — такой же код» — т.е. явно не автоматизация работы QA, а именно юнит-тесты. Ну или в крайнем случае интеграционные. Юнит тесты призваны экономить время разработчиков. QA вообще не должно быть никакого дела до наличия или отсутствия юнит-тестов. Фраза «вернуть задачу к разработчикам при красном юнит тесте» — не имеет смысла — билд просто не должнен доходить до QA при красных юнит/интеграционных тестах.
Юнит-тесты — не альтернатива ручному тестированию. И, тем более, не аналог и не замена автоматизированному тестированию UI, вроде selenium. Это просто другой вид тестирования. А вы вписали в общий список все достоинства и все недостатки разных видов тестирования, даже тех, которые вообще в зону ответственности QA не входит. И перемешали. Не хватает только пунктов «selenium не умеет самостоятельно проводить penetration test-ы» и «юнит-тестами тяжело протестировать документацию» :)
С таким же успехом можно было расписать достоинства и недостатки JavaScript, достоинства .NET/Java, lua-скриптов, powershell, SQL, а потом перемешать это в один список «Блеск и нищета написания кода».
Т.е. вроде как была идея написать интересный противоречивый пост с интригой и открытой концовкой. Но выглядит так, как будто статью писал не лидер backend разработки, а маркетолог, которому выдали брошюру «разные виды тестирования для чайников» :(Vkuvaev
07.02.2017 21:45+1Ну кстати да, тут разные уровни и виды тестирования в кучу. Боюсь что проблема описанная в статье происходит от слабого понимания темы.
PashaPash
07.02.2017 21:57+1Скорее всего, у автора все в порядке с пониманием темы. Просто статья писалась ради второй части (которой пока нет), в которой смешанные в кучу виды тестирования разделят и разложат по полочкам.
dm_wrike
07.02.2017 23:21Вы зря делите полезность тестов для QA по технологическому признаку.
То что отдельная проверка реализована по принципам unit тестирования, а не как selenium тест,
совершенно не значит что такой тест будет не понятен и бесполезен QA. Может быть этот то что нужно.
Польза от теста ручному тестированию определяется не технологией использованной при
написании конкретного теста, а его осмысленностью и выразительностью.
Точно также, любой тест на любой технологии может быть написал плохо и создавать больше проблем чем приносить пользы.
Тесты это тесты.
билд просто не должнен доходить до QA при красных юнит/интеграционных тестах.
Конечно! Жалко не все так делают :)PashaPash
07.02.2017 23:45+1Я не делю тесты по полезности для QA — это вообще не имеет смысла. Тесты пишутся (или прогоняются, если они ручные) не ради QA. Они пишутся ради обеспечения качества продукта. За качество надо платить, в основном, временем разработчиков (кодеров и тестировщиков).
Но вот ваша статья не только делит полезность тестов для разработчиков по технологическому признаку. Вы прямо противопоставляете принципиально разные виды тестирования, и выдаете из этого целую статью.
По сравнению с ручным тестированием, автоматизированное имеет как достоинства так и явные недостатки
Точно так же можно написать статью о том, что «SQL по сравнению с JavaScript имеет как достоинства, так и явные недостатки», с кучей очень обоснованных доводов в пользу как SQL, так и JS.
rmpl
08.02.2017 12:52QA вообще не должно быть никакого дела до наличия или отсутствия юнит-тестов.
Вот это вот очень интересно :) А разработчик сам придумает все покрытие? Уметь писать код != уметь тестировать, а тестировать свое же еще сложнее. В идеале QA накидает кейсов, разработчик напишет юниты, QA их отревьюит/дополнит, и только после этого можно считать что ваш кусок тестами закрыт.PashaPash
08.02.2017 16:13+1Юнит-тесты (если они именно юнит, а не интеграционные) не пишутся по тесткейсам от QA. Юнит-тесты покрывают небольшие куски кода — отдельные методы, отдельные классы, отдельные вызовы в коде.
«SomeService при вызове SaveSomething, при условии что зависимость ISomeRepo вернет минимум 5 строк, в вызове GetSomeItems() заполнит поле SomeField у сохраняемого объекта значением SomeValue» — вот что проверяет юнит тест. Это просто проверка на наличие какого-то условия или какого-то вызова в коде.
QA обычно ничего не знаю о классах и об отдельных методах. Поэтому QA не может полноценно ревьювить и дополнять юнит-тесты. И дело не только в знании конкретного ЯП или фреймворка. Дело в том, что количество юнит тестов должно соответствовать количеству проверок и прочих методов принятия решений в коде. Собственно, в этом и состоит работа разработчика — переложить требования с человеческого (в виде User Story, документации, чего угодно) на язык if-ов и while-ов.
Современные языки программирования хорошо приспособлены для описания бизнес-логики. Они позволяют делать это гораздо компактнее русского или английского языков. Поэтому полноценное описание функционала (спецификация), если она действительно описывает весь функционал, должна несколько раз превышать по объему код приложения. А т.к. нет способов поддерживать и рефакторить текст спецификации с той же легкостью, что и код приложения — то написание такой «полноценной» спецификации должно занимать намного больше времени, чем написание кода. Именно поэтому все спецификации обычно далеки от полноты, и попытки «сгенерировать код по спеке» обречены на провал.
То же самое с тесткейсами для юнит-тестов. Их должно быть столько же, сколько проверок. Более того, написание кейсов для юнит-тестов QA, заранее, подразумевает что QA настолько хорошо представляет себе структуру приложения, что может точно сказать в каком методе, где именно и как именно будет написан каждый if. Если у вас QA так круты — то разработчики вам не нужны. Ну и объем таких тексткейсов будет точно так же превышать объем кода.
Поэтому да, для юнит-тестов разработчик сам придумывает покрытие. Точно так же, как он сам придумывает, где к коде написать if. И проверяют юнит-тесты именно наличие if-а или наличие вызова. Загораясь красным, когда кто-то лажанет при мерже, или неудачно подрефакторит. Или просто случайно выкосит проверку.
Те тесты, которые (иногда) пишутся по кейсам (или могут быть представлены в виде кейсов), по принципу один кейс — один тест — это или интеграционные или функциональные тесты. Т.е. это или selenium и прочие тыкалки интерфейса, тесты на всю систему в сборе (включая базу), или тесты «на бэкенд в сборе + базу».rmpl
08.02.2017 16:24Не смешивайте функциональные тест-кейсы от QA и кейсы, которые нужно проверить для отдельной функции и куска кода. Я про первые и не писал. Вы все правильно расписали про условные if и ветки и про их покрытие. Вопрос в том, что разработчик – человек, и может что-то забыть, а QA это увидит при код-ревью и подскажет. Или даст идей, что проверить. Или увидит, что тест ничего не проверяет на самом деле, или проверяет неправильно (и код работает неправильно). Затем и нужен. И да, QA должен хорошо знать приложение и код, чтобы уметь так делать.
PashaPash
08.02.2017 16:42+1Да, QA может подсказать. Но другие разработчкими справляются с этим намного лучше и быстрее. Т.е. гораздо эффективнее ввести peer code review (через те же пулл реквесты) и получить заодно повышение code ownership, чем надеятся что QA смогут что-то в коде увидеть, и тем более заранее написать кейсы на юнит-тесты (это вообще нереально в более-менее нетривиальном приложении).
rmpl
08.02.2017 17:05Да, это один из способов решения данной проблемы. Другие разработчики эффективны, но не всегда есть время :) а QA в идеале – такой же разработчик, который умеет писать код, только с экспертизой в тестировании. Если QA не пишет код и не знает кодовой базы, толку от него будет мало, это да.
red_ant
08.02.2017 19:17+1Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю — 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.
это вообще смешно, измерять можно покрытие логики тестами, а не сколько времени что-то тестировали
принцип Паретто никто не отменял еще. (потратив всего 20% времени на тестирование мы находим — 80% дефектов, и нужно потратить еще 80% времени чтобы найти оставшиеся 20% дефектов).
в принципе это аргумент в пользу ручного тестировария.
но в контексте итеративной модели разработки, когда релизится нужно каждые две недели — а время на регрессию — постоянно растет — трудно обойтись без автотестов (в противном случае тайм ту аркет увеличивается).
vlsinitsyn
08.02.2017 20:59Прихожу к выводу, что если у вас сразу много денег и план на 10 лет вперед по развитию продукта — то вкладывайтесь в автоматизацию тестирования.
Если у вас стартап, где важны быстрота выхода первой бетты или продукт типа сделал раз и забыл — то нет смысла тратить время.azShoo
14.02.2017 18:49У вас очень странные выводы.
Если у вас стартап, который требует динамичного развития, вы уверены, что у вас есть ресурсы гонять 5 часовую регрессию руками?
Если у вас стартап, который активно набирает обороты, уверены ли вы, что стоит жертвовать качеством ради ускорения релизов на 10-15% времени? (И, что важнее, так ли в этом уверены ваши пользователи?)
Во всём нужен баланс.
vdasus
Можно короче и универсальнее, как мне кажется:
— Серебрянной пули нет
— Надо использовать инструменты там, где это разумно
— Надо правильно расставлять приоритеты
Rastishka
Можно, но ваш коммент не убедит партнеров/руководство в принятии решения ЗА или ПРОТИВ автоматизированного решения. А эта статья убедит. Добавил в избранное.
vdasus
Мне кажется вам не повезло с партнерами/руководством, если набор очевидных истин явяется аргументом для принятия решения. В каждом случае надо анализировать что вам надо и готовы ли вы за это заплатить требуемую цену. От прочтения данной статьи очень мало у кого прояснится в мозгу, имхо.Не в обиду автору, я понимаю что написание статьи это труд, за который спасибо. "Человек быстрее реагирует на изменяющиеся параметры, а автомат тестирует не уставая". [irony]Ну так-то — да.[/irony]