Где брать идеи для тестов (подборка полезных ссылок)

Я, кстати, видела и подробные ТЗ, с скринами из GUI и описанием каждой финтифлюшки. ТЗ на авторизацию в системе там занимало 5 листов вместо 2 строчек)) Угадайте, как быстро такое устаревает)

Поле ввода, на платформе apple, android, и во множестве популярных web-фреймворках, ведет себя внезапно строго по style guide платформы/фреймворка.

То есть, есть документ, в котором рассказано, каким должно быть поведение. Конечно, базовые случаи, типа при вводе «а» появляется именно «а», видимо нужно проверить, но кажется, такого рода проверки пишутся один раз для всего проекта, по одному комплекту на один тип ui-контрола, не? При добавлении нового нового view/экрана/итд, вызывают готовый комплект базовых тестов для этого типа контрола.

нет, у меня почти никогда не было ТЗ. Но первое, что я в этом случае делал — писал ТЗ, а не пытался «что-то сделать, похожее на деятельность». Причина этому простая — если мне ставят задачу недостаточно четко, для её выполнения, с высокой вероятностью, результат моей работы не будет принят с первого раза (а скорее всего со второго, третьего итд), и с еще более высокой вероятностью, суммарные затраты на переделки будут выше, чем сначала «договориться на берегу» — написать ТЗ, хоть в каком-то виде, по которому можно будет принять работу, а потом уже приступать к работе.

Это настолько общий принцип любых коммерческих отношений, что даже удивительно, что приходится его объяснять.

будьте добры, покажите примеры статей, где пишут, что в scrum/kanban/agile не предполагается документация. Боюсь, вы путаете с «не предполагается отдельной фазы проектирования всего продукта, до начала работ».

Если взять семейство agile-методик, у которых ключевой момент — короткие итерации, то насколько короткой итерацию не делай (хоть вообще один день), всегда есть «заказчик», «исполнитель», «ожидаемый результат». Ожидаемый к концу итерации. Записывают его на доске, в issue или просто встретившись утром у кулера обмениваются парой-тройкой фраз, если исполнителю не будут понятно, что от него ожидают — скорее всего, он сделает какую-то фигню не то, что ожидают.

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

Очень странно рассчитывать, что за фигню будут платить. Еще более странно платить за фигню, хотя окружающая действительность как бы говорит, что так поступают чаще, чем хотелось бы. Успокаивает только то, что ожидаемый результат платят значительно больше (на порядки?) чем за фигню.