Мне практика нужна

Во-во, практики бы

а вы тоже убучаетесь?

Четыре задачи по личному проекту: хотя бы один баг и одно улучшение должно быть. Остальное как вам больше нравится.

Как оформлять

Тема — заголовок бага / улучшения
Описание — описание задачи (шаги, результат, ожидаемый в баге или все описание улучшения)
Исполнитель — назначить на тренера (см ниже)

Процедура сдачи такая:

1. все баги, которые вы считаете готовыми - вешаете на Первый тренер. В СДО ничего не присылаем!!

2. когда Первый тренер сочтет их готовыми - перевесит их на другого тренера (Ольгу Киселеву).

3. когда вы поправили баг (не важно по каким комментам - первого тренера или второго) - вы опять вешаете его на первого тренера

4. только после того, как второй тренер напишет "Принято" и поставит статус Resolved (Обработано) → задача зачтена.

Как только примут все задачи, вы присылаете мне ссылку на все баги в СДО и сразу получаете "Зачёт"!

.

Если ваш баг исправили, но в описании все зафиксировано и есть доказательства (скрины), баг мы примем. Просто в описании задачи в доп информации укажите "На такое-то число баг исправлен", чтобы было понятно, почему не воспроизводится.

у всех такая ересь  с курсхантером?

А у вас в баг репорте обычно что первее идет - Actual result или  Expected result? И почему?

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

У меня шаги, потом экшуал, потом экспектед.
Почему?...
1. Нас так учили.
2. Так как оно идёт сразу после шагов это (ИМХО) логичнее. Как подведение итоге после действий, а потом то, как должно быть.

Ну да, вполне логично

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

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

всё это немного смахивает на прокрастинацию)

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

Я не Арсений, но везде, где сталкивался, по логике шло:
1. Шаги;
2. Ожидаемый результат;
3. Фактические результат.
Кто проверяет он смотрит на ожидаемый сначала, а потом что получилось у автора :)

Встречал в примерах ТК при обучении,  у testbirds и Яндекс

Я тоже в июне там получила сертификат 😁 и помню то задание очень хорошо. Оно одно из самых трудных. Можно потестить в данном случае работу фильтров, насколько удачно категоризируется товар, верстку опять же. Наличие ошибок/опечаток. Но Яндекс это сложный проект, у них все обычно на десять раз проверено

И как тебе их курсы в целом ? Ты уже работаешь? Попробую поискать.

Все зависит от учащегося, конечно же, но на мой взгляд это лучшие курсы 😁😁😁

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