Для полной проверки ввода символов для имени пациента сделаем следующее, воспользовавшись граничными и эквивалентными значениями:
...
Попытаемся ввести 26 символов – неверное граничное значение, имя не введено
Медсестра копирует из экселя или из непойми как сделанной ситемы имя вместе со странными пробелами, символами новой строки и еще непойми чего и система зависает тк заложенный в строке тип данных не может справиться этими данными.
Или и того хуже имя проставляется, но по тем или иным причинам при событии "тревога" не может правильно активировать ивент.
В рамках предложенного контекста "медицинское оборудование", подобный риск - смерть пациента. Фокусироваться на так называемом Boundary value analysis которому "учит" ISTQB и проч. становится не просто плохо, а опасно.
"Здесь во фразу "заскриптованный сценарий", как мне показалось, вкладывается какой-то негативный контекст"
Скорее все обстоит наоборот, во фразе "теперь разработчик не только видит, что покрыто тестами..." вкладывается слишком позитивный контекст. Тут претензии можно выставить и к "видит" и "покрыто" и "тестами". Вы сами писали чуть раньше про пример где "тестами" была "покрыта" некая часть, но как оказалось они были зеленые доже когда на самом деле не работало ничего. Так откуда уверенность что и в другом случае оно "покрыто"?
Можно сказать что мы тут пытаемся протестировать собственную речь тк используя те или иные термины мы подвергаем себя влиянию предубеждения "bias". Так уж вышло что все вокруг говорят про Test Automation хотя это не "Test" и уж тем более не "Automation". Это заскриптованные сценарии которые совершают некие действия в определенном контексте и выдают некий результат, который "зеленый или красный" должен обязательно быть интерпретирован человеком. То есть "тупой" инструмент, причем затратный.
Почему я тут распыляюсь вокруг этого? Потому что вокруг нас люди с другим контекстом в голове которые во фразе "Да у нас автотестами покрыта регрессия" слышат что-то свое. В том числе эти люди распоряжаются бюджетами на разработку и тестирование.
Вкратце: мы когда-то потратили бюджеты сделали и использовали один фреймфорк который проходил некие заскриптованные сценарии, делал непойми что, выдавал "все красное" и не использовался при разработке, а теперь мы потратили бюджеты и используем другой. А еще наши КУА теперь пишут код вместо/те с разрабами.
Переформулируем некоторые вещи:
"Теперь разработчик не только видит, что покрыто тестами" - теперь разработчик видит код заскриптованного сценария который как вы считаете при определенных условиях выполняется и выдает некий результат.
"стало возможным делегировать команде разработки часть обязанностей тестирования в те моменты, когда QA становится узким местом" - разработчики создают коды подобных заскриптованных сценариев сами. Теперь заскриптованные сценарии пишут люди не имеющие к тестированию даже косвенного отношения.
"QA тоже стали подхватывать мелкие задачки из техдолга, до которых у команды разработки могли не доходить руки долгое время." - люди которых вы наняли как тестировщиков теперь делают чужую работу.
...
Попытаемся ввести 26 символов – неверное граничное значение, имя не введено
Медсестра копирует из экселя или из непойми как сделанной ситемы имя вместе со странными пробелами, символами новой строки и еще непойми чего и система зависает тк заложенный в строке тип данных не может справиться этими данными.
Или и того хуже имя проставляется, но по тем или иным причинам при событии "тревога" не может правильно активировать ивент.
В рамках предложенного контекста "медицинское оборудование", подобный риск - смерть пациента. Фокусироваться на так называемом Boundary value analysis которому "учит" ISTQB и проч. становится не просто плохо, а опасно.
"Здесь во фразу "заскриптованный сценарий", как мне показалось, вкладывается какой-то негативный контекст"
Скорее все обстоит наоборот, во фразе "теперь разработчик не только видит, что покрыто тестами..." вкладывается слишком позитивный контекст. Тут претензии можно выставить и к "видит" и "покрыто" и "тестами". Вы сами писали чуть раньше про пример где "тестами" была "покрыта" некая часть, но как оказалось они были зеленые доже когда на самом деле не работало ничего. Так откуда уверенность что и в другом случае оно "покрыто"?
Можно сказать что мы тут пытаемся протестировать собственную речь тк используя те или иные термины мы подвергаем себя влиянию предубеждения "bias". Так уж вышло что все вокруг говорят про Test Automation хотя это не "Test" и уж тем более не "Automation". Это заскриптованные сценарии которые совершают некие действия в определенном контексте и выдают некий результат, который "зеленый или красный" должен обязательно быть интерпретирован человеком. То есть "тупой" инструмент, причем затратный.
Почему я тут распыляюсь вокруг этого? Потому что вокруг нас люди с другим контекстом в голове которые во фразе "Да у нас автотестами покрыта регрессия" слышат что-то свое. В том числе эти люди распоряжаются бюджетами на разработку и тестирование.
Вкратце: мы когда-то потратили бюджеты сделали и использовали один фреймфорк который проходил некие заскриптованные сценарии, делал непойми что, выдавал "все красное" и не использовался при разработке, а теперь мы потратили бюджеты и используем другой. А еще наши КУА теперь пишут код вместо/те с разрабами.
Переформулируем некоторые вещи:
"Теперь разработчик не только видит, что покрыто тестами" - теперь разработчик видит код заскриптованного сценария который как вы считаете при определенных условиях выполняется и выдает некий результат.
"стало возможным делегировать команде разработки часть обязанностей тестирования в те моменты, когда QA становится узким местом" - разработчики создают коды подобных заскриптованных сценариев сами. Теперь заскриптованные сценарии пишут люди не имеющие к тестированию даже косвенного отношения.
"QA тоже стали подхватывать мелкие задачки из техдолга, до которых у команды разработки могли не доходить руки долгое время." - люди которых вы наняли как тестировщиков теперь делают чужую работу.