Я джун, ручное тестирование. 

Попала на стартап. 

Задача: написать тест-кейсы на мобилку (iOS). 

Документация: только макеты. На макетах есть процесс аутентификации, регистрации, карта с кластеризацией и прочее прочее.

 

Пока у меня получается отстойно, на мой взгляд.. 

Что-то из разряда: 

Название: 
iOS: Авторизация. Проверка функционала "Демо доступ"
Предусловие: 
Открыта страница авторизации
Шаги: 
1. Нажать на кнопку "Демо доступ"
ОР:
Открыт экран Карта

Или на вёрстку ОР (выделенные названия беру из макетов): 

Группировка по городам и Группировка в рамках города: Цвета маркеров (S): фиолетовый, оранжевый и серый. Дизайн: круглые точки с наполнением, представляющим либо число, либо иконку молнии

Более приближенный вид и Максимально приближено: Цвета маркеров (M): оранжевый и фиолетовый. Дизайн: название, индикатор, мощность

Маркер геолокации: серый

Я бы хотела у старших узнать: был ли у вас опыт написания ТК только по макетам и как вы с этим справились? Как разделяли эти ТК по верстке и функционалу? 

Я принципиально не пишу ТК по верстке, потому что в этом смысла нет. В чем суть ТК? Открыть страницу, сверить с версткой, ОР - все как в верстке? Верстку я исследовательским путем тестирую. А чтобы понимать, как один экран превращается в другой, возьмите аналитика и трясите, пока не родите по результатам схему состояний и переходов. Тогда у вас будут функциональные кейсы.

У нас в мобильном продукте есть отдельная Stage версия, в которой мы тестим все исправления и новые фичи.
И только после того как в Stage версии прошли все ручные и автотесты, отправляем её в Production. Потом тестим прод и после успешного теста прода заливаем его в маркет или стор.
То есть Stage у нас - как песочница, в которой можно крутить-вертеть версию и тестировать до талого. Этих Stage версий может быть много, но хорошим тоном является, конечно, минимум таких билдов.

Так стейдж у всех есть, вопрос в том, насколько он на прод похож. Если на прод он похож, как троюродный брат с синдромом Дауна - смысла в нем не очень много)

Тут в основном люди пишут, что сначала ФР, а потом ОР, а я думаю, что удобнее ФР в конце писать, потому что, как правило, он больше - туда крепится вся инфа о произошедшем: логи, запросы/ответы, скрины и т.д.

Все вышесказанное наводит на мысль, что да - людям часто удобнее смотреть в начало и конец написанного. Кроме того, маленький ОР не затеряется где-то в конце баг-репорта

Если люди читают только начало и конец, могут с тем же успехом вообще баг-репорт не читать. Ну и не надо логами и скринами разносить тело задачи, файлами крепите или под спойлеры, это любой трекер умеет, и никаких Огромных Фактических Результатов не будет. 99% моих ФР занимают максимум 3-4 строчки.