Есть много мнений на этот счет. Тут, например, это toggle button: https://www.usability.gov/how-to-and-tools/methods/user-interface-elements.html

В остальном whatever, тут нет единого правильного варианта.

о спс!

Не за что, первая ссылка в гугле.

Так что за авторитетность источника не отвечаю.

В андроидовых гайдлайнах, кстати, тоже toggle button

а если нарисовано как слева, а работает: по клику (как справа, предположительно) ? тогда наверное ToggleButton ?

ToggleButton - когда кнопка и надо кликать

Switch - тогда надо двигать ))

switch - анимация передвижения положения курсора toggle - анимация выключателя)

https://www.w3schools.com/howto/howto_css_switch.asp

переключатель переключения?

https://material.io/guidelines/components/buttons.html#buttons-toggle-buttons Хмм.

https://material.io/guidelines/components/selection-controls.html#selection-controls-switch

не понятно почему Toggle переводится как тумблер, тумблер вроде совсем другое

https://material.io/guidelines/components/selection-controls.html#selection-controls-switch

гугловскому material можно доверять, я думаю)

гугловскому material можно доверять, я думаю)

Ну, если не считать, что оно слабо коррелирует со всем, что за пределами материала и андроида - да.

Но в целом там довольно наглядно описана разница.

Привет! Хотел спросить про негативные тесты в Selenium. Каким образом их проводить? Например для login - Просто ввести неверные данные и удовлетвориться exception в логах, или же нужно писать отдельный тест, где ждать соответствующего сообщения о неверных данных и после их появления сообщать, что тест успешно завершен?

я отдельный тест писала

Привет! Хотел спросить про негативные тесты в Selenium. Каким образом их проводить? Например для login - Просто ввести неверные данные и удовлетвориться exception в логах, или же нужно писать отдельный тест, где ждать соответствующего сообщения о неверных данных и после их появления сообщать, что тест успешно завершен?

мы пишем отдельные тесты. На введенные неверные данные у приложения все равно должна быть реакция, ее и ждем в тесте

Спасибо

а кто как считает: Вот есть например требования на абстрактную простую форму логина: 1. При введении корректных данных - логинить пользователя 2. При введении неверного пароля и/или логина несуществующего пользователя - выдавать сообщение о неверных авторизвационных данных 3. При введнии не всех данных: нет логина/нет пароля - выдавать сообщение "Заполните все поля" Допустим мы пишем АТ на это дело: Кейс 1: положительный - Ввели Логин и пароль существующего пользователя А кейсы на требования "выдавать ошибку..." - они положительные или отрицательные ?

наверное корректнее: позитивные или негативные ?

сообщения о "мягком" срабатывании системы на ошибки называется негативным тестированием

если ты проверяешь попапы js на валидацию формы, то это негативное тестирование

наверное корректнее: позитивные или негативные ?

негативные.

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

хм, верно ли тогда трактовать, что Любая ситуация, в которой данные формы не проходят валидацию (бэк/фронт - не важно) - будет считаться Негативным тестированием ?.. Или может я поспешно запихал все под одну гребенку ?..

а вы запихали это все под одну гребенку - это какое-то физическое действие? )

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

хотите соответствовать ISTQB дефинициям?

да нет, я пытаюсь свою картинку сформировать: что считать негативным, а что позитивным )

вот например есть у Бизнеса требование - Хотим что бы тут цифру 55 не пропускало в форме - писало ошибку валидации

а все остальные цифры - пропускать

вот тест на то, что 55 вызывает ошибку валидации и сообщение на форме - это позитивное или негативное ? ..

Negative testing ensures that your application can gracefully handle invalid input or unexpected user behavior. For example, if a user tries to type a letter in a numeric field, the correct behavior in this case would be to display the “Incorrect data type, please enter a number” message. The purpose of negative testing is to detect such situations and prevent applications from crashing.

вот например есть у Бизнеса требование - Хотим что бы тут цифру 55 не пропускало в форме - писало ошибку валидации

абстрактная форма с полем, в которое можно ввести число любое и кнопкой "отправить"

Negative testing ensures that your application can gracefully handle invalid input or unexpected user behavior. For example, if a user tries to type a letter in a numeric field, the correct behavior in this case would be to display the “Incorrect data type, please enter a number” message. The purpose of negative testing is to detect such situations and prevent applications from crashing.

Только вот от этого многие отходят.

не цепляйтесь за дефиниции и топтанные дорожки :) только и всего

Ну типа ты все равно тестируешь успешную обработку чего либо

в то время как потроха кода возбуждают исключение

это key difference

Соответственно этот тест ничем не отличается в сущности, от обработки нормального теста и лишь является его подмножеством.

ну дак а по итогу то: Да, это предусмотренное значение - вроде как тест Позитивный С другой стороны: это то значение, которое вроде как не приведет к активации какого-то экшена в системе: вроде как Негативным может быть...

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

понятие придумали чтобы отграничить из 1000 польз. кейсов 10 - нужных для бизнеса (и пользователя) от 990 тех, которые все же считаются незавершенным\некорректным поведением

