Комментарии 50
Проблема останова - совершенно не соответсвует тому, что вы описали.
Закон Эшби тоже мимо кассы. Вы почему-то считаете что QA это супер люди, которые полностью покрывают все тест кейсы(даже те, которые никто никогда не писал), в то время как автотесты способны тестить только то, что в них заложили.
Вот только по факту QA это ровно такая же машина для выполнения автотестов по чек-листам и юзерсторам. Если они что-то и выявляют сами, то только из-за флуктуакций во время выполнения своей программы.
Единственная причина по которой есть живое тестирование - простота "программирования" живого тестера. Чтобы в игре живой QA проверил, что все двери на локации нормально открываются мне надо написать одну строчку в чек-листе "проверить все двери, что они открываются в статичном положении, при ходьбе и на бегу". Писать автотест который это будет проверять я буду день. При этом время программиста существенно дороже времени QA. Поэтому в такой ситуации приоритет отдается: пусть дешевый QA руками тестит, а программисты делом занимаются.
В итоге автотесты пишутся на покрытие тех вещей, которые либо легко покрываются, либо на откровенную регрессию которую часто ломают.
Везде QA которые непосредственно ручными тестами занимаются - дешевле программистов.
Что не так с терминологией?
То, что на рынке часто идут позиции «QA Engineer», а подразумевается ручное тестирование по готовым кейсам — просто крайне удачная попытка компаний завлекать людей шильдиком.
Закон Эшби имеет прямое отношение к автоматизации тестирования, т.к. определяет соотношение необходимой сложности (энтропии) управляющей и управляемой систем. Если вы не согласны с этим утверждением, то или есть два закона, называемых законами Эшби, либо у нас с вами не получится продуктивной дискуссии.
В целом, я вижу, что вы не согласны с моей точкой зрения, но ваша аргументация не совсем понятна. Исходя из вашего комментария вы исходите из того, что тестирование (при этом забываете, что тестирование != QA) это манки-тестинг, и ничего более. Это печально, но я абсолютно согласен, манки-тестинг будет автоматизироваться до тех пор, пока это экономически целесообразно (пока не упремся в Эшби). При этом если вы никогда не работали с тестировщиками, которые, как вы выразились, «супер люди» — сочувствую, вы лишились классного опыта.
"проблема автоматизации тестирования сводится к проблеме останова"
А проблема ручного? Может живой тестер ответить на вопросы, которые ставит проблема останова? Речь не о том, что проблема останова не имеет отношения к тестированию. Речь о том, что она имеет одинаковое отношение как к ручному, так и автоматическому тестированию. Ровно тоже самое с законом Эшби - его применимость не меняется от того, автомат тестирует или живой QA.
За счет чего "супер люди" достигают высокой эффективности тестирования?
Ок. есть обезьянка, которая тупо следует чек-листам. Тут всё понятно - автоматизируется на 100%.
И вы говорите что есть QA который.... как работает? Что он делает такого, что позволяет ему эффективно тестировать? Выдумывает свои тест кейсы? Окей. Если он выдумывает тест кейсы - надо их автоматизировать, а не ему же их гонять. Опять же - покрытие автотестами 100%, т.к. если есть тест кейс значит этот тест кейс можно проверить в автоматическом режиме.
Вообще, просто приведите пример конкретный, который выявляется ручным тестированием и не выявляется автотестами. Конкретный пример, когда нельзя ручное тестирование заменить.
Например когда игра играется не так как прежде. К проблеме останова это отношения не имеет, это проблема формализации требований. Увы иногда это тоже часть тестирования.
Конкретные примеры:
1) решение что тестировать
2) решение как тестировать
3) решение когда тестировать
4) решение когда закончить тестирование
Это все часть работы тестировщика процесса тестирования, которые тяжело/не возможно автоматизировать.
Далее - исследовательское тестирование, которое находит больше всего багов не поддается автоматизации.
Визуальное тестирование, тестирование локализации, юзабилити... А вы точно знаете, что такое тестирование, раз задаете такие вопросы?
Это не конкретные примеры. Это опять абстрактные задачи.
К примеру визуальное тестирование - что, всё что требует визуальной оценки не тестируется? Ну у меня на днях задача была тестировать локацию в UE на преджмет корректной работы лайтмапов. Один из способов оценки - визуальный. Он без проблем автоматизируется. Делается захват экрана и анализируется освещенность картинки.
Тестирование локализации что в вашем случае означает? Что установлен текст вместо IDшников? Вы не поверите, но нет проблем найти на экране весь текст и сравнить его с базой IDшников. Если на экране ID - тест фейл.
Юзабилити - это вы так "удобство" обозвали? Да, тут соглашусь. Есть о чем поговорить тоже, но будем считать что тут вы правы.
Мой вопрос про конкретный примеры он не про то, что "нет ничего что нельзя автоматизировать". Он про то, что таких вещей крайне мало уже и почти каждый конкретный ответ можно разобрать и как минимум частично автоматизировать.
Я работаю в сфере, где автотесты одни из самых сложных из всех - геймдев. Но даже здесь, то что пять лет мы и не мечтали автоматизировать сейчас становится возможным. Современные решения, особенно в сфере нейросетей позволяют обойти или упростить многие задачи, которые раньше казалось невозможно решить без человека. Сейчас мы можем написать бота, который играет в игру не на основе доступа к внутренним данным подготовленным специально для него, а на основе анализа визуальной картинки и стандартного инпута. И дальше здесь всё будет только лучше. И даже ответ на субъективные вопросы типа "удобно ли играть" мы вскоре сможем получить от нейронок. Так что автоматизация не то что не умрет, а наоборот станет проще и мощнее.
Я рекомендую вам еще раз перечитать статью, посмотреть видео и ответить самому, почему в геймдеве применимость автоматизации может быть больше, чем, например, в банковской сфере или здравоохранении.
При этом я не помню, чтоб я где-то выдвигал тезис о том, что автоматизация 'умрет'. Речь идет о том, является ли автоматизация полноценной заменой. Фокус на слове 'полноценной'.
Очень классный ход: "Я на вопросы отвечать не буду, я уже всё ответил в видео, если вы не понимаете - ваши проблемы".
Я вполне конкретные вопросы задаю. Не хотите на них отвечать - ваше право. Но это вашу позицию сильнее не делает.
Вы не задаёте вопросов, а делаете спорные утверждения, зачастую абсурдные, которые потом заменяете на другие, в случае если 'не выстрелило'
Это называется 'полемикой'. Отличие полемики от дискуссии в том, что в полемике нет цели найти истину, а, есть цель убедить в своей правоте. У меня тако цели нет, а ваши аргументы непоследовательны и не достаточно интересны, чтоб я хотел на них отвечать.
Предлагаю вам написать статью 'ответку' с тезисом 'автоматизация является полноценной заменой тестированию', и посмотреть что выйдет.
Применимость закона Эшби не меняется, вы правы! Вот только если ручном тестировании управляющая система это человек, которая заведомо более сложная, чем управляемая. При автоматизации - управляющая система это автотест.
Может живой тестер ответить на вопросы, которые ставит проблема останова?можно заканчивать диалог, т.к. вы или не разбираетесь в вопросе, или толсто троллите.
QA во-многом решает организационные задачи вроде разработки планов и стратегий тестирования, анализа и уточнения требований и документации и выстраивания процессов в целом. Разница между тестировщиком и QA - примерно как разница между кодером и архитектором.
К тому же, некоторые задачи QA может осуществить только человек: например, демонстрация пригодности к использованию
На будущее запомнить - Никогда не ставить публикацию по расписанию для неготовой статьи
В статье очень спорных утверждения относительно автоматизации:
Валидация программ и проблема останова. При этом упускается момент, что при этом есть подмножество программ которые вполне успешно валидируются. Но что более важно человек который проводит тестирование руками точно так же не может доказать корректность работы + к этому подвержен влиянию внутренних факторов (усталость и т.д.)
Тезис про наказание кажется не совсем к месту. Автоматизация здесь абсолютно перпендекулярна
При этом общий тезис валидный граница автоматизации определяется с учетом бизнеса, рисков и сложности автоматизации
Как я уже писал чуть выше — тема про проблему останова не раскрыта, я это подправлю, но вы абсолютно правы. Проблема останова действительно говорит об ОБЩЕМ случае, но ничего не говорит про частный.
Тем не менее, я не думаю, что у нас с вами разные точки зрения. Я ведь не утверждаю, что какую-то часть тестирования невозможно выполнить автоматически, я работаю с одним конкретным тезисом — «сможет ли автоматизация ЗАМЕНИТЬ тестирование», это общее утверждение, и в данном случае аргумент с проблемой останова мне кажется вполне уместным.
Тезис не про наказание, а про принятие решения. Принятие решения о качестве продукта осуществляется человеком, и эту часть QA и тестирования автоматизировать будет, как минимум, сложно, и во многих странах (привет GDPR и право на отказ от автоматизированных решений!) возможно не очень законно. Видимо этот момент тоже не до конца раскрыл, но, как уже и писал, статья не была готова и опубликовалась случайно. Подправлю в полете.
Спасибо за статью и за ссылки, часть объявленных принципов в свое время пришлось подтверждать примерами, что бы начать перестраивать процесс, но теперь я могу это делать более аргументированно.
тестирование - это всего-лишь один из способов управления рисками, и альтернативные способы развиваются очень быстро
Что за альтернативные способы, которые не подразумевают даже запуск программы и сравнение ожидаемого поведения и фактического?
1. трудно найти;
2. трудно подготовить;
3. Готовят их со спецификой продукта, т.е. при переходе специалиста его снова приходится доучивать.
Исходя из этого спрос на них, как я считаю, будет расти не долго. Потом будет расти спрос на SDET и на QA. Спрос на QA вернется, потому что у QA огромная зона ответственности. от нее будут понемногу «откусывать» и выделять новые должности, спрос на QA будет похож на синусоиду. Спрос на SDET уже сложно спрогнозировать, все таки, как мне кажется, отправная точка — QA.
Границы между QAA(SDET, возможно будут еще переименования) и QA не будут стираться, наоборот произойдет четкое разделение зон ответственности. Именно разделение зон ответственности позволяет компаниям уменьшить кадровые риски. Причин по которым в долгосрочной перспективе произошел откат к «универсалам» я не вижу.
Прежде всего, огромное спасибо за развернутый и аргументированный ответ!
Мои взгляды на судьбу SDET еще более нетрадиционные:
Посмотрите, пожалуйста, видео, интересно ваше мнение
Вполне традиционные, но как мне кажется такое решение опять же временное, как показывает опыт(прошло два года после https://habr.com/ru/post/492054/), разработчики не очень хотят развивать инструменты для автотестирования, но это вполне возможно из-за их топорности(инструментов), неразвитости подходов и простой логики. Несколько SDET должно быть в компании, они бы мониторили развитие инструментов, осуществляли обновление, писали моки для внешних систем, осуществляли поддержку infrastructure as code для тестовых стендов, осуществляли code review и пр. Сейчас разработчики и так должны мониторить очень большой спектр инструментов, у многих есть pet проекты для обкатки новых технологий, добавлять ещё десяток инструментов для "e2e" уже лишнее, инструменты слишком разные.
ок, тогда что насчёт tdd? оно же, в теории, может покрыть 100%
и другой вопрос, почему ПО должно быть сверхсложным? почему это не может быть самообучающаяся нейронка?
1) Какой код мы забыли написать (конфликт покрытия кода и покрытия требований)?
2) Какой код\функционал не надо было писать?
3) Какие риски и пограничные значения возможны?
Тем не менее, TDD обеспечивает достаточно высокий уровень качества, настолько высокий, что во многих бизнес доменах позволяет обойтись без тестирования в принципе. Но TDD — это метод разработки; классическая автоматизация тестирования — это что-то другое.
И даже в случае TDD (что позволяет нам обходить ограничения от проблемы останова и закона Эшби за счет сужения общей задачи до большого количества частных) решение о релизе и уровне (дилемма лица, принимающего решения) принимает человек.
А про нейронку — потому что самообучающаяся нейронка — это сверхсложное ПО из палаты мер и весов) Даже хуже. В нейронке сложность столько не на уровне кода, сколько на уровне обучения (чем учили, как переучивали, какие поправочные коэффициенты, как это все дело хранится, как доучивается?), что повышает сложность и уменьшает способность контролировать результат на порядок.
про нейронку это было мое любопытство. согласен, слишком сложно.
возвращаясь к нашим баранам:
>> 1) Какой код мы забыли написать (конфликт покрытия кода и покрытия требований)?
а при чем тут вообще тестирование? это чистой воды административные решения. это ошибки того кто составлял ТЗ
>> 2) Какой код\функционал не надо было писать?
так же, пишите ТЗ правильно.
>> 3) Какие риски и пограничные значения возможны?
я конечно в третий раз повторюсь, но это все указывается в ТЗ.
в моем видении мира тдд очень дорогой и ресурсоемкий процесс разработки который мало компаний себе может позволить, но если все выстроенно качественно он закрывает огромное кол-во вопросов, если не все. а перечисленные Вами выше исключительно не головная боль разработчика. сказано на входе 5 на выходе 8, за 200мс, вот и все)
а при чем тут вообще тестирование? это чистой воды административные решения. это ошибки того кто составлял ТЗ
Это хорошее замечание. Давайте я приведу пример: например мы выпускаем сайт на территории, ну, скажем, Башкартостана. Зафигарили мы значит сайт, а добавить функцию выбора языка забыли. Я исхожу из предположения, что обратить на это внимание и задать вопрос — это часть процесса тестирования.
так же, пишите ТЗ правильно.— тестирование требований я тоже отношу к тестированию.
Если исходить из модели, что тестирование — это взять ТЗ и банально проверить выполнено ли это ТЗ в точности как написано, то да. Это можно автоматизировать, но это является очень упрощенным и поверхностным пониманием, что такое тестирование.
Вами выше исключительно не головная боль разработчика. сказано на входе 5 на выходе 8, за 200мс, вот и все)— к сожалению, такая логика не выдерживает критики в суде. Например уже были преценденты, когда инженер был признан виновным за добавление функционала «точно по ТЗ» (кейс VW).
В нашем университете мы вполне себе серьезно обсуждаем вопрос является ли «выполнил по ТЗ» достаточным аргументом в пользу защиту подсудимого, и необходимо ли обучение программистов этике.
Я понимаю аргументы тех, которые считают, что «делаем по ТЗ, а дальше — не наша головная боль», но чисто по человечески я на стороне тех, кто считает, что программист\тестировщик зачастую обладают бОльшей эксперизой, чем те, кто пишут ТЗ, а потому должны указывать на проблемы в ТЗ и не делать «черни», даже если она указана в ТЗ) Именно поэтому у меня такая забавная должность.
Ну и самое главное — в большинстве случаев разработки ТЗ уже как-то и не пишется, а люди приходят с проблемой, которую нужно решить. Например, «хочу автоматизировать производство». И ТЗ в данном случае — просто этап производства продукта, за который МЫ несем ответственность.
Я не брал в рассчет «чернь», имелось в виду что ТЗ разработано должно быть с учетом всех необходимых фич. Даже если команда разрабатывает ТЗ, кто-то должен об этом позаботиться. Ну т.е. условно представьте что это потом действительно сбагрят индусам и они будут писать строго по ТЗ.
И Вы пишете
>> Ну и самое главное — в большинстве случаев разработки ТЗ уже как-то и не пишется
но… но ведь так нельзя особенно с тдд…
Т.е. при классическом (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
Могу быть не прав, но моё имхо такое, что полностью заменить мануала на автотестирование (насколько оно глубоко проработано не было) на живом и постоянно развивающемся проекте, невозможно.
Автотестирование хорошо подходит для сценариев в которые не вносятся изменения. Но для поиска новых "входов" требуется мануал, плюсом отыгрывать нестандартные человеческие сценарии (открывать новую вкладку сайта не через нажатие ссылки, а через ctrl+клик / нажатие на ролик мыши) которые машина не сможет воспроизвести (или не сможет описать) что не менее важно.
Также признаюсь все комменты я не прочел, возможно кто-то поделился схожими мыслями.
И да, и нет, я потому и уточнил про постоянно развивающийся проект.
В проекте где уже все давно реализовано и настроено (к примеру какая-нибудь црмка для ТСЖ) новые баги (если таковые будут) могут найти пользователи, и это нормально.
Но если система активная (релизы каждую неделю) и включают в себя новые фичи, автотест на это не написать быстро, плюсом нужно проверить изначально не только как работает, но и насколько удобно реализовано, сколько шагов требуется до выполнения той или иной функции. Тестирование же много чего может в себя включать... И проверку "удобности" неавтоматизировать...
Тестирование Usability не относится к автоматизированному тестированию, но данная часть может быть выполнена ui/ux designer, в этом случае привлекать тестировщиков для этого становится необязательно.
«теоретически невозможно написать программу достоверно валидирующую другую программу» — теоретически невозможно создать человека достоверно валидирующего программу, вопрос только в том кому вы больше доверяете.
Публикации
Может ли автоматизированное тестирование заменить ручное?