Нет ничего нормального)

если у кого нет ничего нормального - надо начинать с юнит-тестов тогда :)

такая спорная статья

легко конечно отформатировать "только для США" - а в настоящей системе будут пользователи и из Зимбабве, и тогда автору придётся форматировать номер и согласно предпочтениям жителей Зимбабве, а какие у них там предпочтения? может у автора таблица предпочтений есть, какое форматирование предпочитают жители всех стран?

ну или пользователь будет из США а номер не из США, тогда опять же будет путаница

про тестирование всех видов вычета в каждой рамке - наверное даже глупо. 

разве в коде будет отдельная имплементация этого вычета для каждой рамки? для вычета будет конечно же отдельный юнит

вычет ведь не зависит от рамки, значит нет смысла придумывать попарное тестирование там, где его нет, и конечно же автоматизированное тестирование поможет нам запускать все эти ненужные тесты

 

 

все img с alt

главное не забывать, что стандарты постоянно меняются, и многие стандарты уходят в небытие

 

Т.к. предварительно не были выдвинуты требования для проведения тестирования тележки, будем исходить из ниже изложенных параметров.

В качестве вводных данных будем использовать такие параметры тележки:

            1. Металлический корпус корзины из прутьев объемом 140л.

            2. 4 колеса

            3. Пластиковая рукоять с замком-монетопремником принимающим монеты номиналом 10р.

            4. Откидывающиеся сидение для ребенка возрастом 1-2 лет

первая ошибка тестировщика - даже не узнал не спросил что тестируем как тестируем и какие требования, но уже сам додумал что и как

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

это для собеседования?

как по мне, так модели с машинным обучением должны тестировать дата-сайентисты (специальные люди со специальным образованием и скиллами), ведь обычные сотрудники ничего не поймут, правильные ли данные возвращает модель

это то же самое как и с математическими моделями или другими сложными системами - только профильные специалисты могут их понимать

ну или если есть сотрудник или студент желающий "копать поглубже", который будет читать книжки и постоянно сидеть в Jupiter Notebook

наверное таких людей можно находить просто задав вопрос: "а Вы работали с Jupiter Notebook?", если работал то попросить показать свои проекты, или даже набросать какое-то решение

 

В зависимости от задач можно какую-то эквивалентность выстроить.

Больше интересует как отлавливать эксепшены бота, когда процесс переводится на ручную обработку.

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

 

 

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

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

 

 

2) В статье нигде не указано, что валидация производится именно в интерфейсе. 

всё там указано, что именно через интерфейс. например "Click Submit without filling in the text field"

 

 

3) А вы действительно считаете, что валидацию тестировать не нужно? Или нужно, но не так?

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

ну во первых Джеквони замахнулась на тестирование безопасности, учит других но по факту "слышала звон но не знает где он" - не понимает элементарного принципа работы инжектов.

Ей кажется что код типа "скрипт" не должен попасть в базу данных иначе это считается атакой, хотя это совершенно нормально, например попробуйте создать тикет в Джире со скриптом в поле Summary. Это ведь поля отображения надо защищать, чтобы они отображали код а не запускали его

Ей кажется что надо делать интерфейсную валидацию чтобы не допустить "вредоносный код" в базу, несмотря на то что РЕСТ протокол будет полностью открыт

Как указано выше, она сразу начинает ломать поле вместо того чтобы исследовать как работает фича, и работает ли вообще

представляете, как Джеквони замедляет свою команду разработки десятками бессмысленных багов про "правильную интерфейсную валидацию"

 

 

Опытные тестировщики: если вы чем-то не довольны - пишите, предлагайте свои варианты, не нужно писать комментарии в духе "все говно". Таких комментариев уже большая часть, полезных почти не осталось :-(

ну эти статьи это же такой "юмор для тестировщиков" насколько я понимаю, откуда тут серьёзности взяться? на каждую её статью (которых очень много) серьёзных комментариев не хватит сил и сарказма писать :)

спасибо за перевод! всегда интересные статьи про тестирование от учителя музыки

 

 

4) "сразу начинает ломать поле" -- статья про валидацию!

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

 

 

1) "Джеквони замахнулась на тестирование безопасности" -- нет, не замахнулась, она замахнулась на "способ подтолкнуть вас к размышлениям о большом количестве тестов, которые можно прогнать, тестируя единственное поле", и среди прочего упоминает, что можно выполнить тесты, которые более опытный тестировщик отнесёт к области тестирования безопасности, но новичок должен хотя бы понять, что такие тесты надо выполнять и почему их надо выполнять.

 

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

 

А что написано в этой статье?

