Не обманывайте своих заказчиков

    Это мой первый пост на Хабре, поэтому не судите строго. Я достаточно много занимаюсь не только разработкой, но и постановкой процессов, в том числе тестирования. И всегда несколько скептически относился к ручному тестированию, точнее к той его части, которая отвечает за «обеспечение работоспособности существующей фунциональности» (в простонародье регрессионное тестирование). Что же плохого в этом тестировании и почему многие компании его тогда используют? Кто интересуется ответом на эти вопросы, могут потратить еще пару минут на дальнейшее чтение.

    Корень проблемы


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

    Но вот проходит месяц-другой и выясняется неприятная деталь — на тестирование тратится все больше и больше времени. Оно вполне логично — ведь готовой функциональности в продукте становится все больше и надо постоянно контролировать, что она по-прежнему работает. Это эффект называется «регрессионная спираль смерти» (термин подсмотрен в выступлении Макса Дорофеева «Обезьянки против Роботов»). Эта спираль развивается со временем и становится все шире и шире. И если раньше тестировщики успевали «пробежаться» по продукту за несколько часов, то вскоре на это начинает уходить несколько дней.

    Ну и где же тут обман?


    Все очень просто — отдавая заказчику «готовую» работу мы не даем ему способа бесплатно и легко контролировать ее работоспособность в будущем. Утрируя, это может звучать так: «Мы закончили работать над X, Y и Z. Но уже через пару недель есть шансы, что они перестанут работать нормально...» Но как же так? Ведь заказчик заплатил за полное завершение работ. Как же ему теперь быть? Ему предлагается очень простое решение — плати нам постоянно дополнительную плату за то, что мы будем контролировать работоспособность на протяжении жизни продукта.

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

    Кому это все нужно?


    Почему же при всей ущербности подобной модели она не перестанет применяться? Тут есть несколько причин:

    • Эта модель выгодна аутсорсинговым компаниям. Ведь в этом случае заказчик «попадает в рабство» и постоянно платит даже за то, что уже давно оплачено и должно работать. А как только регрессионная спираль выходит на новый большой виток, то можно нанять еще тестировщиков, к ним тест-лида, тест-менеджера и понеслась...
    • Многим заказчикам объясняют, что «это нормальный подход в IT» и так все работают. Многие из них даже не догадываются об обмане и соответственно не пытаются с ним бороться.
    • Так исторически сложилось в компании и она делает все проекты «по накатанной». Никто не пытается проанализировать варианты улучшения процесса разработки, а уж тем более воплотить их в жизнь.


    При этом, во многих современных продуктовых компаниях к такого рода затратам относятся скептически и не поддерживают идею ручного регрессионного тестирования. В таких компаниях нет позиции monkey тестировщика, так привычной для рынка аутсорсинга.

    Решение проблемы


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

    Дальше хорошая команда снабжает эти критерии приемки конкретными примерами, данными и «прикручивает» к работающему продукту. Таким образом, добавляется возможность с помощью приемочных тестов в любой момент времени проверить, работает ли та или иная функциональность в продукте после любых изменений. Запустить эти автоматизированные приемочные тесты может любой, обычно они добавляются к Continuous Integration серверу и запускаются на каждое изменение или в ручном режиме.

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

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

    Заключение


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

    UPD: По стечению обстоятельств в тот же день на глаза попались две интересные статьи про командное написание приемочных тестов и эволюцию необходимости таких тестов к запуску в облаке. Обе статьи на английском.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 218
    • +17
      не все и не везде можно покрыть автотестами
      • +4
        Я согласен. К примеру как можно покрыть автоматическими тестами 3д игру?
        • +8
          А фонарик в мобилке? :)
          • +1
            Можно, если производитель этим заморочится. Самое элементарное — стенд с фотодиодом. Посмотрите промо-видео на youtube, как Samsung тестирует свой S3. Видео, к сожалению, не содержит теста вспышки, но думаю, что он должен быть.
            • +2
              мне почему-то кажется, что пример с самсунгом немного не об этом, ведь заказчик такой штуки скорее всего был внутри компании и тесты S3 это стезя разработки, а не внешних отношений, как предлагается в статье.

              может-ли внешний заказчик доверять автотестам? каким образом он можно убедиться, что приемочные автотесты:

              1. полны (покрывают достаточный объем функциональности)?
              2. состоятельны (действительно что-то проверяют, а не рисуют зеленые полоски «от балды»)?
              3. адекватны (приложение в продакшене будет вести себя так же как в среде тестирования)?
              4. экономически выгодны (стоимость их внедрения, разработки и поддержки будет ниже, чем у альтернатив)?
              • +1
                П.1 и 3 решается совместным подписанием ПМИ (и без него в пиемочных тестах нет никакого смысла).
                П.2 решается ручным прогоном тех же самых тестов.
                Наконец, п.4 решается рынком и левой пяткой заказчика.

                И на самом деле, все эти пункты не зависят от того, автоматизированы ли приемочные тесты, или нет.
                • +2
                  Вот что удивляет — когда в таких обсуждениях всплывают организационные или юридические вопросы. Как будто введение автоматического или автоматизированного тестирования что-то меняет, как будто ручного тестирования своих продуктов никто никогда не делает, а просто дают заказчику «мы тут написали что-то, но что получилось не проверяли — на, смотри сам». Или как будто считают возможным сдать очередной билд с явными регрессиями в надежде, что заказчик при приемке не станет тестировать уже проверенную им когда-то функциональность.

                  • +1
                    Каких «таких»?

                    Понимаете ли, посыл поста не в том, чтобы делать автоматизированное тестирование. Посыл поста в том, чтобы включать его в критерии готовности продукта — то есть, обсуждать и согласовывать с заказчиком. А это, в свою очередь, означает организационные и юридические вопросы.

                    Как будто введение автоматического или автоматизированного тестирования что-то меняет,

                    Конечно, меняет. Меняет стоимость разработки.

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

                    Ситуации, когда при сдаче билда не проводится регрессионное тестирование под лозунгом «да что там могло сломаться» — весьма распространены.
                    • 0
                      Посыл поста в том, чтобы включать его в критерии готовности продукта.


                      В посте вроде не указано, что об этом критерии должен знать заказчик. Он вполне может быть и внутренним критерием готовности продукта, о котором заказчик ничего не знает, в лучшем случае получает инфу типа «мы новую фичу сделали, начали тестировать и увидели, что старая отвалилась, сейчас чиним, потому небольшая задержка», а как тестировали — ручками или автотестами — заказчика особо и не должно волновать.

                      Конечно, меняет. Меняет стоимость разработки.


                      Я про организационные вопросы в отношениях с заказчиком.

                      Ситуации, когда при сдаче билда не проводится регрессионное тестирование под лозунгом «да что там могло сломаться» — весьма распространены.


                      Я, скорее, про ситуации, когда провели, что-то некритичное сломалось, но билд всё равно выкатывается под лозунгом «дедлайн на носу, дадим что есть, а потом скажем, что нашли регрессию уже после сдачи и вот новый билд с его исправлением».
                      • 0
                        В посте вроде не указано, что об этом критерии должен знать заказчик.


                        Ну здрасте пжалста. Цитата (выделение мое):

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


                        Что характерно, это второй раз, когда я цитирую эту фразу.

                        Я про организационные вопросы в отношениях с заказчиком.

                        А стоимость разработки заказчика не волнует, типа?

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

                        А эта ситуация как раз возникает тогда, когда у заказчика нет приемочных тестов.
                        • 0
                          Ну здрасте пжалста. Цитата (выделение мое):


                          Заказчик формулирует критерии на своем языке, а разработчики переводят их на язык автотестов. Заказчик волен проверять свои критерии любым способом. То, что это должны быть тесты, разработанные исполнителем — лишь одна из опций. Он может по списку критериев в простой письменной форме пробежаться ручками, может нанять кого-то для этих целей, может проверить только часть критериев. Прохождение тестов для него не обязано быть критерием приемки, тем более основным критерием, в частности по обозначенным funca причинам, заключающимся в общем в том, что «зеленые полоски» не означают, что продукт соответствует критериям, сформулированным на человеческом языке.
                          • 0
                            Скажите, а зачем вы сейчас это мне написали? Это никак не противоречит написанному мной.

                            То, что это должны быть тесты, разработанные исполнителем — лишь одна из опций.

                            В рамках поста это обязательная опция (хотя и не отменяющая остальных).
                            • 0
                              Не вижу я в посте, что это обязательная опция, хотя ещё раз его перечитал. «Мини-контракт» может быть заключен на бумаге, а не апрувом исходников тестов.

                              В общем, по-моему, приемочные тесты могут быть юридически значимым критерием только в ситуации когда заказчик по сути сам их пишет, сам несёт ответственность за их содержанием. В лучшем случае, когда их понимает и визирует или, хотя бы, может проконтролировать, что с прошлого билда ничего не менялось в тестах и тестирующем фреймворке. По сути ему нужен доступ к инфраструктуре разработчика, чтобы контролировать, что тот не мухлюет с тестами.
                              • 0
                                Не вижу я в посте, что это обязательная опция, хотя ещё раз его перечитал. «Мини-контракт» может быть заключен на бумаге, а не апрувом исходников тестов.

                                Обязательная опция — наличие таких тестов и передача их заказчику.

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

                                Зачем? Вообще-то еще должен быть тестовый контур на стороне заказчика, где проводится тестирование перед внедрением. Вот там такие вещи и гоняют.
                                • 0
                                  Это очень квалифицированный заказчик должен быть тогда, а это обязательной опцией не является по определению. Это типа как перед тем как покупать автомобиль лично проверять его соответствие всем техническим требованиям. Есть такие покупатели, но их меньшинство, большинство довольствуется простеньким тест-драйвом (ручным тестированием по самым частым сценариям) и гарантией.
                                  • 0
                                    Это опция приблизительно того же порядка, что и заказчик, готовый оплатить разработку автоматизированных тестов на стороне разработчика.
                                    • 0
                                      Меньшего. Вот прямо сейчас я договариваюсь о разработке с тестами, речи о их запуске заказчиком нет. Формально они у него будут (в его репозиторий хранится будут), но вряд ли он в них полезет когда. Он их принимает (если примет) как мое личное средство обеспечения качества кода, наравне с, например, тем, что я использую IDE, а не в блокноте пишу.
                    • 0
                      Вы не поверите, такое бывает
                • 0
                  Вы меня не правильно поняли. Речь о приложении, которое светит диодом. Заморочная хрень на зоопарке андроидов и тестирование подразумевает мартышкин труд.
              • +1
                Кстати, справедливости ради, натыкался лет 8-9 назад на коммерческий 3D-движок, в котором юнит-тестами были покрыты даже всякие нюансы с рендерингом, анализировалось «как отрендерилось» и «как должно отрендериться» :)
                За давностью лет, увы, совершенно вылетело из головы, как он назывался.
              • +4
                Вы правы — не все легко покрыть автотестами. Но из моего опыта, люди зачастую просто не знают, не хотят, не умеют этого делать. Для веб проектов есть Selenium, для совершенно произвольных есть Sikuli. А еще уйма инструментов специализированных. Если не получается протестировать через конечный пользовательский UI, то можно тестировать API бизнес логики.
                • +3
                  Selenium никак не узнает что, например, испортился layout в IE.
                  • 0
                    угу, или кнопка «купить» стала белая на белом фоне — он же ее по имени лукапит.

                    Я слышал это как реальную историю, которую вылечили тем, что увидели после коммита резкое падение типичного количества заказов на сайте.
                    • +2
                      Можно замечательно с помощью Selenium тестировать UI (расположение элементов, верстку, отработку JavaScript). На эту тему советую посмотреть мое выступление: www.youtube.com/watch?v=cUoSTBkeFy4. А тут есть еще много всего полезного на эту тему: xpinjection.com/resources/.
                      • 0
                        отлично, актуально, спасибо :)
                        • +1
                          Еще бы кто нибудь разъяснил толком как настроить ферму тестовых машин и тесты запускать параллельно…
                          • 0
                            Приезжайте на SeleniumCamp 2013. Там будет автор Selenium Grid из eBay и много докладчиков из больших продуктовых компаний: Google, Groupon, Amazon, eBay, Яндекс, Одноклассники, 2ГИС и т.д. А у них фермы машин стоят достаточно большие.
                            • 0
                              Спасибо за приглашение, но лучше уж вы к нам :)
                              На самом деле мне кажется на конференциях о таком не говорят, не будут же докладчики в деталях рассказывать как поднять селениум сервер и xvfb… А вот дельной инструкции в деталях я не нашел.
                              • +1
                                Инструкций в интернете валом, под рукой нет, но читал в ленте не раз.
                                • 0
                                  Ну так о том и речь, что вроде как все знают, а как до дела доходит, так никто в деталях описать не может.
                            • 0
                              Обновил пост ссылкой на статью сегодняшнюю про облачные провайдеры для запуска тестов. Вполне себе вменяемые цены и неплохой вариант для многих проектов.
                              • 0
                                Selenium grid hub запускается одной командой.
                                Selenium grid node запускается ещё одной командой.

                                Что именно вам непонятно в вопросе «как настроить ферму тестовых машин и тесты запускать параллельно»?
                            • 0
                              Посмотрел выступление, так и не увидел — какой же инструмент используется для screenshot-based тестирования?
                              • 0
                                • 0
                                  Вебдрайвер максимум сделает скриншот, но он не сделает никаких автоматических сравнений скриншотов.

                                  В презентации автор упоминает что у них задаются области, исключаемые из сравнения — для какого инструмента они задаются?

                                  В конце презентации вообще интересные вопросы — как быть с мобильными девайсами, iOS — на них вебдрайвер вам не сделает скриншоты. Или сделает?
                                  • 0
                                    А, вот оно code.google.com/p/fighting-layout-bugs/ работает над вебдрайвер.

                                    • 0
                                      Нет, это не для скриншот-бейз тестирования, это для выявления других проблем, про которые в презентации говорится после скриншот-бейзд — выползание текста за края, поломанные картинки и т.п.

                                      Цитата с сайта:
                                      What does it offer?
                                      Currently there are the following detectors:
                                      — DetectInvalidImageUrls
                                      — DetectTextNearOrOverlappingHorizontalEdge
                                      — DetectTextNearOrOverlappingVerticalEdge
                                      — DetectTextWithTooLowContrast
                                      — DetectElementsWithInvisibleFocus
                                    • 0
                                      P.S. О, таки да — для iOS и Android уже есть Driver-ы которые, вероятно, делают скриншоты — code.google.com/p/selenium/wiki/WebDriverForMobileBrowsers
                                      Одной проблемой меньше.
                                      • 0
                                        Видимо невнимательно смотрели. Сравнивалка картинок с регионами самописная. Это самая простая часть, любой адекватный разработчик пишет за пару часов. :) В интернете пробегала публичная версия на питоне, но ссылку не помню. У нас на Java.
                          • +9
                            В 99% случаев, я слышу эту фразу, как оправдание отсутствия автотестов :). Даже если нельзя достич 100% покрытия, автотесты значительно облегчат участь ручных тестеров, и уменьшат время проверки продукта
                            • +1
                              Но увеличивают время разработки, если писать под каждую функцию свои тесты. =)
                              • +2
                                Но увеличивают меньше чем в последствии экономят. Это факт.
                                • 0
                                  Да. С этим и не поспоришь. Проблема как правило в заказчике. Либо не хочет тратить денег на это, либо время.
                                • 0
                                  А вы таки вообще не тестируете свои приложения? Или как — отдали тестерам, время разработки закончилось?
                                  • 0
                                    Ну лично у меня. В общей массе тестами сильно обвешивать не приходилось. Когда-то вообще не знал даже о таком, хотя и проекты были мелочью «быстро сделал, сдали и забыл». Ну а последнее несколько лет, работал над двумя крупными. Тут как не пытался, не смог заказчиков убедить ввести тесты и закладывать их во время разработки. Только для себя кое какие тесты вводил, для бакенда сложной логики.
                                    Да и тестеров там вообще не было. Заказчикам нужно было «быстрее делай это и запускай, и принимайся за новые модули».
                              • 0
                                Не все баги можно найти, что теперь, никакие не искать?
                                • 0
                                  Особенно если разработка ведется в условия часто изменяющихся требований.
                                • +14
                                  Какая-то отчасти утопичная картина — заказчик вот так сразу взял и смог выдать все требования к какой-то части функционала. Ну-ну.

                                  К сожалению, заказчик легко напридумывает новых требований к уже написанному, что повлечет за собой переписывание тестов.
                                  • 0
                                    Полностью поддерживаю! В статье описан какой-то идеальный заказчик — эдакий сферический заказчик в вакууме :)
                                    На деле же оказывается, что по мере развития проекта всегда появляются новые элементы и дополнения, которые сразу предугадать невозможно. Да и это логично. Ведь если проект и идеи не модифицируются в ходе реальных тестов и работы проекта — то это, скорее всего, мёртвый проект.
                                    • +5
                                      Пусть себе на здоровье модифицируются, но скорее всего не вся функциональность перепиливается каждую неделю, особенно в большом проекте.
                                      • 0
                                        Не вся… не каждую неделю… Но обычно где-то через несколько месяцев подобных дополнений потребуется рефакторинг кода, чтобы всё работало хорошо и держало нагрузки. А писать идеальный код сразу… не знаю, не встречал я таких людей. Разве что — написать идеально и всё, в долгий ящик и больше никогда этот код не трогать.
                                        • +7
                                          Рефакторинг — последовательность изменений, которая изменяет внутреннюю структуру программы без изменения ее внешнего поведения.

                                          При рефакторинге тесты не меняются. Более того, без них невозможно убедиться, что внешнее поведение не изменилось, а значит называть это рефакторингом. :)
                                          • 0
                                            при рефакторинге уровня программы не меняются приемочные тесты. но все, что касается её внутренностей (unit, интеграционные) ломается — аж пыль столбом. :)
                                            • –1
                                              Не должны ломаться тесты того уровня (и выше), что рефакторится.
                                              • –1
                                                Интересно, кто минус поставил считает, что должны ломаться приемочные тесты, если где-то выделили кусок кода в отдельный метод или переименовали индекс цикла?
                                                • +2
                                                  Нет, я думаю, что те, кто видят, что при архитектурном рефакторинге тесты «того же уровня» ломаются с вероятностью, близкой к 0.99.
                                                  • 0
                                                    Не понимаю. Вот есть приемочные тесты, работающие чисто с UI. Проводим архитектурный рефакторинг без изменения UI (иначе это не рефакторинг, а изменение функциональности) — разве должны приемочные тесты при этом ломаться? Разве как раз прохождение тестов без их изменения не будет сигналом, что рефакторинг завершен и только теперь можно думать об изменении тестов или написании новых?
                                                    • 0
                                                      Вам уже написали, что приемочные тесты не ломаются, ломаются все остальные. Их, что характерно, больше, чем приемочных, на несколько порядков.
                                                      • 0
                                                        Так ломаются (и должны ломаться, если их предварительно не изменить) тесты ниже уровнем, а не того же или выше. Рефакторим архитектуру на высоком уровне — должны ломаться тесты уровнем ниже приемочных, функциональные, взаимодействующие непосредственно с кодом продукта, минуя UI.
                                                        • 0
                                                          Так ломаются (и должны ломаться, если их предварительно не изменить) тесты ниже уровнем, а не того же или выше.

                                                          У вас очень свое понимание «уровня» тестов.

                                                          И да, как раз «того» уровня тесты и ломаются — когда я рефакторю компонент, меняя его зависимости, тесты, написанные для тестирования этого компонента в изоляции, ломаются, потому что зависимости перестают совпадать.
                                                          • 0
                                                            Меняя его зависимости разве вы не меняете го поведение? Ну, кроме вырожденных случаев, когда формально зависимость есть, но нигде не используется. И это если не считать, что зависимость часть поведения.
                                                            • 0
                                                              Меняя его зависимости разве вы не меняете го поведение?

                                                              Зафиксированное в его контракте? Нет, не меняю.
                                                              • 0
                                                                Сигнатура конструктора контрактом не является?
                                                                • +1
                                                                  Во-первых, не обязательно, потому что это детали реализации. Во-вторых, зависимости не обязательно выражены в сигнатуре конструктора (и вообще во внешнем интерфейсе).
                                                                  • 0
                                                                    Конечно не обязательно, но я как-то привык, что зависимости являются частью внешнего интерфейса и контракта. Что зависимости компонента должны быть переданы клиентом в том или ином виде.
                                                                    • +1
                                                                      Вы привыкли неправильно. Если зависимости передаются клиентом, то вы говорите о Dependency Injection, но в этом случае непонятно, почему вы применяете его частично, и ваш «клиент» не получает обсуждаемый компонент снаружи, как и полагается зависимости.
                                              • +1
                                                И должны ломаться, потому что те части приложения, которые зависят от модифицируемого кода тоже ломаются. Или вы предпочитаете надеятся, что это только тесты сломались?
                                                А пыль столбом — это если рефакторить от души, а потом тесты запускать. Если делать рефакторинг мелкими шагами, постоянно прогоняя тесты, все совсем не так драматично.
                                            • +1
                                              Написать идеальный код сразу (да и со временем) не возможно, но возможно написать тестируемый код. Если код возможно протестировать и эти тесты для него написаны, то код уже близкий к идеалу, так как его можно рефакторить и не бояться что отвалится пол системы.
                                              В том то и дело, что обычно хреновый код в долгий ящик кладут (работает — не трогай!), а код который покрыт тестами он «живой», он дышит…
                                          • 0
                                            ни один бизнес не стоит на месте, если он пока еще жив
                                            так что требования менялись, меняются и будут меняться
                                            а раз он жив, то у бизнеса все хорошо

                                            а вот с кодом работать вам, и обеспечивать его работоспособность тоже
                                            я вам за багфиксы вообще не платил бы, ведь вы уже сделали что-то за что уплочено, сами сломали, сами и фиксите
                                            • 0
                                              Дык вопрос не в багфиксах, а в оптимизации взаимодействия новых фич и уже написанного.
                                              • 0
                                                называйте это как хотите, но если первая фича готова, и вторая тоже готова, но вместе они не работают, то за что вам платить?
                                                • 0
                                                  читайте договор )
                                                  • 0
                                                    и как часто вы со своими заказчиками по судам бегаете, чтобы они оплатили то, что вы не сделали?
                                                    • 0
                                                      что мы не сделали, какие суды, вы вообще о чем? :) предмет, стоимость, порядок сдачи и приемки — все это описывается в договоре, предоставляя для подобных неформальных вопросов, вполне формальные ответы.
                                                  • 0
                                                    Первая фича может быть очень плохо написана и ломаться при малейшем дуновении. В таком случае интеграция второй фичи будет довольно трудоемким занятием. И кому-то за него прийдется платить.
                                                    • 0
                                                      меня как заказчика больше интересует почему не работает, а не как оно там написано
                                                      • 0
                                                        Не работает, ведь, потому, что плохо написано. А вы, как заказчик, на этапе разработки первой фичи можете позаботиться о том, чтобы ее было достаточно просто поддерживать и расширять. Хотя про «Сделай по-быстрому, а потом зарефакторим» уже написано много.
                                            • 0
                                              Речь идет о работе над требованиями на очень короткий срок — обычно одна итерация. Если он не может на такой срок сформулировать требования во всех деталях и ответить на все вопросы, то у вас уже проблемы. :)
                                              • 0
                                                Да какая разница. Всегда возможно такое «а вот была пол года назад формочка, а надо в ней поменять функциональность, чтобы она грузила данные не оттуда а отсюда...».

                                                А на неделю может, да =)
                                                • +1
                                                  Так тут как раз все отлично! Полгода вы контролировали автоматически что она грузит данные из одного места. Потом перед тем как изменить поменяли тест. Он не проходит. Реализовали загрузку из другого места и вуаля! Все продолжает работать. Называется это ATDD — Acceptance Test Driven Development. :)
                                                  • 0
                                                    И какой тогда профит, если мне нужно постоянно писать новые тесты и вместе с этим переделывать половину (ну да, заказчики они такие) старых?
                                                    • +2
                                                      В том, что между этими переделками вы можете в любой момент времени, сделав изменение в любом месте, понять что все работает как должно работать. А если что-то поломается, то это будет видно и заказчику и вам и всем заинтересованным лицам.
                                                      • +2
                                                        Профит в том, что Вы знаете, что не сломали вторую половину.

                                                        Иначе — вот, мы сделали что требовалось — тестирование заказчиком — исправление багов — тестирование заказчиком — исправление багов, вылезших на другом конце — …
                                                • 0
                                                  ой да лааадно. Ну вот прям таки на 100% у вас требования поменяются. Да и поменять существующий тест — не так уж и сложно, серьёзно (у меня как раз почти полное покрытие автотестами, и динамично-меняющийся заказчик).

                                                  По сути, автотесты для разработки в целом — могут быть вполне тем же самым что и unit-тесты для написания кода.
                                                  • 0
                                                    Примерно какое приложение по категории и объему?
                                                • +4
                                                  А почему не затронуты минусы? Из того, что я могу прикинуть на опыте сразу после прочтения:
                                                  1. Как заставить заказчика составить список тестов?
                                                  2. Что если из-за написания таких тестов стоимость разработки увеличится на сумму большую чем стоимость разработки продукта?
                                                  3. Что если заказчик забыл/не учел какой-то тест?

                                                  Но, в целом, должен заметить, что нечто подобное, возможно, не в таком конкретном виде всегда присутствует и «обман» заключается в том, что заказчик сам всего не может учесть — такая уж это область, как и не все тесты можно придумать.
                                                  • +2
                                                    Для этого и есть комментарии. ;)

                                                    1. Его не надо заставлять ничего писать. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор тестов.

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

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

                                                    Для того, чтобы все учитывать и не забывать, надо мыслить малым. Именно в этом помогают итерации и фокусировка на ограниченном небольшом куске функциональности.
                                                    • +3
                                                      Его не надо заставлять ничего писать. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор тестов

                                                      Какие вы оптимисты.

                                                      «Вы мне сделайте, что я прошу, а проверю я сам». И все.
                                                      • 0
                                                        и что же он такого просит?
                                                        я не понял что вы имеете ввиду, уточните
                                                        объясните мне как для своей бабушки в конце концов

                                                        или расскажите как вы делаете то, что не понимаете как проверить?
                                                        • +1
                                                          Ну например — чтобы вот тут была формочка, данные вводились, обрабатывались и показывались.

                                                          Тесты? Какие тесты? Не хочу никаких тестов.
                                                          • +1
                                                            какая формочка? какие данные? как обрабатывались? что показывалось?
                                                            • +4
                                                              Цитирую ответ заказчика дословно: " ты что, дурак, что ли"?

                                                              А если серьезно (хотя и предыдущее было серьезно), то заказчик еще готов потратить время на объяснение вам сценариев использования, но вот ПМИ он с вами обсуждать может и не захотеть. А нет ПМИ — значит, нет и приемочных тестов.
                                                              • +3
                                                                Простите, а как Вы тогда вообще за проект берётесь? Вас же заказчик загоняет до полусмерти, ещё и только половину заплатит.
                                                                • +1
                                                                  Стараюсь не браться.

                                                                  Заказчиков, несомненно, надо воспитывать. Но выбить из него список аксептанс-тестов — это существенно дальше в перспективе, нежели выбить из него нормальные требования.
                                                                  • 0
                                                                    «нормальные требования» по сути позволяют понять, какие данные будут подаваться на вход, и что будут ожидать на выходе, правда?

                                                                    Посути автотесты помогут Вам значительно уменьшить время/итерации приёмки продукта, что — есть профит.
                                                                    • 0
                                                                      Время приемки — никак не уменьшит, потому что приемку делает заказчик все равно.

                                                                      А время разработки — это надо считать стоимость разработки автотестов еще.
                                                                  • +1
                                                                    А Вы не работали с крупными заказчиками, банками? Вы сами решаете с кем работать? Если начальство говорит, что с этим заказчиком надо работать, Вы говорите: «Нет, не буду!»?
                                                                    • 0
                                                                      Как раз крупные заказчики — очень любят приёмочные тесты. Потому что их можно формализировать, и результаты записать в акт приёмки/сдачи.

                                                                      А вообще, когда Вы работаете за ЗП — то это всё не Ваши проблемы :)
                                                                • +1
                                                                  Пускай калькулятор обычный. Вполне реальный дилог может быть такой:
                                                                  — как проверять будете?
                                                                  — введу что-нибудь и сложу, а потом умножу и т. п.
                                                                  — что введете?
                                                                  — ты что издеваешься?
                                                                  • 0
                                                                    в руби, например, и строки умножать можно, но это не ожидаемое поведение калькулятора
                                                                    никто не сказал, что складывать надо не только int, но и float, а с кого спрашивать?
                                                                    если все риски закладывать в цену, так я найду кто дешевле сделает
                                                                    • 0

                                                                      — Нет, я не издеваюсь. Просто прошлый раз под «что-нибудь» я понимал целые числа, а вы думали про все подряд. Потом пришлось переделывать.
                                                                      — Ну это же просто здравый смысл взять все числа!
                                                                      — Здравый смысл как оказывается у каждого свой, да еще и склонен меняться. Давайте пару примеров накидаем и так все будет проще.
                                                                      • 0
                                                                        — Так я же полгода назад говорил, что не все числа надо, а только целые
                                                                        а еще через полгода
                                                                        — Почему калькулятор дробные числа не считает?
                                                                        и где искать потом правду?
                                                                        • +11
                                                                          Извините, не могу не процитировать из одной в свое время популярной статьи (А. Соловьев «Ишкушштвенный интеллект»)

                                                                          — Какие могут быть формальности между друзьями! Вася, сделай мне программу сортировки.
                                                                          — А что такое сортировка?
                                                                          — Мне надо, чтобы я вводил любые числа, а программа выдавала УПОРЯДОЧЕННЫЕ числа.
                                                                          (через неделю)
                                                                          — Ты что, Вася! Я ввожу 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, а она даже два числа отказывается сортировать.
                                                                          — А откуда я знал, что тебе НЕ ТОЛЬКО целые надо сортировать?
                                                                          Может тебе завтра взбредет комплексные сортировать?! Последний раз!!!
                                                                          (через неделю)
                                                                          — Ты что, Вася! Программа больше девяти чисел не сортирует...
                                                                      • 0
                                                                        >>— введу что-нибудь и сложу, а потом умножу и т. п.

                                                                        Вот вам и почва для написания приёмок.

                                                                        Или Вы хотите, чтоб заказчик сначала складывал/умножал. Потом оказывается что ему нужно и вычитание/деление. Потом — запуск небольших программ на бейсике (А что, это не очевидно?! Вот, смотрите, калькулятор от ****** это умеет!)…
                                                                        • +1
                                                                          Это нам польза от написания приемочных тестов. А вот заказчику — нет. Поэтому он и будет эту деятельность саботировать до последнего.
                                                                          • 0
                                                                            Как раз от приёмочных тестов — больше всего пользы заказчику. Потому что он получает протестированный продукт, а не абы-что. Особенно это касается сложной системы, проверить которую за пару дней просто не возможно.

                                                                            Ваша задача — просто донести это до заказчика. И да, по опыту, автоматизаторы выходят не дороже ручных тестеров (из-за того что их значительно меньше нужно). А раз нет ценовой разницы — то какие ещё могут быть аргументы против? :)

                                                                            *жуткая догадка* Или Вы вообще не тестируете?
                                                                            • +1
                                                                              Потому что он получает протестированный продукт, а не абы-что.

                                                                              Вы что-то путаете. Степень протестированности продукта не зависит от того, есть ли подписанные заказчиком ПМИ.

                                                                              Зато ПМИ не дают заказчику сказать «не, меня не устраивает, хочу иначе» — и это ему невыгодно.

                                                                              И да, по опыту, автоматизаторы выходят не дороже ручных тестеров (из-за того что их значительно меньше нужно). А раз нет ценовой разницы — то какие ещё могут быть аргументы против?

                                                                              Вы стоимость разработки ПМИ и, что важнее, стоимость тестовых ландшафтов тоже посчитали, я надеюсь?
                                                                              • 0
                                                                                Видимо мы о разных вещах говорим, т.к. я привык называть приёмочными тестами любые функциональные тесты, на основе которых принимается решение о валидности продукта.

                                                                                очевидно, что в вашем случае, приёмки будут подмножеством функциональных тестов. В таком случае, действительно, со стороны заказчика глупо давать план тестирования, т.к. он может получить продукт, который работает только по 2-3 сценариям. Либо же заказчику придётся составлять план, покрывающий 100% функциональности продукта.

                                                                                А теперь по стоимости. Вы согласны, что тест-кейсы придётся разрабатывать в любом случае? А теперь прикиньте сколько раз, ручные тестеры будут гонять один и тот же тесткейс во время разработки, и Вы сами придёте к тому, что автотесты — банально дешевле
                                                                                • +1
                                                                                  Видимо мы о разных вещах говорим, т.к. я привык называть приёмочными тестами любые функциональные тесты, на основе которых принимается решение о валидности продукта.


                                                                                  Цитирую обсуждаемый пост (выделение мое):

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


                                                                                  Именно об этом я и говорю.

                                                                                  А теперь прикиньте сколько раз, ручные тестеры будут гонять один и тот же тесткейс во время разработки, и Вы сами придёте к тому, что автотесты — банально дешевле

                                                                                  Они возможно дешевле в идеальной долгосрочной перспективе. А в реальности для некоторых приложений написание автоматизированных сценариев тестирования увеличивает косты разработки вдвое или втрое.
                                                                                  • 0
                                                                                    >>Они возможно дешевле в идеальной долгосрочной перспективе. А в реальности для некоторых приложений написание автоматизированных сценариев тестирования увеличивает косты разработки вдвое или втрое.

                                                                                    После 3-ей итерации уже будут дешевле. Попробуйте.

                                                                                    Впрочем, если у вас небольшие приложения, которые укладываются в одну итерацию — смысла не будет.
                                                                                    • +1
                                                                                      После 3-ей итерации уже будут дешевле. Попробуйте.

                                                                                      Мне нравится, как уверенно вы говорите о стоимости разработки приложения, которого вы в глаза не видите.
                                                                                      • 0
                                                                                        не приложения, что Вы. Всего лишь о том, что бы заменить (хотя бы частично) «мартышек» на автоматизаторщиков.
                                                                                        • 0
                                                                                          А вы думаете, что стоимость этого процесса не зависит от приложения?
                                                                                          • 0
                                                                                            Ещё раз — я говорю о удешевлении производства, из-за добавления в него автоматизации. Практика показывает, что даже в металлургии это приносит пользу.

                                                                                            Я думаю, можно придумать ситуацию, когжда автоматизация лишь приведёт к удорожанию процесса. Но 90% вероятности, что Вы просто не хотите с этим заморачиваться. Ведь проще убедить себя и начальство, что авто-тесты зло, правда?
                                                                                            • 0
                                                                                              Ещё раз — я говорю о удешевлении производства, из-за добавления в него автоматизации.

                                                                                              Это, по-вашему, верно для любого производства?

                                                                                              Но 90% вероятности, что Вы просто не хотите с этим заморачиваться.

                                                                                              Мы как раз хотим. Но стоимость развертывания тестового полигона такова, что мы не можем себе этого позволить.
                                                                                              • 0
                                                                                                >>Это, по-вашему, верно для любого производства?
                                                                                                Прочитайте ещё раз мой комментарий.

                                                                                                >>Мы как раз хотим. Но стоимость развертывания тестового полигона такова, что мы не можем себе этого позволить.

                                                                                                Если не секрет — то что у Вас за разработка?
                                                                                                • +1
                                                                                                  Если не секрет — то что у Вас за разработка?

                                                                                                  Унаследованная информационная система масштаба распределенного предприятия.
                                                                                                  • 0
                                                                                                    Отлично. Я думаю деньги на ещё одну машинку у Вас есть. А это значит, что используя системы типа Selenium Или testcomplite Вы вполне можете выполнять приёмочные тесты для вновь созданного функционала. Да, это будет казаться каплей в море. Да, это не будет гарантировать работоспособности всей системы. Но! это будет гарантировать работоспособность новых модулей.

                                                                                                    С другой стороны, сейчас я являюсь свидетелем внедрения автоматизации в достаточно массивный проект. Там автоматизация внедряется по другому пути — покрываются наиболее критические участки. И это не выходит особо дорого.

                                                                                                    Так что — В вашем случае есть различные методы внедрения автоматизации (на первых этапах частичной), и некоторые из них — вполне бюджетны.
                                                                                                    • 0
                                                                                                      «Одна машинка?» Понятно. Дальше не интересно. Вы правда не понимаете масштаб проблемы, в рамках которой даете советы.
                                                                                                      • +2
                                                                                                        70+M пользователей, 2M+ уникальных в день, 600mb кода. Для введения в это автотестов хватило на первых парах одной машины, на которой запускались авто-тесты. Ах да, и полигон для ручных тестеров (он то у вас хоть есть?).

                                                                                                        Знаете, есть ощущение, что весь Ваш пафос и усердие направлено не на поиск решения, а на поиск препятствий. Хотите поговорим об этом в личной почте? Я уверен, что приемлимое для Вас решение можно найти. Но прежде всего нужно желание. Если его нет — всё остальное бессмысленно.
                                                                                                        • 0
                                                                                                          Простите, это был унаследованный проект, или разработанный вами? Вам были подконтрольны и известны все его части, или нет?
                                                                                                          • 0
                                                                                                            Унаследованный. Страшный гавнокод. В некоторые его части отказывались лезть даже самые бесстрашные программисты :). Опять таки — потому что небыло тестов, и понять, сломал ты что-то или нет — не возможно.

                                                                                                            К счастью, для автоматизированных тестов (как и для пользователя) это всё не важно. Да, конечно, хороше бы ещё и базу контроллировать, но изменения в БД, в своих модулях Вы то, наверное, знаете.
                                                                                                            • 0
                                                                                                              Значит, контроль над базой вам не нужен? Ну оок.

                                                                                                              Вот есть модуль управления контрагентами. Пока контрагент новый — можно вводить только часть информации, как только она введена — можно вводить всю остальную. И это все, конечно же, унаследованное.

                                                                                                              Вам приходит CR на то, чтобы изменить валидацию в части тех данных, которые можно вводить только пока контрагент новый. Ваши действия?

                                                                                                              Ах, да, малозначительная деталь (которую вы узнаете только на второй день тестирования): контрагенты при вводе проверяются на уникальность ИНН.
                                                                                                              • 0
                                                                                                                >>Вам приходит CR на то, чтобы изменить валидацию в части тех данных, которые можно вводить только пока контрагент новый. Ваши действия?

                                                                                                                Что мешает создавать свежего пользователя и проверять? Что мешает сделать действия для получения статуса «старый» и провести отрицательный тест? (если нет порядка действий — то ведь и вручную это не проверить, правда?)

                                                                                                                >>контрагенты при вводе проверяются на уникальность ИНН.
                                                                                                                В чём проблема добавлять некую временно-зависимую велечину в ИНН? В чём проблема попытаться создать подряд 2х пользователей с одинаковым ИНН?

                                                                                                                И самый главный вопрос, а «мартышки» то как этот вопрос решают?

                                                                                                                Посмотрите внимательно — вместо того, чтоб найти в своём проекте вещи, которые можно начать автоматизировать, Вы старательно пытаетесь найти то, что автоматизировать нельзя. Да, может быть Вы такое и найдёте (поищите в стороне использования стороннего API, желательно банковского). Но это не значит, что остальную, весьма значительную часть проекта невозможно покрыть автоматизированными тестами.
                                                                                                                • 0
                                                                                                                  Что мешает создавать свежего пользователя и проверять?

                                                                                                                  Уникальность ИНН.

                                                                                                                  В чём проблема добавлять некую временно-зависимую велечину в ИНН?

                                                                                                                  Вы не в курсе, как формируется ИНН?

                                                                                                                  В чём проблема попытаться создать подряд 2х пользователей с одинаковым ИНН?

                                                                                                                  Если первый создастся, то второй — нет.

                                                                                                                  И самый главный вопрос, а «мартышки» то как этот вопрос решают?

                                                                                                                  Анализом существующих данных и выбором подходящих значений.

                                                                                                                  Посмотрите внимательно — вместо того, чтоб найти в своём проекте вещи, которые можно начать автоматизировать, Вы старательно пытаетесь найти то, что автоматизировать нельзя.

                                                                                                                  Я вам просто привел один из примеров. В реальности же именно таких ситуаций в системе (известной мне части) преобладающее большинство. Чтобы их решить, нужна самая малость — полный контроль над БД.

                                                                                                                  Нет смысла тратить усилия на автоматизацию 5%, если очевидно, что остальные 95% автоматизировать тем же подходом нельзя. Это будет автоматизация ради автоматизации, без какой-либо глобальной цели.
                                                                                                                  • 0
                                                                                                                    >>Анализом существующих данных и выбором подходящих значений.
                                                                                                                    Ну и о чём тогда разговор? :) Знаете, с помощью селениума можно даже в админке искать пользователей, и уж тем более анализировать выборку.

                                                                                                                    Подумайте, какие конкретно действия ручных тестеров нельзя автоматизировать?
                                                                                                                    • 0
                                                                                                                      Подумайте, какие конкретно действия ручных тестеров нельзя автоматизировать?

                                                                                                                      Нет таких действий. Вопрос только в том, сколько будет стоить эта автоматизация.

                                                                                                                      Про что вам с самого начала и сказали.
                                                                                                                      • 0
                                                                                                                        >>Нет таких действий.

                                                                                                                        Отлично, значит автоматизация всё таки возможна. Уже радует.

                                                                                                                        >>Вопрос только в том, сколько будет стоить эта автоматизация.

                                                                                                                        Просто посчитайте, сколько раз ручные тестеры делают одно и тоже действие, тестируя ВСЮ систему перед каждым релизом (или — ну его нафиг, и так прокатит?)
                                                                                                                        тут как с JIT компиляторами — автоматизируйте действия, которые выполняются 80% времени (а это, как правило, 20% функционала) и вы получите хорошее снижение стоимости тестирования
                                                                                                                        • 0
                                                                                                                          Отлично, значит автоматизация всё таки возможна. Уже радует.

                                                                                                                          Никто никогда не говорил, что она невозможна. Я всего лишь говорил о ее стоимости.

                                                                                                                          Просто посчитайте, сколько раз ручные тестеры делают одно и тоже действие, тестируя ВСЮ систему перед каждым релизом (или — ну его нафиг, и так прокатит?)

                                                                                                                          Заказчику не нужно сплошное тестирование всей системы перед каждым релизом. Он не готов и отказывается за него платить.
                                                                                                                          • 0
                                                                                                                            Подождите, Покрытия у вас нет… Полностью систему перед релизом не проверяете…
                                                                                                                            Тоесть, по сути никто не знает, работает ли система целиком, и как…

                                                                                                                            Извините, но это подход Х**к, Х**к и в продакшн. И если Вас это устраивает — то да, автотесты вам не нужны. Зачем же Вам бесполезное качество? :)
                                                                                                                            • 0
                                                                                                                              Это не нас устраивает, а заказчика. И он не готов платить за полный ретест системы.

                                                                                                                              Собственно, о чем я вам и говорю с самого начала: стоимость приемочных тестов может быть выше, чем экономически оправданно для разработки.
                                                                                                                              • 0
                                                                                                                                >>Собственно, о чем я вам и говорю с самого начала: стоимость приемочных тестов может быть выше, чем экономически оправданно для разработки.

                                                                                                                                Немножко неправильная формулировка. Правильная звучала бы как «Мы можем позволить себе экономить на качестве». А так — да, всё правильно :)
                                                                                                                                • 0
                                                                                                                                  Не «мы» — разработчики, — а заказчик. Не надо путать.
                                                                                                                                  • 0
                                                                                                                                    Скорее «мы оптимизируем критерий цена/качество»
                                                                                                                        • 0
                                                                                                                          Например, заметить интуитивно аномальное значение, а то их последовательность, исследовать контекст и решить это просто статистический всплеск или баг.

                                                                                                                          Вот, например, приложение, которое я долго покрывал тестами широко использует случайные числа. С помощью инъекций, рефлексий и т. п., на уровне юнит-тестов я всё же проблему решил. Но вот на приемочных я просто не представляю как это делать, чтобы исключить как ложноположительные, так и ложноотрицательные срабатывания. Рандом — он такой рандом, любые последовательности равноверотны.
                                                                                                                          • 0
                                                                                                                            >>Например, заметить интуитивно аномальное значение
                                                                                                                            Простите, что? Именно это авто тесты и делают лучше всего — «замечают аномальные значения» :). Или у вас как — если бага встретилась случайно, то ну её нафиг, авось пользователь не заметит?

                                                                                                                            >>Рандом — он такой рандом, любые последовательности равноверотны.
                                                                                                                            Конечно. Поэтому есть понятие экстримальных значений. Идея — найти такие входные данные(методом анализа), на которых Ваше приложение скорее всего упадёт. Если не упадёт на них, то скорее всего и внутри интервала будет всё отлично.
                                                                                                                            • 0
                                                                                                                              Утрированный пример: где-то в программе складывается 10 случайных чисел от 1 до 9 (не важно зачем, так надо), от входных данных никак не зависит. Диапазон получается от 10 до 90 со средним значением 50. Диапазон мы проверить можем. Но как автоматическим тестом проверить, что не допущена ошибка и вместо случайного числа от 1 до 9 не выдаётся всегда константа?

                                                                                                                              Глазками мы увидим большую последовательность одних чисел, залезем в код, трижды проверим, что всё правильно и это лишь статистический выплеск, и с лгким сердцем отправим в продакшен. А как писать автотест? Ведь мы знаем, что в теории может быть сколько угодно длинная последовательность одинаковых чисел столь же вероятная как другая.
                                                                                                                              • 0
                                                                                                                                Это ручные тестеры в код то залезут?
                                                                                                                                Ваш пример звучит как «где то в программе, сферический конь в вакууме», и по звуку из колонок можно понять что он заболел и кашляет.

                                                                                                                                Если Вы работаете профессионально, то у вас должны быть тестеры, и должны быть прописанные тест кейсы, верно? На основании тест кейсов и можно автоматизировать.

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

                                                                                                                                Если же Ваша программа не решает никаких задач — то да, автоматизировать её бессмысленно.
                                                                                                                                • 0
                                                                                                                                  Игра. Тестер скажет мне, я полезу в код.
                                                                                                                                  • 0
                                                                                                                                    Отлично, требования то к игре у вас есть? И на что конкретно влияют случайности?

                                                                                                                                    Да, не всё и не с первого раза вы покроете. Но то что покроете — не нужно больше трогать. Всё, этот функционал всегда рабочий.
                                                                                                                                    • 0
                                                                                                                                      Результат боев. По сути «черное-красное» в рулетке.

                                                                                                                                      Нет, унаследованный код, как говорится. Тестами фиксирую (вернее уже фиксировал) поведение для последующего рефакторинга.
                                                                                                                                      • 0
                                                                                                                                        Ну первое что приходит в голову — установите максимальную длину «совпадений». Ту, из-за которой бы занервничал мануальщик :)

                                                                                                                                        А вообще — всё остальное то покрывается? :)
                                                                                                                                        • 0
                                                                                                                                          Всё остальное, в принципе, да.
                                                                                                                                • 0
                                                                                                                                  Что руками, что автоматизировано, это решается только через статистический анализ. Считаем 1000 раз, оцениваем мат. ожидание, дисперсию и форму распределения.
                                                                                                    • 0
                                                                                                      Самая простая и довольно распространенная ситуация: есть ТЗ, сделали его, отдали заказчику, он принял, а дальше хоть трава не расти.
                                                                        • +2
                                                                          Было бы еще круче: «Сделайте как я хочу, но как я не скажу, а проверять буду со всей строгостью!». ;)
                                                                          • +3
                                                                            Какая-то квантовая разработка. Результат должен быть сразу всяким :)
                                                                    • 0
                                                                      Как-то на моей практике приемочные тесты приносят пользу если только заказчик понимает, что это такое, а в идеале их сам и пишет. А так хватает функциональных и модульных.
                                                                      • 0
                                                                        Функциональное тестирование — это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. (с) Википедия

                                                                        Вообще то приёмочные тесты — это функциональные, которые назвали по другому :)
                                                                        • 0
                                                                          Для меня приемочные, если брать внешнюю сторону, это эмуляция работы пользователя, вплоть до указания координат кликов. Функциональные — отправка http запросов, анализ ответов или, максимум, инициирование тех или иных DOM событий и сравнение изменений в DOM с ожидаемыми. Если уж совсем на пальцах, то приемочные для меня «кликнуть кнопку и проверить результат визульно», а функциональные — «эмулировать нажатие кнопки и проверить результат в памяти». Ключевое отличие — кнопка может оказаться невидимой пользователю, как и результат, не смотря на выставление флогов типа visible.