а то и чаще

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

Ну ты еж определишь что форма не работает

Но при этом ты сможешь проверить дальше

тут получается разница в подходе ведь? разве нет?

Да

И каждый решает

Простой пример. Два теста: 1. Проверка возможности создания пользователя через форму регистрации. 2. Проверка что созданный пользователь сохраняется и им можно авторизироваться. Есть два частых варианта реализации. 1. И в первом и во втором тесте пользователь регистрируется через кнопочку "Регистрация". 2. Первый тест регистрирует пользователя по UI кнопке. Второй тест делает прямой POST запрос регистрации, а потом по кнопочке "Логин" авторизуется.

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

Ну ты еж определишь что форма не работает

Кирилл, давайте без мата? Здесь люди разные.

я очень ранимый?

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

нужно переписать тест, если добавили фичу ) это логично вроде )

Но обычно такой подход логичнее. Ведь если что-то ломается или меняется, так часто удается сэкономить время

сори)

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

нужно переписать тест, если добавили фичу ) это логично вроде )

а какова цена такой поддержки?

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

Если это сломает логин, вы поймете. А если это влияет дальше - сломается другой тест.

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

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

ага

А можно так не делать)

и чтоб тестик быстро прогнался

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

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

и чтоб их было много и они все были зеленые и збс

и чтоб тестик быстро прогнался

Ведь мы ж прогнали и у нас зелено

О_о

нароооооод

Ведь мы ж прогнали и у нас зелено

КАКОЙ С НАС СПРОС!

я ж не говорю упускать функционал

дак урезая шаги сделанные через сам продукт вы упускаете функционал

просто максимально сделать независимым

Нет

Другой функционал - в другом тесте

при ручном тестировании вы тоже успешность входа зареганого юзера будете регать юзера через пост?

просто максимально сделать независимым

от кого? У вас там Америка, чтоли? что она от всех независимая?)

при ручном тестировании вы тоже успешность входа зареганого юзера будете регать юзера через пост?

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

при ручном тестировании вы тоже успешность входа зареганого юзера будете регать юзера через пост?

у них какие-то неправильные подходы, коллега, бог им в помощь

Баг будет найден

Баг будет найден

баг упущен, вы ж обход делаете

мне кажется Ручные тестировщики и Автоматизаторы - думают по разной схеме ?

баг упущен, вы ж обход делаете

2. Первый тест регистрирует пользователя по UI кнопке. Второй тест делает прямой POST запрос регистрации, а потом по кнопочке "Логин" авторизуется.

мне кажется Ручные тестировщики и Автоматизаторы - думают по разной схеме ?

для меня автоматизация - как доп помошник

Где он упущен

ткни меня

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

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

ткни меня

вот

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

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

при ручном тестировании вы тоже успешность входа зареганого юзера будете регать юзера через пост?

_

для меня автоматизация - как доп помошник

мне просто показалось что вы рассуждаете как ручной тестировщик, потому что кейса автоматизации для более гибкой поддержки должен быть атомарным и в этом Кирилл, на мой взгляд, прав. Хотя и в словах Егора есть правда: если тесты спроектированы плохо - то грош им цена :)

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

точно! Атомарный) Забыл это слово)

мне кажется Ручные тестировщики и Автоматизаторы - думают по разной схеме ?

Автоматизатором лишь бы автоматизировать и больше тестов, больше тестов больше видимости работы, так чтоли? Это как ручники зачкастую думают что чем больше багов в багтрекере тем лучше они провели тестирование

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

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

мне просто показалось что вы рассуждаете как ручной тестировщик, потому что кейса автоматизации для более гибкой поддержки должен быть атомарным и в этом Кирилл, на мой взгляд, прав. Хотя и в словах Егора есть правда: если тесты спроектированы плохо - то грош им цена :)

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

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

это как?)

вот

ню?)

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

а можешь сказать: проект крупный или небольшие проекты ?

Слышали про тестирование серого ящика?)

мне для праздного интереса

а можешь сказать: проект крупный или небольшие проекты ?

угу, крупный

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

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

