Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 218
не все и не везде можно покрыть автотестами
Я согласен. К примеру как можно покрыть автоматическими тестами 3д игру?
А фонарик в мобилке? :)
Можно, если производитель этим заморочится. Самое элементарное — стенд с фотодиодом. Посмотрите промо-видео на youtube, как Samsung тестирует свой S3. Видео, к сожалению, не содержит теста вспышки, но думаю, что он должен быть.
мне почему-то кажется, что пример с самсунгом немного не об этом, ведь заказчик такой штуки скорее всего был внутри компании и тесты S3 это стезя разработки, а не внешних отношений, как предлагается в статье.
может-ли внешний заказчик доверять автотестам? каким образом он можно убедиться, что приемочные автотесты:
1. полны (покрывают достаточный объем функциональности)?
2. состоятельны (действительно что-то проверяют, а не рисуют зеленые полоски «от балды»)?
3. адекватны (приложение в продакшене будет вести себя так же как в среде тестирования)?
4. экономически выгодны (стоимость их внедрения, разработки и поддержки будет ниже, чем у альтернатив)?
может-ли внешний заказчик доверять автотестам? каким образом он можно убедиться, что приемочные автотесты:
1. полны (покрывают достаточный объем функциональности)?
2. состоятельны (действительно что-то проверяют, а не рисуют зеленые полоски «от балды»)?
3. адекватны (приложение в продакшене будет вести себя так же как в среде тестирования)?
4. экономически выгодны (стоимость их внедрения, разработки и поддержки будет ниже, чем у альтернатив)?
П.1 и 3 решается совместным подписанием ПМИ (и без него в пиемочных тестах нет никакого смысла).
П.2 решается ручным прогоном тех же самых тестов.
Наконец, п.4 решается рынком и левой пяткой заказчика.
И на самом деле, все эти пункты не зависят от того, автоматизированы ли приемочные тесты, или нет.
П.2 решается ручным прогоном тех же самых тестов.
Наконец, п.4 решается рынком и левой пяткой заказчика.
И на самом деле, все эти пункты не зависят от того, автоматизированы ли приемочные тесты, или нет.
Вот что удивляет — когда в таких обсуждениях всплывают организационные или юридические вопросы. Как будто введение автоматического или автоматизированного тестирования что-то меняет, как будто ручного тестирования своих продуктов никто никогда не делает, а просто дают заказчику «мы тут написали что-то, но что получилось не проверяли — на, смотри сам». Или как будто считают возможным сдать очередной билд с явными регрессиями в надежде, что заказчик при приемке не станет тестировать уже проверенную им когда-то функциональность.
Каких «таких»?
Понимаете ли, посыл поста не в том, чтобы делать автоматизированное тестирование. Посыл поста в том, чтобы включать его в критерии готовности продукта — то есть, обсуждать и согласовывать с заказчиком. А это, в свою очередь, означает организационные и юридические вопросы.
Конечно, меняет. Меняет стоимость разработки.
Ситуации, когда при сдаче билда не проводится регрессионное тестирование под лозунгом «да что там могло сломаться» — весьма распространены.
Понимаете ли, посыл поста не в том, чтобы делать автоматизированное тестирование. Посыл поста в том, чтобы включать его в критерии готовности продукта — то есть, обсуждать и согласовывать с заказчиком. А это, в свою очередь, означает организационные и юридические вопросы.
Как будто введение автоматического или автоматизированного тестирования что-то меняет,
Конечно, меняет. Меняет стоимость разработки.
Или как будто считают возможным сдать очередной билд с явными регрессиями в надежде, что заказчик при приемке не станет тестировать уже проверенную им когда-то функциональность.
Ситуации, когда при сдаче билда не проводится регрессионное тестирование под лозунгом «да что там могло сломаться» — весьма распространены.
Посыл поста в том, чтобы включать его в критерии готовности продукта.
В посте вроде не указано, что об этом критерии должен знать заказчик. Он вполне может быть и внутренним критерием готовности продукта, о котором заказчик ничего не знает, в лучшем случае получает инфу типа «мы новую фичу сделали, начали тестировать и увидели, что старая отвалилась, сейчас чиним, потому небольшая задержка», а как тестировали — ручками или автотестами — заказчика особо и не должно волновать.
Конечно, меняет. Меняет стоимость разработки.
Я про организационные вопросы в отношениях с заказчиком.
Ситуации, когда при сдаче билда не проводится регрессионное тестирование под лозунгом «да что там могло сломаться» — весьма распространены.
Я, скорее, про ситуации, когда провели, что-то некритичное сломалось, но билд всё равно выкатывается под лозунгом «дедлайн на носу, дадим что есть, а потом скажем, что нашли регрессию уже после сдачи и вот новый билд с его исправлением».
В посте вроде не указано, что об этом критерии должен знать заказчик.
Ну здрасте пжалста. Цитата (выделение мое):
Это и есть процесс формирования приемочных критериев. Они представляют из себя мини-контракт между заказчиком и командой на реализацию этой функциональности.
Что характерно, это второй раз, когда я цитирую эту фразу.
Я про организационные вопросы в отношениях с заказчиком.
А стоимость разработки заказчика не волнует, типа?
Я, скорее, про ситуации, когда провели, что-то некритичное сломалось, но билд всё равно выкатывается под лозунгом «дедлайн на носу, дадим что есть, а потом скажем, что нашли регрессию уже после сдачи и вот новый билд с его исправлением».
А эта ситуация как раз возникает тогда, когда у заказчика нет приемочных тестов.
Ну здрасте пжалста. Цитата (выделение мое):
Заказчик формулирует критерии на своем языке, а разработчики переводят их на язык автотестов. Заказчик волен проверять свои критерии любым способом. То, что это должны быть тесты, разработанные исполнителем — лишь одна из опций. Он может по списку критериев в простой письменной форме пробежаться ручками, может нанять кого-то для этих целей, может проверить только часть критериев. Прохождение тестов для него не обязано быть критерием приемки, тем более основным критерием, в частности по обозначенным funca причинам, заключающимся в общем в том, что «зеленые полоски» не означают, что продукт соответствует критериям, сформулированным на человеческом языке.
Скажите, а зачем вы сейчас это мне написали? Это никак не противоречит написанному мной.
В рамках поста это обязательная опция (хотя и не отменяющая остальных).
То, что это должны быть тесты, разработанные исполнителем — лишь одна из опций.
В рамках поста это обязательная опция (хотя и не отменяющая остальных).
Не вижу я в посте, что это обязательная опция, хотя ещё раз его перечитал. «Мини-контракт» может быть заключен на бумаге, а не апрувом исходников тестов.
В общем, по-моему, приемочные тесты могут быть юридически значимым критерием только в ситуации когда заказчик по сути сам их пишет, сам несёт ответственность за их содержанием. В лучшем случае, когда их понимает и визирует или, хотя бы, может проконтролировать, что с прошлого билда ничего не менялось в тестах и тестирующем фреймворке. По сути ему нужен доступ к инфраструктуре разработчика, чтобы контролировать, что тот не мухлюет с тестами.
В общем, по-моему, приемочные тесты могут быть юридически значимым критерием только в ситуации когда заказчик по сути сам их пишет, сам несёт ответственность за их содержанием. В лучшем случае, когда их понимает и визирует или, хотя бы, может проконтролировать, что с прошлого билда ничего не менялось в тестах и тестирующем фреймворке. По сути ему нужен доступ к инфраструктуре разработчика, чтобы контролировать, что тот не мухлюет с тестами.
Не вижу я в посте, что это обязательная опция, хотя ещё раз его перечитал. «Мини-контракт» может быть заключен на бумаге, а не апрувом исходников тестов.
Обязательная опция — наличие таких тестов и передача их заказчику.
По сути ему нужен доступ к инфраструктуре разработчика, чтобы контролировать, что тот не мухлюет с тестами.
Зачем? Вообще-то еще должен быть тестовый контур на стороне заказчика, где проводится тестирование перед внедрением. Вот там такие вещи и гоняют.
Это очень квалифицированный заказчик должен быть тогда, а это обязательной опцией не является по определению. Это типа как перед тем как покупать автомобиль лично проверять его соответствие всем техническим требованиям. Есть такие покупатели, но их меньшинство, большинство довольствуется простеньким тест-драйвом (ручным тестированием по самым частым сценариям) и гарантией.
Это опция приблизительно того же порядка, что и заказчик, готовый оплатить разработку автоматизированных тестов на стороне разработчика.
Меньшего. Вот прямо сейчас я договариваюсь о разработке с тестами, речи о их запуске заказчиком нет. Формально они у него будут (в его репозиторий хранится будут), но вряд ли он в них полезет когда. Он их принимает (если примет) как мое личное средство обеспечения качества кода, наравне с, например, тем, что я использую IDE, а не в блокноте пишу.
Вы не поверите, такое бывает
Вы меня не правильно поняли. Речь о приложении, которое светит диодом. Заморочная хрень на зоопарке андроидов и тестирование подразумевает мартышкин труд.
Кстати, справедливости ради, натыкался лет 8-9 назад на коммерческий 3D-движок, в котором юнит-тестами были покрыты даже всякие нюансы с рендерингом, анализировалось «как отрендерилось» и «как должно отрендериться» :)
За давностью лет, увы, совершенно вылетело из головы, как он назывался.
За давностью лет, увы, совершенно вылетело из головы, как он назывался.
Вы правы — не все легко покрыть автотестами. Но из моего опыта, люди зачастую просто не знают, не хотят, не умеют этого делать. Для веб проектов есть Selenium, для совершенно произвольных есть Sikuli. А еще уйма инструментов специализированных. Если не получается протестировать через конечный пользовательский UI, то можно тестировать API бизнес логики.
Selenium никак не узнает что, например, испортился layout в IE.
угу, или кнопка «купить» стала белая на белом фоне — он же ее по имени лукапит.
Я слышал это как реальную историю, которую вылечили тем, что увидели после коммита резкое падение типичного количества заказов на сайте.
Я слышал это как реальную историю, которую вылечили тем, что увидели после коммита резкое падение типичного количества заказов на сайте.
Можно замечательно с помощью Selenium тестировать UI (расположение элементов, верстку, отработку JavaScript). На эту тему советую посмотреть мое выступление: www.youtube.com/watch?v=cUoSTBkeFy4. А тут есть еще много всего полезного на эту тему: xpinjection.com/resources/.
отлично, актуально, спасибо :)
Еще бы кто нибудь разъяснил толком как настроить ферму тестовых машин и тесты запускать параллельно…
Приезжайте на SeleniumCamp 2013. Там будет автор Selenium Grid из eBay и много докладчиков из больших продуктовых компаний: Google, Groupon, Amazon, eBay, Яндекс, Одноклассники, 2ГИС и т.д. А у них фермы машин стоят достаточно большие.
Обновил пост ссылкой на статью сегодняшнюю про облачные провайдеры для запуска тестов. Вполне себе вменяемые цены и неплохой вариант для многих проектов.
Selenium grid hub запускается одной командой.
Selenium grid node запускается ещё одной командой.
Что именно вам непонятно в вопросе «как настроить ферму тестовых машин и тесты запускать параллельно»?
Selenium grid node запускается ещё одной командой.
Что именно вам непонятно в вопросе «как настроить ферму тестовых машин и тесты запускать параллельно»?
Посмотрел выступление, так и не увидел — какой же инструмент используется для screenshot-based тестирования?
Вебдрайвер максимум сделает скриншот, но он не сделает никаких автоматических сравнений скриншотов.
В презентации автор упоминает что у них задаются области, исключаемые из сравнения — для какого инструмента они задаются?
В конце презентации вообще интересные вопросы — как быть с мобильными девайсами, iOS — на них вебдрайвер вам не сделает скриншоты. Или сделает?
В презентации автор упоминает что у них задаются области, исключаемые из сравнения — для какого инструмента они задаются?
В конце презентации вообще интересные вопросы — как быть с мобильными девайсами, iOS — на них вебдрайвер вам не сделает скриншоты. Или сделает?
Нет, это не для скриншот-бейз тестирования, это для выявления других проблем, про которые в презентации говорится после скриншот-бейзд — выползание текста за края, поломанные картинки и т.п.
Цитата с сайта:
What does it offer?
Currently there are the following detectors:
— DetectInvalidImageUrls
— DetectTextNearOrOverlappingHorizontalEdge
— DetectTextNearOrOverlappingVerticalEdge
— DetectTextWithTooLowContrast
— DetectElementsWithInvisibleFocus
Цитата с сайта:
What does it offer?
Currently there are the following detectors:
— DetectInvalidImageUrls
— DetectTextNearOrOverlappingHorizontalEdge
— DetectTextNearOrOverlappingVerticalEdge
— DetectTextWithTooLowContrast
— DetectElementsWithInvisibleFocus
P.S. О, таки да — для iOS и Android уже есть Driver-ы которые, вероятно, делают скриншоты — code.google.com/p/selenium/wiki/WebDriverForMobileBrowsers
Одной проблемой меньше.
Одной проблемой меньше.
Видимо невнимательно смотрели. Сравнивалка картинок с регионами самописная. Это самая простая часть, любой адекватный разработчик пишет за пару часов. :) В интернете пробегала публичная версия на питоне, но ссылку не помню. У нас на Java.
В 99% случаев, я слышу эту фразу, как оправдание отсутствия автотестов :). Даже если нельзя достич 100% покрытия, автотесты значительно облегчат участь ручных тестеров, и уменьшат время проверки продукта
Но увеличивают время разработки, если писать под каждую функцию свои тесты. =)
Но увеличивают меньше чем в последствии экономят. Это факт.
А вы таки вообще не тестируете свои приложения? Или как — отдали тестерам, время разработки закончилось?
Ну лично у меня. В общей массе тестами сильно обвешивать не приходилось. Когда-то вообще не знал даже о таком, хотя и проекты были мелочью «быстро сделал, сдали и забыл». Ну а последнее несколько лет, работал над двумя крупными. Тут как не пытался, не смог заказчиков убедить ввести тесты и закладывать их во время разработки. Только для себя кое какие тесты вводил, для бакенда сложной логики.
Да и тестеров там вообще не было. Заказчикам нужно было «быстрее делай это и запускай, и принимайся за новые модули».
Да и тестеров там вообще не было. Заказчикам нужно было «быстрее делай это и запускай, и принимайся за новые модули».
Не все баги можно найти, что теперь, никакие не искать?
Особенно если разработка ведется в условия часто изменяющихся требований.
Какая-то отчасти утопичная картина — заказчик вот так сразу взял и смог выдать все требования к какой-то части функционала. Ну-ну.
К сожалению, заказчик легко напридумывает новых требований к уже написанному, что повлечет за собой переписывание тестов.
К сожалению, заказчик легко напридумывает новых требований к уже написанному, что повлечет за собой переписывание тестов.
Полностью поддерживаю! В статье описан какой-то идеальный заказчик — эдакий сферический заказчик в вакууме :)
На деле же оказывается, что по мере развития проекта всегда появляются новые элементы и дополнения, которые сразу предугадать невозможно. Да и это логично. Ведь если проект и идеи не модифицируются в ходе реальных тестов и работы проекта — то это, скорее всего, мёртвый проект.
На деле же оказывается, что по мере развития проекта всегда появляются новые элементы и дополнения, которые сразу предугадать невозможно. Да и это логично. Ведь если проект и идеи не модифицируются в ходе реальных тестов и работы проекта — то это, скорее всего, мёртвый проект.
Пусть себе на здоровье модифицируются, но скорее всего не вся функциональность перепиливается каждую неделю, особенно в большом проекте.
Не вся… не каждую неделю… Но обычно где-то через несколько месяцев подобных дополнений потребуется рефакторинг кода, чтобы всё работало хорошо и держало нагрузки. А писать идеальный код сразу… не знаю, не встречал я таких людей. Разве что — написать идеально и всё, в долгий ящик и больше никогда этот код не трогать.
Рефакторинг — последовательность изменений, которая изменяет внутреннюю структуру программы без изменения ее внешнего поведения.
При рефакторинге тесты не меняются. Более того, без них невозможно убедиться, что внешнее поведение не изменилось, а значит называть это рефакторингом. :)
При рефакторинге тесты не меняются. Более того, без них невозможно убедиться, что внешнее поведение не изменилось, а значит называть это рефакторингом. :)
при рефакторинге уровня программы не меняются приемочные тесты. но все, что касается её внутренностей (unit, интеграционные) ломается — аж пыль столбом. :)
Не должны ломаться тесты того уровня (и выше), что рефакторится.
Интересно, кто минус поставил считает, что должны ломаться приемочные тесты, если где-то выделили кусок кода в отдельный метод или переименовали индекс цикла?
Нет, я думаю, что те, кто видят, что при архитектурном рефакторинге тесты «того же уровня» ломаются с вероятностью, близкой к 0.99.
Не понимаю. Вот есть приемочные тесты, работающие чисто с UI. Проводим архитектурный рефакторинг без изменения UI (иначе это не рефакторинг, а изменение функциональности) — разве должны приемочные тесты при этом ломаться? Разве как раз прохождение тестов без их изменения не будет сигналом, что рефакторинг завершен и только теперь можно думать об изменении тестов или написании новых?
Вам уже написали, что приемочные тесты не ломаются, ломаются все остальные. Их, что характерно, больше, чем приемочных, на несколько порядков.
Так ломаются (и должны ломаться, если их предварительно не изменить) тесты ниже уровнем, а не того же или выше. Рефакторим архитектуру на высоком уровне — должны ломаться тесты уровнем ниже приемочных, функциональные, взаимодействующие непосредственно с кодом продукта, минуя UI.
Так ломаются (и должны ломаться, если их предварительно не изменить) тесты ниже уровнем, а не того же или выше.
У вас очень свое понимание «уровня» тестов.
И да, как раз «того» уровня тесты и ломаются — когда я рефакторю компонент, меняя его зависимости, тесты, написанные для тестирования этого компонента в изоляции, ломаются, потому что зависимости перестают совпадать.
Меняя его зависимости разве вы не меняете го поведение? Ну, кроме вырожденных случаев, когда формально зависимость есть, но нигде не используется. И это если не считать, что зависимость часть поведения.
Меняя его зависимости разве вы не меняете го поведение?
Зафиксированное в его контракте? Нет, не меняю.
Сигнатура конструктора контрактом не является?
Во-первых, не обязательно, потому что это детали реализации. Во-вторых, зависимости не обязательно выражены в сигнатуре конструктора (и вообще во внешнем интерфейсе).
И должны ломаться, потому что те части приложения, которые зависят от модифицируемого кода тоже ломаются. Или вы предпочитаете надеятся, что это только тесты сломались?
А пыль столбом — это если рефакторить от души, а потом тесты запускать. Если делать рефакторинг мелкими шагами, постоянно прогоняя тесты, все совсем не так драматично.
А пыль столбом — это если рефакторить от души, а потом тесты запускать. Если делать рефакторинг мелкими шагами, постоянно прогоняя тесты, все совсем не так драматично.
Написать идеальный код сразу (да и со временем) не возможно, но возможно написать тестируемый код. Если код возможно протестировать и эти тесты для него написаны, то код уже близкий к идеалу, так как его можно рефакторить и не бояться что отвалится пол системы.
В том то и дело, что обычно хреновый код в долгий ящик кладут (работает — не трогай!), а код который покрыт тестами он «живой», он дышит…
В том то и дело, что обычно хреновый код в долгий ящик кладут (работает — не трогай!), а код который покрыт тестами он «живой», он дышит…
ни один бизнес не стоит на месте, если он пока еще жив
так что требования менялись, меняются и будут меняться
а раз он жив, то у бизнеса все хорошо
а вот с кодом работать вам, и обеспечивать его работоспособность тоже
я вам за багфиксы вообще не платил бы, ведь вы уже сделали что-то за что уплочено, сами сломали, сами и фиксите
так что требования менялись, меняются и будут меняться
а раз он жив, то у бизнеса все хорошо
а вот с кодом работать вам, и обеспечивать его работоспособность тоже
я вам за багфиксы вообще не платил бы, ведь вы уже сделали что-то за что уплочено, сами сломали, сами и фиксите
Дык вопрос не в багфиксах, а в оптимизации взаимодействия новых фич и уже написанного.
называйте это как хотите, но если первая фича готова, и вторая тоже готова, но вместе они не работают, то за что вам платить?
Речь идет о работе над требованиями на очень короткий срок — обычно одна итерация. Если он не может на такой срок сформулировать требования во всех деталях и ответить на все вопросы, то у вас уже проблемы. :)
Да какая разница. Всегда возможно такое «а вот была пол года назад формочка, а надо в ней поменять функциональность, чтобы она грузила данные не оттуда а отсюда...».
А на неделю может, да =)
А на неделю может, да =)
Так тут как раз все отлично! Полгода вы контролировали автоматически что она грузит данные из одного места. Потом перед тем как изменить поменяли тест. Он не проходит. Реализовали загрузку из другого места и вуаля! Все продолжает работать. Называется это ATDD — Acceptance Test Driven Development. :)
И какой тогда профит, если мне нужно постоянно писать новые тесты и вместе с этим переделывать половину (ну да, заказчики они такие) старых?
В том, что между этими переделками вы можете в любой момент времени, сделав изменение в любом месте, понять что все работает как должно работать. А если что-то поломается, то это будет видно и заказчику и вам и всем заинтересованным лицам.
Профит в том, что Вы знаете, что не сломали вторую половину.
Иначе — вот, мы сделали что требовалось — тестирование заказчиком — исправление багов — тестирование заказчиком — исправление багов, вылезших на другом конце — …
Иначе — вот, мы сделали что требовалось — тестирование заказчиком — исправление багов — тестирование заказчиком — исправление багов, вылезших на другом конце — …
ой да лааадно. Ну вот прям таки на 100% у вас требования поменяются. Да и поменять существующий тест — не так уж и сложно, серьёзно (у меня как раз почти полное покрытие автотестами, и динамично-меняющийся заказчик).
По сути, автотесты для разработки в целом — могут быть вполне тем же самым что и unit-тесты для написания кода.
По сути, автотесты для разработки в целом — могут быть вполне тем же самым что и unit-тесты для написания кода.
А почему не затронуты минусы? Из того, что я могу прикинуть на опыте сразу после прочтения:
1. Как заставить заказчика составить список тестов?
2. Что если из-за написания таких тестов стоимость разработки увеличится на сумму большую чем стоимость разработки продукта?
3. Что если заказчик забыл/не учел какой-то тест?
Но, в целом, должен заметить, что нечто подобное, возможно, не в таком конкретном виде всегда присутствует и «обман» заключается в том, что заказчик сам всего не может учесть — такая уж это область, как и не все тесты можно придумать.
1. Как заставить заказчика составить список тестов?
2. Что если из-за написания таких тестов стоимость разработки увеличится на сумму большую чем стоимость разработки продукта?
3. Что если заказчик забыл/не учел какой-то тест?
Но, в целом, должен заметить, что нечто подобное, возможно, не в таком конкретном виде всегда присутствует и «обман» заключается в том, что заказчик сам всего не может учесть — такая уж это область, как и не все тесты можно придумать.
Для этого и есть комментарии. ;)
1. Его не надо заставлять ничего писать. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор тестов.
2. Тут вы точно подметили, надо считать. Это решение логически верное, но может быть физически невыгодным в определенных условиях. Например, при краткосрочном проекте или очень сложным пользовательским интерфейсом, который почти нереально покрыть автотестами.
3. Ничего страшного, тесты дописываются в момент нахождения таких моментов. Главное, сразу же подумать как не допустить такого в будущем.
Для того, чтобы все учитывать и не забывать, надо мыслить малым. Именно в этом помогают итерации и фокусировка на ограниченном небольшом куске функциональности.
1. Его не надо заставлять ничего писать. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор тестов.
2. Тут вы точно подметили, надо считать. Это решение логически верное, но может быть физически невыгодным в определенных условиях. Например, при краткосрочном проекте или очень сложным пользовательским интерфейсом, который почти нереально покрыть автотестами.
3. Ничего страшного, тесты дописываются в момент нахождения таких моментов. Главное, сразу же подумать как не допустить такого в будущем.
Для того, чтобы все учитывать и не забывать, надо мыслить малым. Именно в этом помогают итерации и фокусировка на ограниченном небольшом куске функциональности.
Его не надо заставлять ничего писать. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор тестов
Какие вы оптимисты.
«Вы мне сделайте, что я прошу, а проверю я сам». И все.
и что же он такого просит?
я не понял что вы имеете ввиду, уточните
объясните мне как для своей бабушки в конце концов
или расскажите как вы делаете то, что не понимаете как проверить?
я не понял что вы имеете ввиду, уточните
объясните мне как для своей бабушки в конце концов
или расскажите как вы делаете то, что не понимаете как проверить?
Ну например — чтобы вот тут была формочка, данные вводились, обрабатывались и показывались.
Тесты? Какие тесты? Не хочу никаких тестов.
Тесты? Какие тесты? Не хочу никаких тестов.
какая формочка? какие данные? как обрабатывались? что показывалось?
Цитирую ответ заказчика дословно: " ты что, дурак, что ли"?
А если серьезно (хотя и предыдущее было серьезно), то заказчик еще готов потратить время на объяснение вам сценариев использования, но вот ПМИ он с вами обсуждать может и не захотеть. А нет ПМИ — значит, нет и приемочных тестов.
А если серьезно (хотя и предыдущее было серьезно), то заказчик еще готов потратить время на объяснение вам сценариев использования, но вот ПМИ он с вами обсуждать может и не захотеть. А нет ПМИ — значит, нет и приемочных тестов.
Простите, а как Вы тогда вообще за проект берётесь? Вас же заказчик загоняет до полусмерти, ещё и только половину заплатит.
Стараюсь не браться.
Заказчиков, несомненно, надо воспитывать. Но выбить из него список аксептанс-тестов — это существенно дальше в перспективе, нежели выбить из него нормальные требования.
Заказчиков, несомненно, надо воспитывать. Но выбить из него список аксептанс-тестов — это существенно дальше в перспективе, нежели выбить из него нормальные требования.
А Вы не работали с крупными заказчиками, банками? Вы сами решаете с кем работать? Если начальство говорит, что с этим заказчиком надо работать, Вы говорите: «Нет, не буду!»?
Пускай калькулятор обычный. Вполне реальный дилог может быть такой:
— как проверять будете?
— введу что-нибудь и сложу, а потом умножу и т. п.
— что введете?
— ты что издеваешься?
— как проверять будете?
— введу что-нибудь и сложу, а потом умножу и т. п.
— что введете?
— ты что издеваешься?
в руби, например, и строки умножать можно, но это не ожидаемое поведение калькулятора
никто не сказал, что складывать надо не только int, но и float, а с кого спрашивать?
если все риски закладывать в цену, так я найду кто дешевле сделает
никто не сказал, что складывать надо не только int, но и float, а с кого спрашивать?
если все риски закладывать в цену, так я найду кто дешевле сделает
…
— Нет, я не издеваюсь. Просто прошлый раз под «что-нибудь» я понимал целые числа, а вы думали про все подряд. Потом пришлось переделывать.
— Ну это же просто здравый смысл взять все числа!
— Здравый смысл как оказывается у каждого свой, да еще и склонен меняться. Давайте пару примеров накидаем и так все будет проще.
— Нет, я не издеваюсь. Просто прошлый раз под «что-нибудь» я понимал целые числа, а вы думали про все подряд. Потом пришлось переделывать.
— Ну это же просто здравый смысл взять все числа!
— Здравый смысл как оказывается у каждого свой, да еще и склонен меняться. Давайте пару примеров накидаем и так все будет проще.
— Так я же полгода назад говорил, что не все числа надо, а только целые
а еще через полгода
— Почему калькулятор дробные числа не считает?
и где искать потом правду?
а еще через полгода
— Почему калькулятор дробные числа не считает?
и где искать потом правду?
Извините, не могу не процитировать из одной в свое время популярной статьи (А. Соловьев «Ишкушштвенный интеллект»)
— Какие могут быть формальности между друзьями! Вася, сделай мне программу сортировки.
— А что такое сортировка?
— Мне надо, чтобы я вводил любые числа, а программа выдавала УПОРЯДОЧЕННЫЕ числа.
(через неделю)
— Ты что, Вася! Я ввожу 5 4 7 6, а твоя программа выдает 1 2 8 9.
— Так бы и сказал, что она должна использовать ВВЕДЕННЫЕ числа.
(через неделю)
— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6.
— Так бы и сказал, что ВСЕ числа должны присутствовать.
(через неделю)
— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6 7 и 8 и 9.
— Я выдал все, а от себя ДОБАВИЛ, по дружбе, чтобы ты от меня отстал, наконец.
(через неделю)
— Ты что, Вася! Я ввожу 5.4 и 7.6, а она даже два числа отказывается сортировать.
— А откуда я знал, что тебе НЕ ТОЛЬКО целые надо сортировать?
Может тебе завтра взбредет комплексные сортировать?! Последний раз!!!
(через неделю)
— Ты что, Вася! Программа больше девяти чисел не сортирует...
>>— введу что-нибудь и сложу, а потом умножу и т. п.
Вот вам и почва для написания приёмок.
Или Вы хотите, чтоб заказчик сначала складывал/умножал. Потом оказывается что ему нужно и вычитание/деление. Потом — запуск небольших программ на бейсике (А что, это не очевидно?! Вот, смотрите, калькулятор от ****** это умеет!)…
Вот вам и почва для написания приёмок.
Или Вы хотите, чтоб заказчик сначала складывал/умножал. Потом оказывается что ему нужно и вычитание/деление. Потом — запуск небольших программ на бейсике (А что, это не очевидно?! Вот, смотрите, калькулятор от ****** это умеет!)…
Это нам польза от написания приемочных тестов. А вот заказчику — нет. Поэтому он и будет эту деятельность саботировать до последнего.
Как раз от приёмочных тестов — больше всего пользы заказчику. Потому что он получает протестированный продукт, а не абы-что. Особенно это касается сложной системы, проверить которую за пару дней просто не возможно.
Ваша задача — просто донести это до заказчика. И да, по опыту, автоматизаторы выходят не дороже ручных тестеров (из-за того что их значительно меньше нужно). А раз нет ценовой разницы — то какие ещё могут быть аргументы против? :)
*жуткая догадка* Или Вы вообще не тестируете?
Ваша задача — просто донести это до заказчика. И да, по опыту, автоматизаторы выходят не дороже ручных тестеров (из-за того что их значительно меньше нужно). А раз нет ценовой разницы — то какие ещё могут быть аргументы против? :)
*жуткая догадка* Или Вы вообще не тестируете?
Потому что он получает протестированный продукт, а не абы-что.
Вы что-то путаете. Степень протестированности продукта не зависит от того, есть ли подписанные заказчиком ПМИ.
Зато ПМИ не дают заказчику сказать «не, меня не устраивает, хочу иначе» — и это ему невыгодно.
И да, по опыту, автоматизаторы выходят не дороже ручных тестеров (из-за того что их значительно меньше нужно). А раз нет ценовой разницы — то какие ещё могут быть аргументы против?
Вы стоимость разработки ПМИ и, что важнее, стоимость тестовых ландшафтов тоже посчитали, я надеюсь?
Видимо мы о разных вещах говорим, т.к. я привык называть приёмочными тестами любые функциональные тесты, на основе которых принимается решение о валидности продукта.
очевидно, что в вашем случае, приёмки будут подмножеством функциональных тестов. В таком случае, действительно, со стороны заказчика глупо давать план тестирования, т.к. он может получить продукт, который работает только по 2-3 сценариям. Либо же заказчику придётся составлять план, покрывающий 100% функциональности продукта.
А теперь по стоимости. Вы согласны, что тест-кейсы придётся разрабатывать в любом случае? А теперь прикиньте сколько раз, ручные тестеры будут гонять один и тот же тесткейс во время разработки, и Вы сами придёте к тому, что автотесты — банально дешевле
очевидно, что в вашем случае, приёмки будут подмножеством функциональных тестов. В таком случае, действительно, со стороны заказчика глупо давать план тестирования, т.к. он может получить продукт, который работает только по 2-3 сценариям. Либо же заказчику придётся составлять план, покрывающий 100% функциональности продукта.
А теперь по стоимости. Вы согласны, что тест-кейсы придётся разрабатывать в любом случае? А теперь прикиньте сколько раз, ручные тестеры будут гонять один и тот же тесткейс во время разработки, и Вы сами придёте к тому, что автотесты — банально дешевле
Видимо мы о разных вещах говорим, т.к. я привык называть приёмочными тестами любые функциональные тесты, на основе которых принимается решение о валидности продукта.
Цитирую обсуждаемый пост (выделение мое):
Это и есть процесс формирования приемочных критериев. Они представляют из себя мини-контракт между заказчиком и командой на реализацию этой функциональности.
Именно об этом я и говорю.
А теперь прикиньте сколько раз, ручные тестеры будут гонять один и тот же тесткейс во время разработки, и Вы сами придёте к тому, что автотесты — банально дешевле
Они возможно дешевле в идеальной долгосрочной перспективе. А в реальности для некоторых приложений написание автоматизированных сценариев тестирования увеличивает косты разработки вдвое или втрое.
>>Они возможно дешевле в идеальной долгосрочной перспективе. А в реальности для некоторых приложений написание автоматизированных сценариев тестирования увеличивает косты разработки вдвое или втрое.
После 3-ей итерации уже будут дешевле. Попробуйте.
Впрочем, если у вас небольшие приложения, которые укладываются в одну итерацию — смысла не будет.
После 3-ей итерации уже будут дешевле. Попробуйте.
Впрочем, если у вас небольшие приложения, которые укладываются в одну итерацию — смысла не будет.
После 3-ей итерации уже будут дешевле. Попробуйте.
Мне нравится, как уверенно вы говорите о стоимости разработки приложения, которого вы в глаза не видите.
не приложения, что Вы. Всего лишь о том, что бы заменить (хотя бы частично) «мартышек» на автоматизаторщиков.
А вы думаете, что стоимость этого процесса не зависит от приложения?
Ещё раз — я говорю о удешевлении производства, из-за добавления в него автоматизации. Практика показывает, что даже в металлургии это приносит пользу.
Я думаю, можно придумать ситуацию, когжда автоматизация лишь приведёт к удорожанию процесса. Но 90% вероятности, что Вы просто не хотите с этим заморачиваться. Ведь проще убедить себя и начальство, что авто-тесты зло, правда?
Я думаю, можно придумать ситуацию, когжда автоматизация лишь приведёт к удорожанию процесса. Но 90% вероятности, что Вы просто не хотите с этим заморачиваться. Ведь проще убедить себя и начальство, что авто-тесты зло, правда?
Ещё раз — я говорю о удешевлении производства, из-за добавления в него автоматизации.
Это, по-вашему, верно для любого производства?
Но 90% вероятности, что Вы просто не хотите с этим заморачиваться.
Мы как раз хотим. Но стоимость развертывания тестового полигона такова, что мы не можем себе этого позволить.
>>Это, по-вашему, верно для любого производства?
Прочитайте ещё раз мой комментарий.
>>Мы как раз хотим. Но стоимость развертывания тестового полигона такова, что мы не можем себе этого позволить.
Если не секрет — то что у Вас за разработка?
Прочитайте ещё раз мой комментарий.
>>Мы как раз хотим. Но стоимость развертывания тестового полигона такова, что мы не можем себе этого позволить.
Если не секрет — то что у Вас за разработка?
Если не секрет — то что у Вас за разработка?
Унаследованная информационная система масштаба распределенного предприятия.
Отлично. Я думаю деньги на ещё одну машинку у Вас есть. А это значит, что используя системы типа Selenium Или testcomplite Вы вполне можете выполнять приёмочные тесты для вновь созданного функционала. Да, это будет казаться каплей в море. Да, это не будет гарантировать работоспособности всей системы. Но! это будет гарантировать работоспособность новых модулей.
С другой стороны, сейчас я являюсь свидетелем внедрения автоматизации в достаточно массивный проект. Там автоматизация внедряется по другому пути — покрываются наиболее критические участки. И это не выходит особо дорого.
Так что — В вашем случае есть различные методы внедрения автоматизации (на первых этапах частичной), и некоторые из них — вполне бюджетны.
С другой стороны, сейчас я являюсь свидетелем внедрения автоматизации в достаточно массивный проект. Там автоматизация внедряется по другому пути — покрываются наиболее критические участки. И это не выходит особо дорого.
Так что — В вашем случае есть различные методы внедрения автоматизации (на первых этапах частичной), и некоторые из них — вполне бюджетны.
«Одна машинка?» Понятно. Дальше не интересно. Вы правда не понимаете масштаб проблемы, в рамках которой даете советы.
70+M пользователей, 2M+ уникальных в день, 600mb кода. Для введения в это автотестов хватило на первых парах одной машины, на которой запускались авто-тесты. Ах да, и полигон для ручных тестеров (он то у вас хоть есть?).
Знаете, есть ощущение, что весь Ваш пафос и усердие направлено не на поиск решения, а на поиск препятствий. Хотите поговорим об этом в личной почте? Я уверен, что приемлимое для Вас решение можно найти. Но прежде всего нужно желание. Если его нет — всё остальное бессмысленно.
Знаете, есть ощущение, что весь Ваш пафос и усердие направлено не на поиск решения, а на поиск препятствий. Хотите поговорим об этом в личной почте? Я уверен, что приемлимое для Вас решение можно найти. Но прежде всего нужно желание. Если его нет — всё остальное бессмысленно.
Простите, это был унаследованный проект, или разработанный вами? Вам были подконтрольны и известны все его части, или нет?
Унаследованный. Страшный гавнокод. В некоторые его части отказывались лезть даже самые бесстрашные программисты :). Опять таки — потому что небыло тестов, и понять, сломал ты что-то или нет — не возможно.
К счастью, для автоматизированных тестов (как и для пользователя) это всё не важно. Да, конечно, хороше бы ещё и базу контроллировать, но изменения в БД, в своих модулях Вы то, наверное, знаете.
К счастью, для автоматизированных тестов (как и для пользователя) это всё не важно. Да, конечно, хороше бы ещё и базу контроллировать, но изменения в БД, в своих модулях Вы то, наверное, знаете.
Значит, контроль над базой вам не нужен? Ну оок.
Вот есть модуль управления контрагентами. Пока контрагент новый — можно вводить только часть информации, как только она введена — можно вводить всю остальную. И это все, конечно же, унаследованное.
Вам приходит CR на то, чтобы изменить валидацию в части тех данных, которые можно вводить только пока контрагент новый. Ваши действия?
Ах, да, малозначительная деталь (которую вы узнаете только на второй день тестирования): контрагенты при вводе проверяются на уникальность ИНН.
Вот есть модуль управления контрагентами. Пока контрагент новый — можно вводить только часть информации, как только она введена — можно вводить всю остальную. И это все, конечно же, унаследованное.
Вам приходит CR на то, чтобы изменить валидацию в части тех данных, которые можно вводить только пока контрагент новый. Ваши действия?
Ах, да, малозначительная деталь (которую вы узнаете только на второй день тестирования): контрагенты при вводе проверяются на уникальность ИНН.
>>Вам приходит CR на то, чтобы изменить валидацию в части тех данных, которые можно вводить только пока контрагент новый. Ваши действия?
Что мешает создавать свежего пользователя и проверять? Что мешает сделать действия для получения статуса «старый» и провести отрицательный тест? (если нет порядка действий — то ведь и вручную это не проверить, правда?)
>>контрагенты при вводе проверяются на уникальность ИНН.
В чём проблема добавлять некую временно-зависимую велечину в ИНН? В чём проблема попытаться создать подряд 2х пользователей с одинаковым ИНН?
И самый главный вопрос, а «мартышки» то как этот вопрос решают?
Посмотрите внимательно — вместо того, чтоб найти в своём проекте вещи, которые можно начать автоматизировать, Вы старательно пытаетесь найти то, что автоматизировать нельзя. Да, может быть Вы такое и найдёте (поищите в стороне использования стороннего API, желательно банковского). Но это не значит, что остальную, весьма значительную часть проекта невозможно покрыть автоматизированными тестами.
Что мешает создавать свежего пользователя и проверять? Что мешает сделать действия для получения статуса «старый» и провести отрицательный тест? (если нет порядка действий — то ведь и вручную это не проверить, правда?)
>>контрагенты при вводе проверяются на уникальность ИНН.
В чём проблема добавлять некую временно-зависимую велечину в ИНН? В чём проблема попытаться создать подряд 2х пользователей с одинаковым ИНН?
И самый главный вопрос, а «мартышки» то как этот вопрос решают?
Посмотрите внимательно — вместо того, чтоб найти в своём проекте вещи, которые можно начать автоматизировать, Вы старательно пытаетесь найти то, что автоматизировать нельзя. Да, может быть Вы такое и найдёте (поищите в стороне использования стороннего API, желательно банковского). Но это не значит, что остальную, весьма значительную часть проекта невозможно покрыть автоматизированными тестами.
Что мешает создавать свежего пользователя и проверять?
Уникальность ИНН.
В чём проблема добавлять некую временно-зависимую велечину в ИНН?
Вы не в курсе, как формируется ИНН?
В чём проблема попытаться создать подряд 2х пользователей с одинаковым ИНН?
Если первый создастся, то второй — нет.
И самый главный вопрос, а «мартышки» то как этот вопрос решают?
Анализом существующих данных и выбором подходящих значений.
Посмотрите внимательно — вместо того, чтоб найти в своём проекте вещи, которые можно начать автоматизировать, Вы старательно пытаетесь найти то, что автоматизировать нельзя.
Я вам просто привел один из примеров. В реальности же именно таких ситуаций в системе (известной мне части) преобладающее большинство. Чтобы их решить, нужна самая малость — полный контроль над БД.
Нет смысла тратить усилия на автоматизацию 5%, если очевидно, что остальные 95% автоматизировать тем же подходом нельзя. Это будет автоматизация ради автоматизации, без какой-либо глобальной цели.
>>Анализом существующих данных и выбором подходящих значений.
Ну и о чём тогда разговор? :) Знаете, с помощью селениума можно даже в админке искать пользователей, и уж тем более анализировать выборку.
Подумайте, какие конкретно действия ручных тестеров нельзя автоматизировать?
Ну и о чём тогда разговор? :) Знаете, с помощью селениума можно даже в админке искать пользователей, и уж тем более анализировать выборку.
Подумайте, какие конкретно действия ручных тестеров нельзя автоматизировать?
Подумайте, какие конкретно действия ручных тестеров нельзя автоматизировать?
Нет таких действий. Вопрос только в том, сколько будет стоить эта автоматизация.
Про что вам с самого начала и сказали.
>>Нет таких действий.
Отлично, значит автоматизация всё таки возможна. Уже радует.
>>Вопрос только в том, сколько будет стоить эта автоматизация.
Просто посчитайте, сколько раз ручные тестеры делают одно и тоже действие, тестируя ВСЮ систему перед каждым релизом (или — ну его нафиг, и так прокатит?)
тут как с JIT компиляторами — автоматизируйте действия, которые выполняются 80% времени (а это, как правило, 20% функционала) и вы получите хорошее снижение стоимости тестирования
Отлично, значит автоматизация всё таки возможна. Уже радует.
>>Вопрос только в том, сколько будет стоить эта автоматизация.
Просто посчитайте, сколько раз ручные тестеры делают одно и тоже действие, тестируя ВСЮ систему перед каждым релизом (или — ну его нафиг, и так прокатит?)
тут как с JIT компиляторами — автоматизируйте действия, которые выполняются 80% времени (а это, как правило, 20% функционала) и вы получите хорошее снижение стоимости тестирования
Отлично, значит автоматизация всё таки возможна. Уже радует.
Никто никогда не говорил, что она невозможна. Я всего лишь говорил о ее стоимости.
Просто посчитайте, сколько раз ручные тестеры делают одно и тоже действие, тестируя ВСЮ систему перед каждым релизом (или — ну его нафиг, и так прокатит?)
Заказчику не нужно сплошное тестирование всей системы перед каждым релизом. Он не готов и отказывается за него платить.
Подождите, Покрытия у вас нет… Полностью систему перед релизом не проверяете…
Тоесть, по сути никто не знает, работает ли система целиком, и как…
Извините, но это подход Х**к, Х**к и в продакшн. И если Вас это устраивает — то да, автотесты вам не нужны. Зачем же Вам бесполезное качество? :)
Тоесть, по сути никто не знает, работает ли система целиком, и как…
Извините, но это подход Х**к, Х**к и в продакшн. И если Вас это устраивает — то да, автотесты вам не нужны. Зачем же Вам бесполезное качество? :)
Это не нас устраивает, а заказчика. И он не готов платить за полный ретест системы.
Собственно, о чем я вам и говорю с самого начала: стоимость приемочных тестов может быть выше, чем экономически оправданно для разработки.
Собственно, о чем я вам и говорю с самого начала: стоимость приемочных тестов может быть выше, чем экономически оправданно для разработки.
Например, заметить интуитивно аномальное значение, а то их последовательность, исследовать контекст и решить это просто статистический всплеск или баг.
Вот, например, приложение, которое я долго покрывал тестами широко использует случайные числа. С помощью инъекций, рефлексий и т. п., на уровне юнит-тестов я всё же проблему решил. Но вот на приемочных я просто не представляю как это делать, чтобы исключить как ложноположительные, так и ложноотрицательные срабатывания. Рандом — он такой рандом, любые последовательности равноверотны.
Вот, например, приложение, которое я долго покрывал тестами широко использует случайные числа. С помощью инъекций, рефлексий и т. п., на уровне юнит-тестов я всё же проблему решил. Но вот на приемочных я просто не представляю как это делать, чтобы исключить как ложноположительные, так и ложноотрицательные срабатывания. Рандом — он такой рандом, любые последовательности равноверотны.
>>Например, заметить интуитивно аномальное значение
Простите, что? Именно это авто тесты и делают лучше всего — «замечают аномальные значения» :). Или у вас как — если бага встретилась случайно, то ну её нафиг, авось пользователь не заметит?
>>Рандом — он такой рандом, любые последовательности равноверотны.
Конечно. Поэтому есть понятие экстримальных значений. Идея — найти такие входные данные(методом анализа), на которых Ваше приложение скорее всего упадёт. Если не упадёт на них, то скорее всего и внутри интервала будет всё отлично.
Простите, что? Именно это авто тесты и делают лучше всего — «замечают аномальные значения» :). Или у вас как — если бага встретилась случайно, то ну её нафиг, авось пользователь не заметит?
>>Рандом — он такой рандом, любые последовательности равноверотны.
Конечно. Поэтому есть понятие экстримальных значений. Идея — найти такие входные данные(методом анализа), на которых Ваше приложение скорее всего упадёт. Если не упадёт на них, то скорее всего и внутри интервала будет всё отлично.
Утрированный пример: где-то в программе складывается 10 случайных чисел от 1 до 9 (не важно зачем, так надо), от входных данных никак не зависит. Диапазон получается от 10 до 90 со средним значением 50. Диапазон мы проверить можем. Но как автоматическим тестом проверить, что не допущена ошибка и вместо случайного числа от 1 до 9 не выдаётся всегда константа?
Глазками мы увидим большую последовательность одних чисел, залезем в код, трижды проверим, что всё правильно и это лишь статистический выплеск, и с лгким сердцем отправим в продакшен. А как писать автотест? Ведь мы знаем, что в теории может быть сколько угодно длинная последовательность одинаковых чисел столь же вероятная как другая.
Глазками мы увидим большую последовательность одних чисел, залезем в код, трижды проверим, что всё правильно и это лишь статистический выплеск, и с лгким сердцем отправим в продакшен. А как писать автотест? Ведь мы знаем, что в теории может быть сколько угодно длинная последовательность одинаковых чисел столь же вероятная как другая.
Это ручные тестеры в код то залезут?
Ваш пример звучит как «где то в программе, сферический конь в вакууме», и по звуку из колонок можно понять что он заболел и кашляет.
Если Вы работаете профессионально, то у вас должны быть тестеры, и должны быть прописанные тест кейсы, верно? На основании тест кейсов и можно автоматизировать.
Если в программе есть елемент случайности, то обычно он создан с некой целью (скажем — чтобы два последовательно идущих документа имели разный номер). И исходя из этой цели можно построить авто-тест.
Если же Ваша программа не решает никаких задач — то да, автоматизировать её бессмысленно.
Ваш пример звучит как «где то в программе, сферический конь в вакууме», и по звуку из колонок можно понять что он заболел и кашляет.
Если Вы работаете профессионально, то у вас должны быть тестеры, и должны быть прописанные тест кейсы, верно? На основании тест кейсов и можно автоматизировать.
Если в программе есть елемент случайности, то обычно он создан с некой целью (скажем — чтобы два последовательно идущих документа имели разный номер). И исходя из этой цели можно построить авто-тест.
Если же Ваша программа не решает никаких задач — то да, автоматизировать её бессмысленно.
Игра. Тестер скажет мне, я полезу в код.
Отлично, требования то к игре у вас есть? И на что конкретно влияют случайности?
Да, не всё и не с первого раза вы покроете. Но то что покроете — не нужно больше трогать. Всё, этот функционал всегда рабочий.
Да, не всё и не с первого раза вы покроете. Но то что покроете — не нужно больше трогать. Всё, этот функционал всегда рабочий.
Что руками, что автоматизировано, это решается только через статистический анализ. Считаем 1000 раз, оцениваем мат. ожидание, дисперсию и форму распределения.
Самая простая и довольно распространенная ситуация: есть ТЗ, сделали его, отдали заказчику, он принял, а дальше хоть трава не расти.
Было бы еще круче: «Сделайте как я хочу, но как я не скажу, а проверять буду со всей строгостью!». ;)
Как-то на моей практике приемочные тесты приносят пользу если только заказчик понимает, что это такое, а в идеале их сам и пишет. А так хватает функциональных и модульных.
Функциональное тестирование — это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. (с) Википедия
Вообще то приёмочные тесты — это функциональные, которые назвали по другому :)
Вообще то приёмочные тесты — это функциональные, которые назвали по другому :)
Для меня приемочные, если брать внешнюю сторону, это эмуляция работы пользователя, вплоть до указания координат кликов. Функциональные — отправка http запросов, анализ ответов или, максимум, инициирование тех или иных DOM событий и сравнение изменений в DOM с ожидаемыми. Если уж совсем на пальцах, то приемочные для меня «кликнуть кнопку и проверить результат визульно», а функциональные — «эмулировать нажатие кнопки и проверить результат в памяти». Ключевое отличие — кнопка может оказаться невидимой пользователю, как и результат, не смотря на выставление флогов типа visible.
На самом деле, мне, как заказчику, не выгодно раскрывать разработчикам мои методы тестирования при приёмке: с моей точки зрения возрастёт риск того, что они просто заточат продукт под прохождение именно этих тестов. Как заказчик я хочу указать фуцкциональность, а уж как я её собираюсь тестировать — это моё дело.
На деле сталкивался с двумя крайностями более, чем с серединой:
1) Безответственный и непонимающий заказчик, имеющий малый бюджет, который никогда не поймет важость автотестов, нормальных требований и не будет дрючить за каждый час в эстимэйте. Такому предлагать все это — как об стену горох, проще сделать что-то более-менее работающее — ему в 90% случаев хватит. Спасает то, что проекты у таких заказчиков в основном малые, поэтому дорасти до критической стадии спирали он не может. Хотя у меня был один большой проект с такими заказчиками — это было ужасно.
2) Богатый и умный заказчик, у которого хватает бюджета на тесты, и он сам заставляет их писать. Были бы все такими… На хороших, серьезных продуктах тоже так.
А вот посередине за 3.5 лет в аутсорсинге почти не встречал. Либо — да, да, я понимаю, давайте тесты напишем после 1 релиза, а то еще идея не окупится. А потом — да, я все понимаю, но нужен срочный апдейт, итак же все работает.
Либо — ребята, мы все понимаем, вот вам 2-3 недели, сделайте как считаете нужным но чтобы не крашилось.
1) Безответственный и непонимающий заказчик, имеющий малый бюджет, который никогда не поймет важость автотестов, нормальных требований и не будет дрючить за каждый час в эстимэйте. Такому предлагать все это — как об стену горох, проще сделать что-то более-менее работающее — ему в 90% случаев хватит. Спасает то, что проекты у таких заказчиков в основном малые, поэтому дорасти до критической стадии спирали он не может. Хотя у меня был один большой проект с такими заказчиками — это было ужасно.
2) Богатый и умный заказчик, у которого хватает бюджета на тесты, и он сам заставляет их писать. Были бы все такими… На хороших, серьезных продуктах тоже так.
А вот посередине за 3.5 лет в аутсорсинге почти не встречал. Либо — да, да, я понимаю, давайте тесты напишем после 1 релиза, а то еще идея не окупится. А потом — да, я все понимаю, но нужен срочный апдейт, итак же все работает.
Либо — ребята, мы все понимаем, вот вам 2-3 недели, сделайте как считаете нужным но чтобы не крашилось.
Технология привязки к проекту любимого фреймворка для юнит-тестов у каждого разработчика должна быть отработана до автоматизма, занимать 5 минут и выполнятся вторым действием — сразу же после создания файла нового проекта. Точно также, как у админа — привязка запуска тестов к билд-серверу. И это всё должно происходить всегда, независимо от наличия тестов в данный момент, планов по их написанию и т.д. Это просто надо делать. Это даже можно автоматизировать.
А что касается «да, я все понимаю, но нужен срочный апдейт» — отлично, всегда нужен срочный апдейт. Что мешает писать тесты по-немножку? Сегодня один, завтра — еще два, тут 10 минут на написание тестов, а послезавтра — есть целый час свободный. И не успеешь оглянуться — а у тебя их уже целая куча. Разработчиков, заявляющих что-то типа «так, мы не писали тестов год и теперь нам нужно 2 недели только на тесты — не трогайте нас» лично я не понимаю — это как «надо в воскресенье выспаться за всю неделю».
А что касается «да, я все понимаю, но нужен срочный апдейт» — отлично, всегда нужен срочный апдейт. Что мешает писать тесты по-немножку? Сегодня один, завтра — еще два, тут 10 минут на написание тестов, а послезавтра — есть целый час свободный. И не успеешь оглянуться — а у тебя их уже целая куча. Разработчиков, заявляющих что-то типа «так, мы не писали тестов год и теперь нам нужно 2 недели только на тесты — не трогайте нас» лично я не понимаю — это как «надо в воскресенье выспаться за всю неделю».
А вот давайте вы не будете путать юнит-тесты с приемочными?
С юнит-тестами-то все просто (относительно), только заказчику их не покажешь и в ПМИ не запишешь.
С юнит-тестами-то все просто (относительно), только заказчику их не покажешь и в ПМИ не запишешь.
Из топика:
" Таким образом, добавляется возможность с помощью приемочных тестов в любой момент времени проверить, работает ли та или иная функциональность в продукте после любых изменений. Запустить эти автоматизированные приемочные тесты может любой, обычно они добавляются к Continuous Integration серверу и запускаются на каждое изменение или в ручном режиме."
А теперь покажите-ка мне эту неуловимую разницу между юнит-тестами и приемочными тестами в понимании автора статьи?
" Таким образом, добавляется возможность с помощью приемочных тестов в любой момент времени проверить, работает ли та или иная функциональность в продукте после любых изменений. Запустить эти автоматизированные приемочные тесты может любой, обычно они добавляются к Continuous Integration серверу и запускаются на каждое изменение или в ручном режиме."
А теперь покажите-ка мне эту неуловимую разницу между юнит-тестами и приемочными тестами в понимании автора статьи?
Юнит-тестами мы проверяем код отдельных юнитов, функциональными/приемочными их взаимодействие.
Т.е. если у меня написано в тесте ASSERT(class1.method() == 5), то это юнит-тест, а если ASSERT( class2.method2( class.method()) == 5) — то это уже приемочный тест? И его уже можно показывать заказчику — а вот первый нельзя?
Мне кажется заказчику вполне можно показать и обычные юнит-тесты: их количество, охват кода, запустить — и показать сколько прошло. Если разработчик не дурак — он сам эти тесты будет писать так, чтобы они не от балды методы тестили, а проверяли какие-то реальные рабочие схемы.
Мне кажется заказчику вполне можно показать и обычные юнит-тесты: их количество, охват кода, запустить — и показать сколько прошло. Если разработчик не дурак — он сам эти тесты будет писать так, чтобы они не от балды методы тестили, а проверяли какие-то реальные рабочие схемы.
Приемочный тест (в моём понимании) действует на уровне UI или максимально к нему приближенном.
А в вашем втором тесте я бы скорее всего использовал стаб или вообще константу или фикстуру вместо вызова class.method(). Но даже без этого он не станет приемочным тестом, и даже вряд ли функциональным, скорее интеграционным.
А в вашем втором тесте я бы скорее всего использовал стаб или вообще константу или фикстуру вместо вызова class.method(). Но даже без этого он не станет приемочным тестом, и даже вряд ли функциональным, скорее интеграционным.
Модульными тестами хороший разработчик покрывает код, чтобы убедиться, что его точечная идея для класса, функции, метода или их связки работает правильно. К сожалению, модульные тесты не способны обеспечить проверку даже возможности запуска приложения, не говоря уже о его функциях. Плюс, приемочные тесты написаны на языке, понятном заказчику, в отличии от модульных тестов. Если искать связь, то модульные тесты рождаются из приемочных, в то же время играя роль приемочных тестов на уровне кода.
написаны на языке, понятном заказчику
Очень большая редкость :) Даже если используется специализированный DSL.
Приемочные тесты проверяют функциональность продукта (причем в терминах требований). Я знаю исключительно мало продуктов, чью функциональность можно проверить тестом изолированного компонента.
Я лично трачу больше времени на тесты, чем на написание кода, который нужно проверять. Так что утверждение спорно. Приведу пример SQLite, когда у них кода тестов в 99 раз больше, чем кода самой SQLite.
А сколько времени Вы тратите на тестирование? Вы ведь понимаете, что внося изменения, например, в ядро — Вы запросто можите отломать что-то на другом конце приложения?
Вы считаете только стоимость кода, но в масштабном, долгоразвивающимся качественном приложении довольно большие средства вложены в тестирование.
Вы считаете только стоимость кода, но в масштабном, долгоразвивающимся качественном приложении довольно большие средства вложены в тестирование.
Не поймите меня неправильно, я целиком ЗА автоматическое тестирование и сейчас, работая в продуктовой компании со спокойными дедлайнами, я постоянно пишу тесты.
Но в том мире, откуда я пришел, мире дикого мелкого аутсорсинга, уговорить заказчика на автотесты в большинстве случаев нереально — он скажет пиши, а потом будет каждый день натягивать команду за производительность и сравнивать с быдлоиндусами, которые из разряда хуяк-хуяк и в продакшн.
Но в том мире, откуда я пришел, мире дикого мелкого аутсорсинга, уговорить заказчика на автотесты в большинстве случаев нереально — он скажет пиши, а потом будет каждый день натягивать команду за производительность и сравнивать с быдлоиндусами, которые из разряда хуяк-хуяк и в продакшн.
Казалось бы, всё просто:
Проект готов — заказчик вправе пользоваться, проектроовщик вправе получить гонорар.
Далее, если проект готов полностью, и заказчик вполне убедился в этом то зачем вообще нужна помощь со стороны проектировщика?
Здесь упускается из виду, что как только изменилось какое-нибудь из важных, пусть и неявных, конкретных технических требований — это, извините меня, уже другой проект; и хотя редко кто об этом говорит, почти все это понимают.
Либо, есть требование вечной жизни проекта — явное или нет: чтобы последняя часть жизненного цикла, т.е. стадия, соответствующая пункту «Эксплуатация и сопровождение» водопадной модели, была бесконечной и/или бесплатной.
С этой точки зрения, первородный грех всякого программного проекта — его отклонение от водопадной модели, предполагающей последовательный, целенаправленный рост и в конечном счёте — практическое и доказанное, гарантированное достижение требований.
Если требования — это река, в которую, одну и ту же, нельзя войти даже один раз, то риторический вопрос, который ставит данный топик, безусловно, имеет смысл.
Проект готов — заказчик вправе пользоваться, проектроовщик вправе получить гонорар.
Далее, если проект готов полностью, и заказчик вполне убедился в этом то зачем вообще нужна помощь со стороны проектировщика?
Здесь упускается из виду, что как только изменилось какое-нибудь из важных, пусть и неявных, конкретных технических требований — это, извините меня, уже другой проект; и хотя редко кто об этом говорит, почти все это понимают.
Либо, есть требование вечной жизни проекта — явное или нет: чтобы последняя часть жизненного цикла, т.е. стадия, соответствующая пункту «Эксплуатация и сопровождение» водопадной модели, была бесконечной и/или бесплатной.
С этой точки зрения, первородный грех всякого программного проекта — его отклонение от водопадной модели, предполагающей последовательный, целенаправленный рост и в конечном счёте — практическое и доказанное, гарантированное достижение требований.
Если требования — это река, в которую, одну и ту же, нельзя войти даже один раз, то риторический вопрос, который ставит данный топик, безусловно, имеет смысл.
На этапе сопровождения часто меняется только часть функциональности (то есть большая часть действительно превращается в реку, в которую нельзя войти дважды). И вот тогда польза от приемочных тестов колоссальная. Мало того, по ним можно понять как должна была работать та или иная часть приложения. Потому что доменные знания теряются за документами, в которых устаревают практически моментально.
А как же модульность и замораживание кода? Железная линейка для работы над руками «молодыми звездами программирования», которые сами пишут/правят фреймворки и хелперы, не думая о готовых частях проекта?
Понятно, что тесты лишними не будут, но все же, это частичное решение организационной проблемы программистскими методами.
Если процесс поставлен правильно, то всегда можно разделить работу на части для поэтапной сдачи. И если вдруг заказчик говорит «мне понравилась кнопочка Ok в этой форме, сделайте везде так же», ему нужно показывать график сдачи, его же подпись с датой и объяснять, что разморозка всех проектов ради кнопочки «Ok» обойдется в дополнительное тестирование.
Понятно, что тесты лишними не будут, но все же, это частичное решение организационной проблемы программистскими методами.
Если процесс поставлен правильно, то всегда можно разделить работу на части для поэтапной сдачи. И если вдруг заказчик говорит «мне понравилась кнопочка Ok в этой форме, сделайте везде так же», ему нужно показывать график сдачи, его же подпись с датой и объяснять, что разморозка всех проектов ради кнопочки «Ok» обойдется в дополнительное тестирование.
Вы как-то путаете вещи. Да, тесты — это классно. Но они ведь не исправят проект по-волшебству. Они лишь свиснут, когда что-то сломается. А исправлять все-равно надо будет руками. Т.е. тот факт, что «стоимость одной конкретной функциональности будет продолжать расти на протяжении всего проекта» не меняется. Модель поддержки, выгодная аутсорс-компаниям — тоже никуда не пропадает. Единственное, что получает заказчик — чуть более высокую скорость реакция на возникшие баги. Ну так это кому-то надо, а кому-то нет. И заказчику надо честно эту фичу предложить с прайсом на неё: хотите автоматические тесты каждую ночь с оповещением вам и нам — вот столько денег это стоит. Не хотите? Ну как хотите.
Как правило, что-то падает при изменении условия/функционала работы. То есть в основном при внесении изменений в программу/железо/логику/данные. Как правило эти события известны (знаем что сейчас залили кусок кода, поменяли железку на сервере, стали грузить данные в другом формате, etc). И вот тут и приходят тесты. Чтобы сразу же, при внесении изменений, протестировать, ничего ли не сломалось и не отвалилось из-за изменений.
Если баг ловится тестом у разработчика, то он до заказчика просто не дойдёт (или будет внесен в known issues). Как минимум репутационные потери не будет нести разработчик. Далее, если, допустим, тесты гоняет сам заказчик, то баг в какой-то фиче, которую заказчик использует редко, будет выявлен им по горячим следам, его будет проще локализовать с точностью до версии (в 1.07 баг есть, в 1.06 не было), а если разработчик, то с точностью до билда, а то и коммита. А оперативная точная локализация бага сильно снижает стоимость его исправления, хотя бы потому что ещё контекст в оперативной памяти у разработчика, не говоря о том, что за несколько, например, месяцев поверх бага может быть налеплено куча кода, который «думает», что «это не баг, это фича» и нужно будет не просто опечатку исправить, а весь код переписывать.
Я ведь не говорю, что тесты не нужны. Нужны, конечно. Но они не отменяют того факта, что систему все-равно нужно поддерживать. Автор как-то противопоставляет «хороших» разработчиков, которые благодаря тестам создают фичу с не растущей больше стоимостью и «плохих», у которых она растет. На самом деле и там и там растёт, просто с разной скоростью.
За все время моей деятельности я ни разу не встречал заказчика с четко сформированными требованиями на момент начала реализации проекта.
Более того, когда проект более-менее большой — я всегда говорил по поводу того, что нужно встроить автоматизированное тестирование, рассказывал как это помогает. Естественно это стоит отдельных денег, так как нужно дополнительное время. И ни разу ни один заказчик не захотел это реализовать в своем проекте. Хотя многие соглашались, что это нужно. Но платить за это никто не хотел.
Более того, когда проект более-менее большой — я всегда говорил по поводу того, что нужно встроить автоматизированное тестирование, рассказывал как это помогает. Естественно это стоит отдельных денег, так как нужно дополнительное время. И ни разу ни один заказчик не захотел это реализовать в своем проекте. Хотя многие соглашались, что это нужно. Но платить за это никто не хотел.
А вы ему объясните, что в противном случае он будет платить каждый раз за ручное регрессионное тестирование либо просто завалится списком дефектов. И не надо иметь четко сформулированные требования для всего продукта, надо всего лишь на итерацию. Или это тоже нереально из вашего опыта?
в случае «списка дефектов» я 90% отпугну клиента. Так уж сильно утвержать нельзя, получается я говорю, что я сделаю продукт с нереальной кучей дефектов.
По поводу тз на первую итерацию, так абсолютно все хотят точную стоимость в начале разработки. На почасовую оплату можно договориться уже на поддержку или последующий релиз.
По поводу тз на первую итерацию, так абсолютно все хотят точную стоимость в начале разработки. На почасовую оплату можно договориться уже на поддержку или последующий релиз.
С требованиями относительно легко решается. Когда пишем код, то эти требования так или иначе (из заказчика ли клещами вытянули или сделали вроде разумное допущение в уме — не суть) у нас в голове есть, нужно только зафиксировать их на формальном языке тестирующего фреймворка перед тем как писать код (в крайнем случае сразу после того как написали).
А вот деньги и время, это да, проблема. Разве что считать, что эти время и деньги входят в процесс разработки по умолчанию, как, скажем, время на проектирование, отладку или документирование. Но тут можно потерять конкурентное преимущество.
А вот деньги и время, это да, проблема. Разве что считать, что эти время и деньги входят в процесс разработки по умолчанию, как, скажем, время на проектирование, отладку или документирование. Но тут можно потерять конкурентное преимущество.
Проблема в том, что в процессе проектирования во время разработки возникнет куча дополнительной работы, нового функционала. А так как 100% заказчиков хотят фиксировать цену в начале разработки, то получается этот весь новый функционал я уже буду делать за свой счет. Или изначально гадать на кофейной гуще о возможных добавлениях и включать это в первоначальную оценку как «подушку».
Есть правда такие заказчики, которые соглашаются все последующие доделки фиксировать отдельным счетом/договором по факту на основе почасовой оплаты, но их очень мало.
Есть правда такие заказчики, которые соглашаются все последующие доделки фиксировать отдельным счетом/договором по факту на основе почасовой оплаты, но их очень мало.
Так функциональность эта так или иначе возникнет, к тестированию это прямого отношения не имеет. Просто тестирование увеличивает время на разработку и изначальной, и новой/измененной функциональности. Я к тому, что оценивая сроки и стоимость, сразу добавлять процентов 10-15 на тестирование (кроме обычного умножения на «пи» :).
Ну тогда мои цены будут вообще намного выше рыночных и я не смогу конкурировать. Поэтому все у меня прозрачно, хотя в принципе любая оценка проекта — это тыканье пальцем в небо.
Я про это сразу написал. Но, в принципе, есть варианты постепенного покрытия тестами задним числом. Например, первый релиз сдаем без тестов, а вот на допфичи и то, что они могут задеть, тесты уже пишем. Заказчик из-за 10-15% вряд ли будет менять коней на переправе.
ну а смысл делать тесты только для доработок, когда весь основной функционал не покрыт. А если делать тесты и для всего остального, то это может быть дольше чем сами доработки. Вряд-ли кто-то вообще согласится на такое.
Основной считаем что как бы покрыт, типа где-то у заказчика они есть, просто он, редиска, делиться не хочет. Но вот пришёл от заказчика багрепорт или фичереквест — пишем на них тест, а также тесты на то, что наш (будущий) новый код может затронуть. Несколько новых фич или закрытых багов и большая часть кода покрыта тестами, а та что не покрыта с большой вероятностью работает без ошибок или просто заказчик ею не пользуется.
То есть вы предлагает «втихую» делать тесты за счет заказчика? Мне кажется именно это будет обманом. Он в явной форме отказался от того, чтоб я тратил свое время (его деньги) на тесты.
А не надо это предлагать с самого начала :) Вы же не предлагаете, например, оплачивать время проведенное в отладчике и не вводите в смету «кодирование — N часов, отладка M часов»? Не говоря о ручном тестировании (ни разу не слышал, чтобы кто-то отправлял код хотя бы чуть-чуть его не проверив, запускается ли он хотя бы — хотя нет, вру, встречал совсем недавно).
В общем я к тому, чтобы плавно сделать автоматическое тестирование таким же неотъемлемым атрибутом разработки как ручное тестирование или отладка.
В общем я к тому, чтобы плавно сделать автоматическое тестирование таким же неотъемлемым атрибутом разработки как ручное тестирование или отладка.
Опять же возвращаемся к экономическому вопросу. Если бы все мои конкуренты закладывали в понятие разработки и тестирование — тогда бы было все ок. А так у меня и так цены выше среднего, так я еще и разработку буду закладывать. Как результат — потеря клиента.
а если конкуренты завтра скинут 50%, то что тогда?
кто-то берет ценой (читай количеством), а кто-то качеством
кто-то берет ценой (читай количеством), а кто-то качеством
Естественно, я не буду скидывать, но поднимать тоже тяжело для выживания на рынке сегодня. Вот держу «золотую середину».
Ну и плюс можно ваше утверждение добавить:
а если все скинут на 90% и будут делать проекты очень качественно?
Тогда конец мне на этом рынке, буду искать другие пути заработать. Это рынок.
а если все скинут на 90% и будут делать проекты очень качественно?
Тогда конец мне на этом рынке, буду искать другие пути заработать. Это рынок.
А ручное тестирование они оплачивали? Или вы им об этом не сказали? Если нет, зачем говорить об автоматизированном? Оно потому и называется автоматизированным, что экономит время на ручном тестировании. Иначе зачем бы его кто-то придумывал?
а ручное обычно проходит поэтапно самим заказчиком.
То есть разработчики никак не проверяют, что выдает программа? Написал и пошел дальше?
Ну зачем так утрировать:
— пишу
— проверяю на соответсвие того, как я понимаю ТЗ
— если что-то не работает то отлаживаю
— возвращаюсь на два шага назад
— пишу
— проверяю на соответсвие того, как я понимаю ТЗ
— если что-то не работает то отлаживаю
— возвращаюсь на два шага назад
Реализуйте второй пункт как «пишу автотест и запускаю» :)
Я не утрирую, я говорю, что вы считаете время на автотесты, но не считаете время на ручное тестирование.
Это если не работает то, что вы разрабатываете. А если сломалось что-то совсем в другом месте, когда вы об этом узнаете? Как скоро найдете причину и исправите последствия? А если работаете в команде и кто-то сломал вашу функциональность, а вы ни сном ни духом? Все эти времязатраты вы никак не учитываете, не потому, что они мизерные, а просто потому, что привыкли, что это часть процесса разработки. А на самом деле они вполне серьезно съедают время.
Да собственно и при текущей разработке очень часто бывает быстрее написать или скопипастить и слегка подправить один тест, чем щелкать мышкой в браузере.
— если что-то не работает то отлаживаю
Это если не работает то, что вы разрабатываете. А если сломалось что-то совсем в другом месте, когда вы об этом узнаете? Как скоро найдете причину и исправите последствия? А если работаете в команде и кто-то сломал вашу функциональность, а вы ни сном ни духом? Все эти времязатраты вы никак не учитываете, не потому, что они мизерные, а просто потому, что привыкли, что это часть процесса разработки. А на самом деле они вполне серьезно съедают время.
Да собственно и при текущей разработке очень часто бывает быстрее написать или скопипастить и слегка подправить один тест, чем щелкать мышкой в браузере.
я понимаю вашу позицию, но реальность говорит о другом и я об этом писал. Мои проекты не настолько огромные, чтоб из-за отсутсвия тестов возникали такие коллапсы. В случае большого и долгоиграющего процесса тут все правильно написано. А в случае, если проект делает один человек максимум за 3-4 месяца — это все не так актуально.
Ну и плюс причем здесь «щелкать мышкой в браузере»?
Ну и плюс причем здесь «щелкать мышкой в браузере»?
Если ваша реальность такова, и вы не занимаетесь самообманом, я только рад за вас )
Я имел в виду ручной прогон веб-приложения. Можете заменить на просто «щелкать мышью», если пишете для десктопов, или «тапать пальцам», если пишете для мобильных устройств. Или как вы проверяете функциональность без автотестов?
Ну и плюс причем здесь «щелкать мышкой в браузере»?
Я имел в виду ручной прогон веб-приложения. Можете заменить на просто «щелкать мышью», если пишете для десктопов, или «тапать пальцам», если пишете для мобильных устройств. Или как вы проверяете функциональность без автотестов?
это не моя реальность, это реальность вокруг меня. Лично я очень люблю тесты и в своих проектах их использую, я умею ими пользоваться и поэтому предлагаю своим клиентам. Но повторяю еще раз — я не хочу это делать за свой счет. Писать приложения, которые пройдут процесс приемки/передачи проекта клиенту быстрее (и ощутимо быстрее) без тестов, чем с ними. Я не делаю такого количества ошибок за 3 месяца, чтоб это выливалось в такие трудозатраты. Я уже не говорю о проектах размером в 100-200 часов.
Для меня подходит «тапать мальцами» :-)
Для меня подходит «тапать мальцами» :-)
Да, пожалуй в вашей сфере деятельности (стоило ее уточнить) дела обстоят именно так, функциональные тесты дороги или невозможны, небольшие размеры проектов и небольшие требования к надежности. Однако это весьма небольшая часть индустрии разработки ПО. Стоит подняться размеру, или требованиям надежности, и без тестового набора регрессионные баги быстро съедят всю экономию на тестах.
Ну и тестирование — это не функциональность продукта, а часть процесса разработки, это не дело клиента — решать, каким образом вы обеспечиваете качество продукта, а только ваше.
Ну и тестирование — это не функциональность продукта, а часть процесса разработки, это не дело клиента — решать, каким образом вы обеспечиваете качество продукта, а только ваше.
Задумайтесь, стоит ли продолжать обманывать своего заказчика. Или лучше работать так, чтобы можно было гордиться результатами своего труда...
Стоит :) вполне заметную сумму денег стоит.
А за «гордиться» денег обычно не получается получать.
Кроме тестов не хватает еще списка принятых решений, ограничений и т.п.
Для примера «мы приняли решение значение Н ограничить только целым типом» (так как в ТЗ указано не было).
Чтобы этот список ограничений можно было передать следующей команде при доработке (иначе уже клиент их обманет — попросив доделать то, на что система принципиально не рассчитана).
Ну если за деньги говорить, то может лучше тогда просто «киданием» заниматься? :)
А по поводу ограничений, решений и т.д. я полностью согласен. Большая часть этого входит в нефункциональные требования. Они не выражаются в приемочных тестах, а переходят в более специфические виды тестов (нагрузочные, производительности, безопасности, юзабилити, доступности). Но если они останутся только на бумаге, то контролировать через некоторое время будет просто нереально…
А по поводу ограничений, решений и т.д. я полностью согласен. Большая часть этого входит в нефункциональные требования. Они не выражаются в приемочных тестах, а переходят в более специфические виды тестов (нагрузочные, производительности, безопасности, юзабилити, доступности). Но если они останутся только на бумаге, то контролировать через некоторое время будет просто нереально…
тесты — это единственная актуальная спека проекта, в которой должны отражаться все принятые решения
Подобные принятые решения можно фиксировать в тестах.
Эта модель выгодна аутсорсинговым компаниям. Ведь в этом случае заказчик «попадает в рабство» и постоянно платит даже за то, что уже давно оплачено и должно работать. А как только регрессионная спираль выходит на новый большой виток, то можно нанять еще тестировщиков, к ним тест-лида, тест-менеджера и понеслась…
Не надо объяснять злым умыслом то, что можно объяснить человеческом глупостью [добавлю: и ленью] ©
Никто не будет специально выдавать дырявый продукт, нанимать армию тестеров и терпеть наезды клиента вместо того, чтобы просто делать еще один кусок функционала, который обещали еще полгода назад. По крайней мере на на конкурентном рынке.
Клиенты тоже не идиоты, чтобы платить все больше и получать все меньше, если, конечно, они платят свои собственные деньги.
Работаю в одном таком проекте — тестов нет. Рефакторинг невозможен. Ручное тестирование всё больше и больше. Что-либо поменять страшно — непонятно будет ли работать ранее сделанный функционал.
Переодически, пишу заказчику слёзные письма, объясняю про тесты — не соглашается. Просто молча включить их в бюджет нельзя, т.к. они больше бюджета любой новой фичи. В самом начале молча их включить тоже было нельзя, т.к. закказчик говорил что-то про KISS, про то как всё дорого и про то что нужно ещё сделать первую версию ещё попроще и быстрее.
Каждая версия, включая первую, задумывалась как последняя (новый функционал никогда не планировался)
А, да самое интересно, заказчик никогда не тестирует проект маленькими частями, на простых случаях. Вместо это сразу в самую сложную боевую обстановку, если находится баг — как шерлоки холмсы — пару дней пытаемся установить его причину. Тоже говорит это его принцип работы — ведь только «поведение программы в реальом мире» важно.
Вот так, и переплачивает заказчик за каждую новую фичу раза в три больше, так как время на всю эту ерунду приходится включать в стоимость.
Переодически, пишу заказчику слёзные письма, объясняю про тесты — не соглашается. Просто молча включить их в бюджет нельзя, т.к. они больше бюджета любой новой фичи. В самом начале молча их включить тоже было нельзя, т.к. закказчик говорил что-то про KISS, про то как всё дорого и про то что нужно ещё сделать первую версию ещё попроще и быстрее.
Каждая версия, включая первую, задумывалась как последняя (новый функционал никогда не планировался)
А, да самое интересно, заказчик никогда не тестирует проект маленькими частями, на простых случаях. Вместо это сразу в самую сложную боевую обстановку, если находится баг — как шерлоки холмсы — пару дней пытаемся установить его причину. Тоже говорит это его принцип работы — ведь только «поведение программы в реальом мире» важно.
Вот так, и переплачивает заказчик за каждую новую фичу раза в три больше, так как время на всю эту ерунду приходится включать в стоимость.
По-моему, вы переплачиваете гораздо больше заказчика собственными нервами. Попробуйте добавлять тесты постепенно, на те куски, которых касаетесь, по-крайней мере будет какая-то уверенность в собственном коде, а так могу только посочувствовать, отдельного бюджета на тесты вам никогда не выделят.
Да, может быть. Беда ещё в том что это прокси (http+https) сервер на perl. В работе которого нужны ещё и другие proxy сервера. Unit тесты там конечно нужны но не не очень помогут. А для интеграционных тестов и реальных тестов с сокетами нужно вначале сделать нечно довольно трудоёмкое. Написать довольно много кода (фиктивный клиент и фиктивный сервер и фиктивные прокси сервера), пока оно не начнёт работать.
Хотя да, здорово будет написать тесты в своё личное время, не отдавать их заказчику и экономить время на саппорте.
Хотя да, здорово будет написать тесты в своё личное время, не отдавать их заказчику и экономить время на саппорте.
А есть возможность дампать данные с продакшена?
Ну можно, но «другие прокси сервера» во первых часто привязаны к IP проакшена, во вторых половина из них полуживые (некоторые фичи как раз относятся к отсеиванию мёртвых прокси), в третьих часто обновляются. Так что по идее мне нужно написать свой а) полуживой прокси б) живой прокси в) мёртвый прокси. А если я с продакшена буду брать эти прокси, то я не знаю какой из них живой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не обманывайте своих заказчиков