Попробуйте межсайтовый скриптинг – введите такой скрипт: <script>alert("I hacked this!")</script>. Если при нажатии на Submit появится всплывающее окно – значит, поле уязвимо для XSS-атаки.

Это же правда (хотя и не вся правда), если появится всплывающее окно -- уязвимость действительно есть (другое дело, что если не появится -- это ещё не значит, что уязвимости нет, но это уже другой уровень!)

да в том то и дело, что не надо выполнять такие тесты, которые не нужны. Валидации "скрипт" не место в интерфейсе (ну может и место, но только в отдельных редких случаях). 

 

 

3) "РЕСТ протокол будет полностью открыт"

это указание что валидация на "скрипт" не нужна в интерфейсе

 

 

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

я отлично отношусь к "популяризационным" статьям. Особенно которые не углубляются туда куда не надо, и где нет понимания. Если бы Джеквони спокойно тестировала поле, то и отлично. Но она обычно начинает "охоту на ведьм", постоянно изобретая никому не нужные валидации и фичи типа "номер телефона должен быть форматирован", "валидация на скрипт должна быть в интерфейсе"

ведь юные тестировщики начитаются и начнут это все применять на практике, создавая ненужные тикеты

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

 

P.S. Кстати, вот в таким стиле комментировать статью -- это гораздо лучше, чем ехидничать про учителя музыки.

ну такой вот уровень статьи...

про автоматизацию то же самое, сама не разобралась но дает постоянно рекомендации

видимо она знает только про Е2Е автоматизацию но не слышала про компонентные тесты, иначе бы у нее например не возникали проблемы с большим количеством полей на одной форме

 

 

граничные значения, которые кстати представленная таблица не учитывает. 

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

наверное все перевели

решение же принимается по таблице

https://gufo.me/dict.../decision_table

эта модель странная какая-то как по мне

 

 

Мы получили 5 рабочих кейсов и бонусом наглядное представление процесса. Совсем не трудно, правда? :)

правда ли эти тесты рабочие? как я вижу возврат средств тестируется два раза, один раз ДО распечатки билета, и второй раз ПОСЛЕ распечатки билета

как вообще наличие распечатки билета влияет на возврат средств, это неясно

 

 

Тестирование локализации с помощью автоматизации и через интерфейс это какой-то извращенный метод, на мой взгляд) 

"О! Месье знает толк в извращениях!"

 

 

ЕСЛИ сумма <=200 И сумма >=499,99, ТО скидка = сумма/100*2.

тут видимо скорее:

ЕСЛИ сумма <=200 ИЛИ сумма >=499,99, ТО скидка = сумма/100*2

а вообще да, "значение в середине" это избыточный тест, но его всегда и все делают, типа как Богу помолиться, это не поможет но всё равно так делают

а вообще правда в том, что надо все величины внутри проверять, начиная с 200.00, затем 200.01 и так далее до 499.98 и 499.99

ведь если понимать как программа работает, то будет понятно что все эти числа в программе хранятся в переменных, часто достаточно в больших, и потом с этими переменными происходят разные рассчёты и конвертации, в конце концов эта сумма приводится обратно к читаемому значению

и получается что иногда некоторые значения могут неправильно округляться, например 213.27 может превратиться в 213.28, хотя все числа рядом будут обрабатываться правильно

но конечно по методу границ таких проверок не надо делать

 

 

Но почему надо делать все равно -- понятно.

наоборот говорят же, не надо его делать

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

наверное мало информации так как все пользуются http://rest-assured.io/

 

Спасибо! 

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

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

 

 

Ответ "спроси свою команду, вы же за все отвечаете"

правильный эджайльный ответ

хороший тестировщик должен уметь сам себе находить себе работу, так как он лучше всех остальных знает что надо делать

 

 

На вашем проекте вас никто учить не будет, не будет никакой "помощи старшего"

помощь старшего можно получить, просто надо знать "как"

сравните:

тестер Иван: уважаемый дев, у меня нет базовых и вообще никаких знаний разработки, научите меня пожалуйста программировать и покажите как тут что, конечно в рабочее время

тестеровщица Маша: я тут прочитала книгу по программированию, уже посмотрела авто-тесты на проекте, я могу помочь с их написанием и поддержкой. И вот еще просмотрела Ваш пулл-реквест, объясните пожалуйста вот этот именно момент в этом изменении

смотрите в код пулл-реквестов, установите на свою машину среду разработки, разбирайтесь с проектной документацией и с требованиями, коллаборируйте с ПМом и дизайнером и кто у Вас там еще

прочитайте книгу по языку разработки который используется на проекте - вот и получите базовые знания