+ если что-то отдельно по БД надо проверить

Слышали про тестирование серого ящика?)

есть мнение, что серого ящика не существует.

Ты про выполнение ручного тестирования перед автоматизацией чтоли?

?

Ты про выполнение ручного тестирования перед автоматизацией чтоли?

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

ERROR: S client not available

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

Это да, логин то явно проверят, но какой-то функционал могут оставить только автотестам и по их зелености сделать вывод, и что тогда? Лично я за то чтобы автотесты писались используя черный ящик. Есть возможность работать в продукте с заранее подготовленным тестовым обхектом - пожалуйста, вот тебе и атомарность, а иначе будь добр выполняй всей шаги из тест-кейса по которому автоматизируешь\

Select в базу автотестом это ручное тестирование средставами автоматизации?

есть мнение, что серого ящика не существует.

Точно есть. Когда тебе тупо не дают доступ :D

Точно есть. Когда тебе тупо не дают доступ :D

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

Select в базу автотестом это ручное тестирование средставами автоматизации?

нет

а как тогда

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

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

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

именно)

Это да, логин то явно проверят, но какой-то функционал могут оставить только автотестам и по их зелености сделать вывод, и что тогда? Лично я за то чтобы автотесты писались используя черный ящик. Есть возможность работать в продукте с заранее подготовленным тестовым обхектом - пожалуйста, вот тебе и атомарность, а иначе будь добр выполняй всей шаги из тест-кейса по которому автоматизируешь\

да я кажется понял про что вы: Это случай когда состояния системы зависят от входных параметров и не очищаются на промежуточных итерациях. Т.е. условно мы можем получить эффект бабочки в программе: залогинился не так - и баг при каком-то другом действии. Мне кажется такой кейс автоматизировать конечно можно, но с точки зрения затрат может оказаться не рентабельно, если таких случаев в реальности не много. Хотя какой-то смысл написать какой-то длинный кейс автоматизации на основе "1 day of user" - можно....

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

угу. согласен.

серый - это когда вы проверяете исходный код, кейсами, которыми проверяют чёрный ящик

Черный - ты клацнул на кнопку, зарегался и перевходом можешь проверить. Серый - ты клацнул на кнопку, зарегался, а потом проверил логи, и оценил запись в базу

серый - это когда вы проверяете исходный код, кейсами, которыми проверяют чёрный ящик

Это белое, юнит-тесты

хотяяяя, мутная формулировка, не уверен)))

Это белое, юнит-тесты

юниты обычно еще уже: на класс или на метод пишуться

это да

Slow простите что опять возвращаюсь, но где я там упустил таки багу?)

Два теста: 1. Проверка возможности создания пользователя через форму регистрации. 2. Проверка что созданный пользователь сохраняется и им можно авторизироваться. Есть два частых варианта реализации. 1. И в первом и во втором тесте пользователь регистрируется через кнопочку "Регистрация". 2. Первый тест регистрирует пользователя по UI кнопке. Второй тест делает прямой POST запрос регистрации, а потом по кнопочке "Логин" авторизуется.

дак урезая шаги сделанные через сам продукт вы упускаете функционал

Вот

для автоматизации нужны свои ТС или универсальные ТС, просто ручной тест != тест для автоматизации.

для автоматизации нужны свои ТС или универсальные ТС, просто ручной тест != тест для автоматизации.

можно ТС расшифровать?..

можете внятно объяснить почему так?

TEST-CASE скорее всего

это тут ссылка выше была и там первое в ней это этот пункт

http://software-testing.ru/library/testing/testing-automation/2388-true-automation

Помимо всем известных прописных правил эффективной автоматизации, таких как: для автоматизации нужны свои ТС или универсальные ТС, просто ручной тест != тест для автоматизации.

получается что это не совсем так?

Ну я пока не могу придумать наглядный пример этому утверждению

"для автоматизации нужны свои ТС или универсальные ТС, просто ручной тест != тест для автоматизации."

Я вот смотрю на это утверждение

Ну вот есть простой пример в котором ручной тест не подойдет как тест для автоматизации?