Как стать автором
Обновить
221
0
Ольга @Molechka

Пользователь

Отправить сообщение

К этому надо стремиться! Особенно если ты тестировщик =)

А почему неправильно? У меня оба варианта сработали)

Да, на темно-зеленом фоне это вообще скриншот из моей презентации в уроках

Да, спасибо) Хотя по факту тут "сама виновата", что не ставлю водные маркеры на картинки. Но мне жалко их "портить". Так что вполне логично, что они расходятся по интернету. И это даже хорошо! Я принимала этот риск, отказываясь от водных маркеров)

Автор может и не знать, откуда картинка, просто нагуглил. А так да, картинка с http://testbase.ru/book-beginner взята)

Примерно поэтому в первом пункте я говорю "то, что ответ вернулся типа хороший" — ещё ни о чем не говорит)) И надо проверить, что регистрация реально отработала.

Спасибо за комментарий, думаю, его будет интересно людям прочитать! :)

Спасибо, интересно)

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

Могут, да. Но чем лучше его вообще не тестировать 5 раз, чем протестировать 1 раз и потом после всех правок проверить, что не сломалось? Ведь ваш вариант как раз "вообще забить до того, как всякие баги починят"

У тестирования может быть только один артефакт - найденный баг,

А, для вас тестирование — это чисто поиск багов... Ну тогда да, надо "крушить и ломать"...

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

Не очень понятно, откуда такие крайности — то есть или тестировать N раз (сколько вернули в редев) одни и те же сценарии, или не проверять их вообще. Что мешает проверить в первый раз и потом после окончательных правок?

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

Всегда пожалуйста ^_^

К сожалению, очень сложно ответить что-то на абстрактное "без объяснения причин" — где нет причин? Много примеров, есть истории из жизни "почему это надо проверять", что как раз поясняет.

"Много частностей" — каких? Есть теория, есть практика, на примере конкретного метода конкретного проекта. Я считаю, что так лучше усваивается материал, но если не хочется погружаться в конкретный пример, то можно просто пропускать все блоки "Практика на примере Users"

Мне сложно ответить на то, кто был первоисточником. Но есть "позитивные" сценарии, когда пользователь идет по задуманной ветке использования, и есть "негативные", когда он попадает в условный эксепшен. Но вообще это не строго "это всегда позитив, а это негатив", это всегда просто градация "что в данном случае позитивныее" https://okiseleva.blogspot.com/2018/12/blog-post_24.html

Спасибо, обдумаю этот вариант =)

Поправила, спасибо

Ну, когда у автора очередь из издателей, он может нос воротить ))

Тогда уж 12%, вы же учитываете что "что получил сотрудник" != "что заплатила компания за него"?)

Не понимаю нелогичности, при чем тут тестовые задания художникам и сайт? Будет время / возможность, сделаю. Нет — ну сорри

Вполне заслуженные слова! )

Согласна с Ralph, денег на книге вы не заработаете много, к этому надо быть готовым)

Информация

В рейтинге
Не участвует
Откуда
Россия
Работает в
Дата рождения
Зарегистрирована
Активность