(“sunny day” scenario and “rainy day” scenarios, aka basic course and alternate courses

Вру, да. "Нетипичные" пользовательские сценарии тоже ушли в "Rainy"

Что бы это, черт возьми, не значило.

In another comment I read some about «sunny day» and «rainy day» testing scenarios. Sunny day means test all the common situations (including the possible / expected wrong situations). In a rainy day scenario will be tested the behavior of the system in exceptional situations.

Вру, да. "Нетипичные" пользовательские сценарии тоже ушли в "Rainy"

Спасибо, тогда рухнувшую базу засун таки в дождики.

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

т.е. база рухнула по сценарию?

Спасибо, тогда рухнувшую базу засун таки в дождики.

А лучше просто откажитесь от этих безумных терминов. :)

А лучше просто откажитесь от этих безумных терминов. :)

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

А вносить какие-то изменения (или хотя бы предложения по этим изменениям) можно только тимлидам? :)

В прочем whatever.

А вносить какие-то изменения (или хотя бы предложения по этим изменениям) можно только тимлидам? :)

Ну точно не в рамках выполнения ТестЗадания, но ты тоже прав.

Я бы поставил отдельную звездочку почета за тестовое задание, в котором человек напишет "Но вообще деление на Sunny\Rainy - какой-то маркетологический буллшит, лучше использовать более распространенные и устоявшиеся термины (напр. Негативные\Позитивные сценарии), т.к. это более прозрачно для всех участников и не требует объяснения каждый раз". ;)

Я тут недавно услышал ещё такое определение: деструктивные кейсы

?‍♀️

не факт что рекрутер это оценит

?

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

Но это не точно.

Я тут недавно услышал ещё такое определение: деструктивные кейсы

А что не так?

т.е. база рухнула по сценарию?

Нет, как раз что "ЭТО КАКОЙ ТО ДОЖДЛИВЫЙ КРАЙ". Полностью сценарий, это что сервис который лазиет в базу тебе нормально ответит что "дорогой пользователь, а база то что-то не читается, попробуйте обратиться ко мне позднее". Например.

не факт что рекрутер это оценит

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

Ладно, следующий вопрос, тут больше мнение интересно. В http сервер прилетает post с данными и ожиданием, что по этим данным будут найдены соответсвующие данные. Какой код статуса должен отдать сервер, в случае, если он обработал запрос, но не нашёл подходящих данных? Я разрываюсь между 404 (который кмк больше для недоступности подходит), просто 400 или 204, например.

А почему тебе кажется, что валидный ответ сервера должен возвращать ошибку, тем более client-side ошибку?

200 или 204 выглядит оптимальным вариантом.

я бы возвращал 200 но с пустыми данными, если сервер отработал корректно

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

200 или 204 выглядит оптимальным вариантом.

просто 204 не даёт тело с пояснениями воткнуть, как я понял. А 200 - это технически логично, да, но обычно на статус завязывается обработка ответа, нет?

просто 204 не даёт тело с пояснениями воткнуть, как я понял. А 200 - это технически логично, да, но обычно на статус завязывается обработка ответа, нет?

Обработка ответа завязывается на статус и контент. Если вам достаточно статуса - то 204 вам подходит. С таким же успехом можно использовать 200 и пустой results в теле ответа трактовать как отсутствие контента для показа.

Оба варианта валидны, в общем-то. Никакой особой разницы нет.

Спасибо

1. 200 и [ ] 2. 200 и { error: "no results" }

Если на интерфейсе необходимо написать сообщение то 2 вариант

1. 200 и [ ] 2. 200 и { error: "no results" }

За error в 200 надо по рукам бить

200 это успешный запрос. Он не должен возвращать ошибок. Вообще никогда. Пустой результат в данном случае - не ошибка, а валидное поведение, откуда там вообще error?

{ msg: "label text or alert text", data: "" } Js: if (data.msg) $(label).text(data.msg)

Имелся ввиду ui error, согласен без error правильно

Кажется как обрабатывать пустой респонз на фронтенде - уже совсем другая история.

Ну тогда можно 200 и длинна контента 0

Ну тогда можно 200 и длинна контента 0

200 и content-length=0 записать в http header

Дальше все зависит от договоренностей с фронтендерами и client side, на самом деле.

Кому то проще длинну result в ответе проверить и если == 0 -> обработать. Кому то хэдерами. Кому то мессаджем.

Тут скорее главное консистентность API.

Полностью согласен)

А есть ещё web sockets)

200 это успешный запрос. Он не должен возвращать ошибок. Вообще никогда. Пустой результат в данном случае - не ошибка, а валидное поведение, откуда там вообще error?

А как иначе бизнес ошибку рест клиенту передать?

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

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

странное у вас представление) возможно пора сменить компанию

странное у вас представление) возможно пора сменить компанию

А можешь пару аргументов? А то живу вот в своем мирке и много не знаю. Завтра вот приду и начну обсуждать с разработкой область видимости, нейминг методов и вот это все

А можешь пару аргументов? А то живу вот в своем мирке и много не знаю. Завтра вот приду и начну обсуждать с разработкой область видимости, нейминг методов и вот это все

не хочу, ты грубый. Не обсуждай и будь дальше тестером

Чотка

какой вопрос такой и ответ

Быть тестером не плохо. Вопрос в том, что вы можете и должны участвовать в таких вещах между фронт и беком

Они то многое между собой могут нарешать, но проверять это вам ;)

ERROR: S client not available

просто почему-то печет от слова тестер

Меня больше печёт, когда девы говнокодят

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

У вас вопрос не в объектах между фронт и бек, а об ответах в апи

он же сказал, что живет в своем мире

А апи отвечает не объектом данных?

Так у вас же не нашлось данных для ответа )

А контракт зафиксирован?

У вас? Ну я хз

@RichardGears

Быть тестером не плохо. Вопрос в том, что вы можете и должны участвовать в таких вещах между фронт и беком

Ты можешь обсуждать даже целосообразность фичи с овнером и просить от него данных подробнее, или даже можешь с дизайнером поспорить, что макет надо переделать и тут вот тут неудачно сделали, потому что.... аргументы Все члены команды могут внести свой вклад. Почему нет?

это МУЛЬТИМЕТР прошу не путать

прошу не флудить

Ты можешь обсуждать даже целосообразность фичи с овнером и просить от него данных подробнее, или даже можешь с дизайнером поспорить, что макет надо переделать и тут вот тут неудачно сделали, потому что.... аргументы Все члены команды могут внести свой вклад. Почему нет?

Так и делаю?

?вчера был на собесе в конторку, опять хотят нанять девопа и уволить 3 qa

кубернетис главный враг qa

?вчера был на собесе в конторку, опять хотят нанять девопа и уволить 3 qa

Ты же их разубедил?

Ты же их разубедил?

это бесполезно, сейчас мода такая увольняем qa dba сетевика билд инженера и берём devops

Всё, разбудили Хрыча, теперь этот чат превратится в флудилку для повышения чсв персонажа

Ребятки , а нет канала с полезными статейками и тд ?

кинул, проверяй

?вчера был на собесе в конторку, опять хотят нанять девопа и уволить 3 qa

Как это в принципе связано ?

Только в голове хрыча и связано.

Как это в принципе связано ?

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

удивительно