Учусь писать test cases, нужна тренировка

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

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

Напишите тест кейсы для тестирования почты яндекса

Напишите тест кейсы для тестирования почты яндекса

This is very funny. Можно очень долго писать тест кейсы. Очень-очень.
Вот попробовала написать тестовые случаи на первую страничку регистрации (поля ввода имени, фамилии и логина). Вот гуглдокс (архив с екселем и парой скринов) (В прикрепленных файлах оно же)

мельком посмотрела )
С точки зрения подробности, терминологии и т д мне тоже интересно, что скажут гуру. Потому что я пишу примерно так же (когда есть время), но мою работу никто никогда не ревьювил(
Я всегда стараюсь быть предельно краткой без ущерба для смысла, потому что не только писать долго, но и читать, и воспринимать тоже.

Что касается тестовых случаев, то не хватает дублирования логина и др параметров, проверки на устойчивость к кросс-сайт скриптингу (по скольку все-таки веб-приложение), и со служебными символами я бы предложила другой вариант (см тут: http://blog.shumoos.com/archives/67) + отдельно проверка того, что в логине нет второй собаки.

При выборе требований к логину при отсутствии документации я бы руководствовалась стандартами протокола. К примеру, лично для меня спорно, что длина логина ограничена 30 символами, ведь протокол позволяет 64, так же и недопустимость ввода подчерка (_), ведь протокол "не против". По-моему, это повод поспорить с аналитиками

проверки на устойчивость к кросс-сайт скриптингу (по скольку все-таки веб-приложение)

А поподробнее?)

проверки на устойчивость к кросс-сайт скриптингу (по скольку все-таки веб-приложение)

А поподробнее?)

своими словами )

кросс-сайт скриптинг - это уязвимость. Для хакеров вариантов использования - масса, о них лучше расскажет интернет : )
С точки зрения тестирования - это выполнение на странице у пользователя зловредного кода, который какой-то другой юзер-злодей туда занес. Например, в качестве комментария, подписи, чего угодно. Этот зловредный код может воровать куки.

Пример: у меня в закладках elefant.ru (давно нашла на него ссылку где-то в инете, но его за долгие годы не починили). Попробуйте поискать, например, <input type=button onclick=alert('Hack')>, и увидите, что код выполнится, а не отобразится "как есть".

Почему это надо проверять?
Вроде для поля логина это не критично, если, конечно, этот логин не будет виден другим пользователям. НО! Никогда нельзя знать наверняка И доверять никому нельзя
Например, бывает, что некоторые серверные фреймворки без правильной конфигурации и корректной обработки просто не пропускают такие данные на сервер, и приложение просто падает.
Важно смотреть, как такой код будет отображаться на разных страницах.