Мы тратим больше времени на внедрение функционального тестирования, чем на внедрение самой системы, это нормально?

12

По сути, у нас есть три основных проекта, два из которых являются веб-сервисами, а другой - веб-приложением. В то время как я удовлетворен тем, что мы максимально покрываем наши веб-сервисы функциональными тестами (все три проекта имеют свои собственные модульные тесты), функциональные тесты для веб-приложения занимают много времени для реализации. Под многим я имею в виду два раза, а иногда и больше, время, которое требуется для реализации тестируемой функциональности с включенным модульным тестированием.

Политика менеджера заключается в тестировании каждой добавляемой нами функциональности, даже если это не критично для бизнеса (например, новый CRUD).

Я согласен с тестированием всех функциональных возможностей веб-сервисов, потому что тестировать их вручную сложно, а также эти тесты выполняются быстро и не требуют особых усилий для реализации.

Итак, в чем смысл тратить больше времени на написание функциональных тестов, чем на написание системного кода, модульных тестов и исправлений тестов QA? Это нормально? Разве мы не должны писать функциональные тесты только для критической функциональности и позволять QA проводить регрессионные тесты без критической функциональности?

Примечание: мы не разрабатываем медицинское программное обеспечение или программное обеспечение НАСА или что-либо столь критическое.

Пабло ласкано
источник
14
У нас нет тестов. Мы тратим огромное количество времени, чтобы исправить вещи после факта. «Вы можете заплатить мне сейчас, или вы можете заплатить мне позже». Это позже, и это не красиво.
MetalMikester
3
Да, часть картины определенно состоит в том, что хорошо поддерживаемый набор тестов уменьшает время, необходимое для фактической реализации.
Майкл Боргвардт

Ответы:

16

Функциональные тесты очень важны. Да, им нужно время, чтобы написать, но если вы пишете правильные функциональные тесты, они того стоят.

Есть несколько веских причин для проведения автоматических функциональных тестов в приложении.

  • Когда новая функция добавляется на ваш веб-сайт, она сразу дает вам знать, нарушают ли изменения, сделанные для этой новой функции, какие-либо другие функции на вашем сайте.
  • Это документированное знание того, как приложение работает и работает вместе для достижения бизнес-требований.
  • Когда пришло время обновить стороннюю библиотеку, вы можете обновить ее и запустить свой функциональный набор тестов, чтобы увидеть, что-то не работает. Вместо того, чтобы просматривать каждую страницу самостоятельно, вы можете попросить компьютер сделать это за вас и предоставить список всех пройденных тестов.
  • Нагрузочное тестирование! Вы можете смоделировать тысячи одновременных пользователей, одновременно попадающих на ваш сайт, и вы можете увидеть, где ваш сайт замедляется и сжимается под давлением. Вы можете увидеть, как ваш веб-сайт ведет себя задолго до того, как вы получили поздний ночной звонок о том, что сайт рухнул.
  • Функциональное тестирование требует времени, чтобы сделать вручную. Да, для написания кейсов требуется много времени, но если вам пришлось сесть с переплетом с 500 страницами тестов, которые вам пришлось пройти, прежде чем вы смогли отгрузить продукт, вы бы хотели, чтобы у вас были автоматизированные тесты!
  • Документы тестирования быстро устаревают. Когда добавляется новая функция, вы должны обязательно обновить основной документ тестирования. Если кто-то пропускает некоторые тесты, вы внезапно получаете ошибки, попадающие на страницы, которые «сделаны и протестированы». В настоящее время я работаю в такой среде, и могу вас заверить, это кошмар.

В конце концов, да, для написания этих дел требуется время, но вы должны гордиться их написанием. Это ваш способ доказательства, без тени сомнения, что ваш код работает и работает со всеми остальными функциями. Когда QA приходит к вам и говорит, что есть ошибка, вы исправляете ее, а затем добавляете в свой набор тестов, чтобы показать, что она исправлена, и убедиться, что она больше никогда не повторится.

Это ваша сеть безопасности. Когда кто-то заходит и захватывает сохраненный процесс и вносит небольшие изменения, чтобы он работал со своим кодом, вы поймете, что он нарушил 3 других функции в процессе. Вы поймете это в ту ночь, а не в ночь перед крайним сроком!

Что касается написания функциональных тестов только для критических функций системы. Это не даст вам полную картину, и это позволит ошибкам проникать. Все, что нужно, это добавить одну маленькую функцию, которая не критична для системы, но косвенно взаимодействует с критичной для системы функцией, и у вас есть потенциальная возможность появления ошибки.