тоесть ты всегда тестируешь ожидаемое поведение. просто это ожидаемое поведение разное. данные валидны -> ожидаемое поведение: success login данные не валидны -> ожидаемое поведение : login failure, something wrong

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

тоесть тест не негативный сам по себе. эта негативность несёт в себе мало семантики.

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

> тоесть тест не негативный сам по себе. а какой тогда в вашем понимании негативный тест

для меня нет такого понятия)

окей, ребят спасибо, я сформировал себе картинку )

> негативность несёт в себе мало семантики негативность теста несет в себе СЛИШКОМ много семантики

я просто тестирую Expected поведение. Всегда ожидаю ожидаемый результат) если мои ожидания совпадают - тест успешно прошел. Нет - фича не работает.

потому что это 90% того, что можно делать с программой, убивать ею людей, покупать яхты на чужие деньги, и т.д. и т.п

я просто тестирую Expected поведение. Всегда ожидаю ожидаемый результат) если мои ожидания совпадают - тест успешно прошел. Нет - фича не работает.

негативное тестирование пошло от юнит тестов

> негативность несёт в себе мало семантики негативность теста несет в себе СЛИШКОМ много семантики

не плодите сущности. Слышали о таком принципе?)

где проверяется assertRaises

всё

не плодите сущности. Слышали о таком принципе?)

бритву Окама? слышал. А дальше че?

где проверяется assertRaises

проверяется падение) Проверяется уожидаемое поведение) Так в чем отличие от позитивных?)

дело в том, что оно отличается лишь на словах. в корне мы всегда обрабатываем нормальное(ожидаемое) поведение системы.

ERROR: S client not available

спросите об этом Антона ;)

тесты то одинаковые. Кейсы разные. Тесты не становятся от этого негативными.

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

тестируешь на то, что будет ошибка - ожидаемое поведение: ошибка. В чем негативность?

так и есть, потому что в TDD когда разработчик будет фиксить это поведение, по хорошему он пишет юнит тест, где будет возникать соответствующий эксепшн

и будет проверять его возбуждение

приложение должно обрабатывать ошибки. обрабатывать валидации и тд. Это нормально поведение системы.

тестируешь на то, что будет ошибка - ожидаемое поведение: ошибка. В чем негативность?

перечитайте плз мое сообщение, что negative testing пошел из юнит тестирования

перечитайте плз мое сообщение, что negative testing пошел из юнит тестирования

ничего не меняется)

Ребята проводят конкурсы по тестированию, у них миллионная аудитория, и я, будучи не тестировщиком постоянно вижу ошибки и недоработки

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

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

цель же, чтобы система нормально обрабатывала раазные кейсы.

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

даа это стандарт.

я выделил 3 категории: 1. Позитивные кейсы - там где предусмотренное поведение по бизнесс логике 2. Предусмотренные исключения - там где экшен в системе может не стартовать, при определенных условиях 3. Негативные кейсы - там где НЕ предусмотрено поведение системы т.е.: по п.2 - каждый сам решит, какие это для него, если ему это надо будет )

для себя все это естественно )

тестируешь на то, что будет ошибка - ожидаемое поведение: ошибка. В чем негативность?

тестирую те случаи, в которых будет перехват некорректного ввода, НЕ будет какого-то крэша и будет сообщение об ошибке ЛИБО ошибки вообще НЕ будет примерно такая костыльная семантика негативности

золотые слова о костыльной семантике)

я не могу понять за что Дима топит

кто мне распарсит

я выделил 3 категории: 1. Позитивные кейсы - там где предусмотренное поведение по бизнесс логике 2. Предусмотренные исключения - там где экшен в системе может не стартовать, при определенных условиях 3. Негативные кейсы - там где НЕ предусмотрено поведение системы т.е.: по п.2 - каждый сам решит, какие это для него, если ему это надо будет )

да всё равно в каждой компании свои соглашения по этому поводу

семантика QA в этой стране сама по себе много где костыльная

за то чтобы перестать делить кейсы на позитивные или негативные?

я не могу понять за что Дима топит

я о том, что негативных тестов нет как таковых. Тест есть тест. Он либо провален, либо не провален. Мы всегда тестируем успешную обработку чего либо. Мы всегда тестируем на ожидааемое поведение. Где негативность в этом?)

да, примерно за это

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

не нужно вкладывать в это новый смысл. Есть дефиниции

которым как жкскрементам мамонта уже лет

не нужно вкладывать в это новый смысл. Есть дефиниции

которые не точные ?

Ну ладно, в корне ничего не меняется, как не называй.

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

Согласен

я выделил 3 категории: 1. Позитивные кейсы - там где предусмотренное поведение по бизнесс логике 2. Предусмотренные исключения - там где экшен в системе может не стартовать, при определенных условиях 3. Негативные кейсы - там где НЕ предусмотрено поведение системы т.е.: по п.2 - каждый сам решит, какие это для него, если ему это надо будет )

Зачем изобретать велосипед, если всё давно изобретено?