да нет, на самом деле с TDD/ATDD так как раз и можно. Истоки Agile (не той жести, во что это сейчас вылилось, а идеи) идут из экстремального программирования, и TDD в нем выполняли задачу ТЗ. Т.е. тесты писались не только для того, чтоб что-то протестировать, сколько для того, чтоб описать требования (в виде тестов) и иметь возможность быстро ответить на вопрос — выполняются ли требования. [1][2]
Т.е. при классическом (Chicago school) TDD ТЗ и продукт появляются одновременно, короткими, итеративными шагами [3].
есть популярный миф, что тестирование делают исключительно тестировщики. Конечно это не так, тестировщики — это инженеры, которые специализируются в тестировании. В отсутствие тестировщиков — тестирование будут делать другие люди. Возможно — пользователи приложения.
а при чем тут вообще тестирование? это чистой воды административные решения. это ошибки того кто составлял ТЗ
Это хорошее замечание. Давайте я приведу пример: например мы выпускаем сайт на территории, ну, скажем, Башкартостана. Зафигарили мы значит сайт, а добавить функцию выбора языка забыли. Я исхожу из предположения, что обратить на это внимание и задать вопрос — это часть процесса тестирования.
так же, пишите ТЗ правильно.
— тестирование требований я тоже отношу к тестированию.
Если исходить из модели, что тестирование — это взять ТЗ и банально проверить выполнено ли это ТЗ в точности как написано, то да. Это можно автоматизировать, но это является очень упрощенным и поверхностным пониманием, что такое тестирование.
Вами выше исключительно не головная боль разработчика. сказано на входе 5 на выходе 8, за 200мс, вот и все)
— к сожалению, такая логика не выдерживает критики в суде. Например уже были преценденты, когда инженер был признан виновным за добавление функционала «точно по ТЗ» (кейс VW).
В нашем университете мы вполне себе серьезно обсуждаем вопрос является ли «выполнил по ТЗ» достаточным аргументом в пользу защиту подсудимого, и необходимо ли обучение программистов этике.
Я понимаю аргументы тех, которые считают, что «делаем по ТЗ, а дальше — не наша головная боль», но чисто по человечески я на стороне тех, кто считает, что программист\тестировщик зачастую обладают бОльшей эксперизой, чем те, кто пишут ТЗ, а потому должны указывать на проблемы в ТЗ и не делать «черни», даже если она указана в ТЗ) Именно поэтому у меня такая забавная должность.
Ну и самое главное — в большинстве случаев разработки ТЗ уже как-то и не пишется, а люди приходят с проблемой, которую нужно решить. Например, «хочу автоматизировать производство». И ТЗ в данном случае — просто этап производства продукта, за который МЫ несем ответственность.
TDD — это классно! Я очень люблю TDD и даже немного умею использовать. TDD действительно может дать 100% покрытие кода, но 100% покрытие кода не отвечает на следующие вопросы:
1) Какой код мы забыли написать (конфликт покрытия кода и покрытия требований)?
2) Какой код\функционал не надо было писать?
3) Какие риски и пограничные значения возможны?
Тем не менее, TDD обеспечивает достаточно высокий уровень качества, настолько высокий, что во многих бизнес доменах позволяет обойтись без тестирования в принципе. Но TDD — это метод разработки; классическая автоматизация тестирования — это что-то другое.
И даже в случае TDD (что позволяет нам обходить ограничения от проблемы останова и закона Эшби за счет сужения общей задачи до большого количества частных) решение о релизе и уровне (дилемма лица, принимающего решения) принимает человек.
А про нейронку — потому что самообучающаяся нейронка — это сверхсложное ПО из палаты мер и весов) Даже хуже. В нейронке сложность столько не на уровне кода, сколько на уровне обучения (чем учили, как переучивали, какие поправочные коэффициенты, как это все дело хранится, как доучивается?), что повышает сложность и уменьшает способность контролировать результат на порядок.
Вы не задаёте вопросов, а делаете спорные утверждения, зачастую абсурдные, которые потом заменяете на другие, в случае если 'не выстрелило'
Это называется 'полемикой'. Отличие полемики от дискуссии в том, что в полемике нет цели найти истину, а, есть цель убедить в своей правоте. У меня тако цели нет, а ваши аргументы непоследовательны и не достаточно интересны, чтоб я хотел на них отвечать.
Предлагаю вам написать статью 'ответку' с тезисом 'автоматизация является полноценной заменой тестированию', и посмотреть что выйдет.
Я рекомендую вам еще раз перечитать статью, посмотреть видео и ответить самому, почему в геймдеве применимость автоматизации может быть больше, чем, например, в банковской сфере или здравоохранении.
При этом я не помню, чтоб я где-то выдвигал тезис о том, что автоматизация 'умрет'. Речь идет о том, является ли автоматизация полноценной заменой. Фокус на слове 'полноценной'.
2) Снижение impact от риска за счет восстановления (например - стабильность браузеров все еще не на высоте, они крашаться все также, но теперь зато сами открываются без потери вкладок)
Применимость закона Эшби не меняется, вы правы! Вот только если ручном тестировании управляющая система это человек, которая заведомо более сложная, чем управляемая. При автоматизации - управляющая система это автотест.
Как я уже писал чуть выше — тема про проблему останова не раскрыта, я это подправлю, но вы абсолютно правы. Проблема останова действительно говорит об ОБЩЕМ случае, но ничего не говорит про частный.
Тем не менее, я не думаю, что у нас с вами разные точки зрения. Я ведь не утверждаю, что какую-то часть тестирования невозможно выполнить автоматически, я работаю с одним конкретным тезисом — «сможет ли автоматизация ЗАМЕНИТЬ тестирование», это общее утверждение, и в данном случае аргумент с проблемой останова мне кажется вполне уместным.
Тезис не про наказание, а про принятие решения. Принятие решения о качестве продукта осуществляется человеком, и эту часть QA и тестирования автоматизировать будет, как минимум, сложно, и во многих странах (привет GDPR и право на отказ от автоматизированных решений!) возможно не очень законно. Видимо этот момент тоже не до конца раскрыл, но, как уже и писал, статья не была готова и опубликовалась случайно. Подправлю в полете.
Прежде всего, спасибо за комментарий. Проблема останова действительно не звучит как что-то, имеющее отношение к тестированию, но проблема автоматизации тестирования сводится к проблеме останова. Статья сыра (я не планировал публикацию, просто поставил расписание, и успешно забыл), я пропустил обоснование этого утверждения, что я, конечно, исправлю.
Закон Эшби имеет прямое отношение к автоматизации тестирования, т.к. определяет соотношение необходимой сложности (энтропии) управляющей и управляемой систем. Если вы не согласны с этим утверждением, то или есть два закона, называемых законами Эшби, либо у нас с вами не получится продуктивной дискуссии.
В целом, я вижу, что вы не согласны с моей точкой зрения, но ваша аргументация не совсем понятна. Исходя из вашего комментария вы исходите из того, что тестирование (при этом забываете, что тестирование != QA) это манки-тестинг, и ничего более. Это печально, но я абсолютно согласен, манки-тестинг будет автоматизироваться до тех пор, пока это экономически целесообразно (пока не упремся в Эшби). При этом если вы никогда не работали с тестировщиками, которые, как вы выразились, «супер люди» — сочувствую, вы лишились классного опыта.
Интересная статья, спасибо!
Отличный комментарий, спасибо!
У меня вопрос, а вы лично кому бы больше доверяли, человеку или автотесту?
Может вам было бы интересно поучаствовать в ревью научной работы на смежную тему?
Неплохая оптимизация, только вот зачем?
В любом случае цель оригинальной статьи в изучении принципов алгоритма, а не создании его оптимальной реализации.
У меня на гитхабе валяется более совершенная версия алгоритма, но это перевод, а потому я не вносил 'отсебятины'
Т.е. при классическом (Chicago school) TDD ТЗ и продукт появляются одновременно, короткими, итеративными шагами [3].
[1] www.linkedin.com/pulse/so-you-say-doing-bdd-story-whiteboard-nail-gun-john-ferguson-smart
[2] www.ministryoftesting.com/dojo/lessons/deliberate-discovery-of-requirements-with-bdd-with-gaspar-nagy
[3] dev.to/hiboabd/a-beginners-explanation-of-the-chicago-london-approaches-4o5f
Это хорошее замечание. Давайте я приведу пример: например мы выпускаем сайт на территории, ну, скажем, Башкартостана. Зафигарили мы значит сайт, а добавить функцию выбора языка забыли. Я исхожу из предположения, что обратить на это внимание и задать вопрос — это часть процесса тестирования.
— тестирование требований я тоже отношу к тестированию.
Если исходить из модели, что тестирование — это взять ТЗ и банально проверить выполнено ли это ТЗ в точности как написано, то да. Это можно автоматизировать, но это является очень упрощенным и поверхностным пониманием, что такое тестирование.
— к сожалению, такая логика не выдерживает критики в суде. Например уже были преценденты, когда инженер был признан виновным за добавление функционала «точно по ТЗ» (кейс VW).
В нашем университете мы вполне себе серьезно обсуждаем вопрос является ли «выполнил по ТЗ» достаточным аргументом в пользу защиту подсудимого, и необходимо ли обучение программистов этике.
Я понимаю аргументы тех, которые считают, что «делаем по ТЗ, а дальше — не наша головная боль», но чисто по человечески я на стороне тех, кто считает, что программист\тестировщик зачастую обладают бОльшей эксперизой, чем те, кто пишут ТЗ, а потому должны указывать на проблемы в ТЗ и не делать «черни», даже если она указана в ТЗ) Именно поэтому у меня такая забавная должность.
Ну и самое главное — в большинстве случаев разработки ТЗ уже как-то и не пишется, а люди приходят с проблемой, которую нужно решить. Например, «хочу автоматизировать производство». И ТЗ в данном случае — просто этап производства продукта, за который МЫ несем ответственность.
1) Какой код мы забыли написать (конфликт покрытия кода и покрытия требований)?
2) Какой код\функционал не надо было писать?
3) Какие риски и пограничные значения возможны?
Тем не менее, TDD обеспечивает достаточно высокий уровень качества, настолько высокий, что во многих бизнес доменах позволяет обойтись без тестирования в принципе. Но TDD — это метод разработки; классическая автоматизация тестирования — это что-то другое.
И даже в случае TDD (что позволяет нам обходить ограничения от проблемы останова и закона Эшби за счет сужения общей задачи до большого количества частных) решение о релизе и уровне (дилемма лица, принимающего решения) принимает человек.
А про нейронку — потому что самообучающаяся нейронка — это сверхсложное ПО из палаты мер и весов) Даже хуже. В нейронке сложность столько не на уровне кода, сколько на уровне обучения (чем учили, как переучивали, какие поправочные коэффициенты, как это все дело хранится, как доучивается?), что повышает сложность и уменьшает способность контролировать результат на порядок.
Вы не задаёте вопросов, а делаете спорные утверждения, зачастую абсурдные, которые потом заменяете на другие, в случае если 'не выстрелило'
Это называется 'полемикой'. Отличие полемики от дискуссии в том, что в полемике нет цели найти истину, а, есть цель убедить в своей правоте. У меня тако цели нет, а ваши аргументы непоследовательны и не достаточно интересны, чтоб я хотел на них отвечать.
Предлагаю вам написать статью 'ответку' с тезисом 'автоматизация является полноценной заменой тестированию', и посмотреть что выйдет.
Я рекомендую вам еще раз перечитать статью, посмотреть видео и ответить самому, почему в геймдеве применимость автоматизации может быть больше, чем, например, в банковской сфере или здравоохранении.
При этом я не помню, чтоб я где-то выдвигал тезис о том, что автоматизация 'умрет'. Речь идет о том, является ли автоматизация полноценной заменой. Фокус на слове 'полноценной'.
Верно :)
Прежде всего, огромное спасибо за развернутый и аргументированный ответ!
Мои взгляды на судьбу SDET еще более нетрадиционные:
https://youtu.be/sEnVOHC3o-c
Посмотрите, пожалуйста, видео, интересно ваше мнение
Классный вопрос!
Например:
1)Бюджетирование проблем
2) Снижение impact от риска за счет восстановления (например - стабильность браузеров все еще не на высоте, они крашаться все также, но теперь зато сами открываются без потери вкладок)
3) defensive design
Применимость закона Эшби не меняется, вы правы! Вот только если ручном тестировании управляющая система это человек, которая заведомо более сложная, чем управляемая. При автоматизации - управляющая система это автотест.
Конкретные примеры:
1) решение что тестировать
2) решение как тестировать
3) решение когда тестировать
4) решение когда закончить тестирование
Это все часть работы тестировщика процесса тестирования, которые тяжело/не возможно автоматизировать.
Далее - исследовательское тестирование, которое находит больше всего багов не поддается автоматизации.
Визуальное тестирование, тестирование локализации, юзабилити... А вы точно знаете, что такое тестирование, раз задаете такие вопросы?
Как я уже писал чуть выше — тема про проблему останова не раскрыта, я это подправлю, но вы абсолютно правы. Проблема останова действительно говорит об ОБЩЕМ случае, но ничего не говорит про частный.
Тем не менее, я не думаю, что у нас с вами разные точки зрения. Я ведь не утверждаю, что какую-то часть тестирования невозможно выполнить автоматически, я работаю с одним конкретным тезисом — «сможет ли автоматизация ЗАМЕНИТЬ тестирование», это общее утверждение, и в данном случае аргумент с проблемой останова мне кажется вполне уместным.
Тезис не про наказание, а про принятие решения. Принятие решения о качестве продукта осуществляется человеком, и эту часть QA и тестирования автоматизировать будет, как минимум, сложно, и во многих странах (привет GDPR и право на отказ от автоматизированных решений!) возможно не очень законно. Видимо этот момент тоже не до конца раскрыл, но, как уже и писал, статья не была готова и опубликовалась случайно. Подправлю в полете.
Закон Эшби имеет прямое отношение к автоматизации тестирования, т.к. определяет соотношение необходимой сложности (энтропии) управляющей и управляемой систем. Если вы не согласны с этим утверждением, то или есть два закона, называемых законами Эшби, либо у нас с вами не получится продуктивной дискуссии.
В целом, я вижу, что вы не согласны с моей точкой зрения, но ваша аргументация не совсем понятна. Исходя из вашего комментария вы исходите из того, что тестирование (при этом забываете, что тестирование != QA) это манки-тестинг, и ничего более. Это печально, но я абсолютно согласен, манки-тестинг будет автоматизироваться до тех пор, пока это экономически целесообразно (пока не упремся в Эшби). При этом если вы никогда не работали с тестировщиками, которые, как вы выразились, «супер люди» — сочувствую, вы лишились классного опыта.
На будущее запомнить - Никогда не ставить публикацию по расписанию для неготовой статьи