Tyanna
источник
спасибо за Ваш ответ. Я знаю о важности и преимуществах функциональных тестов, мои опасения связаны с экономической выгодой от тестирования ВСЕХ. Мы разрабатывали функциональные тесты в течение последних трех лет, но теперь, в этом проекте, я чувствую, что затраты на внедрение теста ALL намного больше, чем на обнаружение ошибки в работе, повышение заявки и ее исправление ... Интересно, Существуют некоторые обстоятельства, когда НЕ делать функциональный тест лучше (с точки зрения затрат и выгод), чем не делать его, и мне интересно, если мы находимся в таких обстоятельствах, где лучше выбрать мудро, что тестировать.
Пабло Ласкано
@donsenior ~, если вы чувствуете, что тестирование занимает слишком много времени, посмотрите на инструменты, которые вы используете. Вы используете их правильно? Вы даже используете инструменты для экономии времени? Написание тестов занимает больше времени, чем написание кода, потому что у вас есть больше кода для написания. Это природа тестирования. Если вы начнете выбирать и для чего писать тесты, то доходит до того, что никто не будет писать тесты, или эти тесты будут неаккуратными.
Тианна
Моя идея выбора того, что тестировать, - это не случайный выбор, а выбор самой важной бизнес-функциональности (и это будет не решение разработчиков, а решение менеджера). И я думаю, что наоборот, разработчики, как правило, пишут неаккуратные тесты, потому что им приходится тестировать все, даже ту функциональность, которая требует 5 минут на тестирование QA и два дня на автоматизацию разработчика. Я согласен, что, возможно, инструменты, которые мы используем, не являются лучшими для тестирования нашего веб-приложения (fitnesse и java). Я боюсь, что мы приближаемся к моменту написания и поддержки функционального теста больше, чем системы
Пабло Ласкано
@donsenior ~ Конечно, для тестирования кейса требуется 5 минут, но для его тестирования требуется меньше секунды. Вы должны спросить: «Почему на то, чтобы написать что-то, что требует 5 минут на ручное тестирование, уходит 2 дня»? Опять же, посмотрите на ваши инструменты. Возможно, QA также должна написать несколько тестов? Проблема не в написании тестовых примеров для вашей системы, а в том, как пишутся эти тестовые примеры.
Тианна
ну, для выполнения этих тестов требуется намного больше секунды (помните, что это функциональные тесты, а не модульные тесты). Но это не проблема, они бегают ночью. Я думаю, что вы правы в том, что QA также должен писать несколько тестов, но, к сожалению, это не решение, которое я могу принять. Большое спасибо за ваши ответы, я отметил это как принятый!
Пабло Ласкано
7

Более чем в 2 раза ... мне кажется, немного много. Возможно, вы захотите проанализировать причины этого, они могут включать в себя:

  • плохая инструментальная поддержка для создания и сопровождения тестов

  • Контракты веб-сервисов недостаточно описаны в дизайне. Разработчики должны разрабатывать контракты во время тестирования, которое обычно занимает много времени.

Поговорите со своими разработчиками.

Предполагая, что вы разрабатываете в спринтах, эти функциональные тесты являются лишь частью спринта. Без этих тестов не обойтись. Если у вас его нет, ваше время на интеграционное тестирование после фазы разработки может удвоиться.

Андреас Хупперт
источник
Я согласен, возможно, мы не используем правильный инструмент для тестирования веб-приложения. Нет проблем при тестировании наших веб-сервисов. В любом случае, помимо правильного или неправильного способа проведения тестов, меня беспокоит стоимость. Я думаю, что на данный момент лучше (с точки зрения затрат / выгод) провести некоторое тестирование для отдела контроля качества и исправить ошибки, даже если они обнаружены в производстве.
Пабло Ласкано
Вы пропустили плохо разработанные классы как возможную причину слишком долгого тестирования. Это, безусловно, самая распространенная причина, которую я вижу, когда люди постоянно тестируют свой код.
Данк
4

Нормально ли тратить больше времени на внедрение функционального тестирования, чем на внедрение самой системы?

Абсолютно. Написание действительно хороших тестов, вероятно, займет большую часть времени во многих (хороших) магазинах.
Так что соотношение 2-1 хорошо. Сами менее опытные разработчики часто не принимают во внимание все тесты.

Майкл Даррант
источник
2

Существует закон убывающей отдачи. Предполагая, что вы сначала пишете тесты для самого опасного кода, значение, сгенерированное последующими тестами, со временем уменьшается.

Модульные тесты - это код, поэтому они будут содержать ошибки (как и любой другой код). Исправление этих ошибок занимает время.

По моему опыту, юнит-тесты содержат гораздо больше ошибок, чем система, которую они тестируют, и их исправление - постоянное бремя.


источник
1

Это о качестве.

Если вам нужно выйти на рынок - вы разработаете свое приложение как можно быстрее. У вас даже не может быть автоматических тестов =), но вы отдадите свое приложение аудитории раньше, чем ваши конкуренты.

Но если вы знаете, что ваш слух не уйдет, вы сделаете все, что сможете, чтобы не разочаровать их. Каждый жук билета повредит вашей репутации. Представьте, что одна ошибка удалит 50 процентов вашей репутации, а другая - еще 25 процентов и так далее. Так может ли быть слишком много тестов?

Никита У.
источник
ну, я не совсем уверен, что в этот момент мы действительно сокращаем билеты. Возможно, мы сократили (но не сильно) количество заявок на QA, но количество ошибок, обнаруженных в этом тесте, недостаточно (с моей точки зрения), чтобы оправдать такие затраты, когда 2/3 разработчиков программного обеспечения занимались разработкой функциональных тестов.
Пабло Ласкано
0

Если по «это нормально» вы спрашиваете, распространено ли это, нет, конечно, нет. Многие команды разработчиков имеют плохую практику тестирования (я принадлежу к одной) и даже качественные книги, которые я прочитал, советуют тратить примерно столько же времени на кодирование функциональности, чем тесты. Если по нормальному вопросу вы спрашиваете, здоров ли он, это зависит, но лучше в два раза больше тестов, чем нужно.

Это не должно быть критическим . Когда вы тестируете функциональность, вы тестируете что-то полезное для конечных пользователей, и вы обязаны знать (и не догадываться), что все время работает правильно. Если вам нужно в два раза больше для этой цели, то это должно быть сделано именно так - если это возможно.

Также возможно, что ваша политика слишком строга в отношении автоматизированных тестов, но трудно сказать, не зная, к какому качеству они стремятся, их ресурсам и к чему еще они могут быть привязаны.

Артур Гавличек
источник