Позитивный тест кейс, как?

Ох уж эти "протестируй все"...
Без спецификации вы не можете тестировать. У вас нет т.н "оракула". Оракул в тестировании это то как вы определите, что наблюдаемое поведение приложения является багом. Может это ошибка, что логин может иметь до 50 символов, может быть должно быть допустимо до 256. Не имея спецификации, как я считаю, можно проверять не изменило ли приложение своего поведения между двумя релизами, тогда вашим "оракулом" будет поведение предыдущей версии программы. И то, вы не знаете может это не регресс, а прогресс.

Но вы можете пользоваться своим мироощущением и жизненным опытом в качестве оракула, если нет спецификации. Но тогда результаты тестирования будут зависеть от тестировщика. Сами понимаете, это немного странно.

Грамматические ошибки это негативное качество. Репортить конечно. Тут у вас хоть будет на что сослаться, есть Правила Русского Языка ;-).

Вот это видео посмотрите, доходчиво обьяснено про классы эквивалентноси и граничные значения.
Разработка тест кейсов по методике Pair wise. Ники...

В тесткейсе указываются входные условия, действия и ожидаемый результат.
Если вы напишите на все приложение тесткейсы у вас получится полная спецификация. Получается что приложение определяет спецификацию, а не спецификация приложение. Значит у нас эталонная реализация. Но если она эталонная, то в ней нет ошибок, и тестировать ее не нужно. Парадокс :)

По плану тестирования (навскидку, подробности додумаете сами):
Общее:

• Нужно проверить все статичные ссылки. Можно написать для этого автоматизацию.
  
• Проверить грамматику и содержание (что в тексты не закопипастили по ошибке ерунду)
  

Функциoнальные области я бы разделил на категории, например:

1. Управление учетной записью
   1. Регистрация
      
   2. Вход
      
   3. Смена пароля
      
   4. Восстановление пароля.
      
   5. Удаление
      
   
   
2. Управление списками дел
   1. Добавление (списка или задачи)
      
   2. Просмотр
      
   3. Удаление
      
   4. Изменение
      
   
   

и т.д. каждый подпункт будет иметь множество тесткейсов .т.е то что нужно проверить при .. смене пароля, удалении элемента списка и.т.д.

Вобщем, я вам не завидую, но опыт систематического анализа функционала (как составление плана тестирования) это очень важный навык.

Всё смешано в кашу.
Думаю вам надо основательно почитать по теории тестирования и разобраться, где и что.
Граничные значения и классы эквивалентности, а так же примеры их применения, гуглятся по запросу "Практики тест дизайна". Ну, или в любой книге по тестированию ПО.
Если коротко: это про то, что разнообразные значения параметров, приводящие к одному и тому же результату нет смысла перебирать и можно схлопнуть их до минимума проверок.
Напр. если у вас валидной датой рождения является 1910 - 2000 год -> вам нет смысла перебирать все значения от -MAX_INT до + MAX_INT, вам достаточно проверить >1910, 1910, 1911 - 1999, 2000 и > 2000.
Т.к. по сути у вас есть 3 класса эквивалентных кейсов: пользователь указывает слишком раннюю дату рождения, пользователь указывает дату рождения в допустимом промежутке и пользователь указывает слишком позднюю дату рождения.
Плюс к этому добавляется проверка границ этих интервалов - т.е. конкретных кейсов на границе каждого класса.
Это позволяет определить, что границы классов проходят именно по нужным вам значениям (1910 - 2000), а не раньше\позже.



По поводу классификации тесты на позитивные и негативные.
Здесь всё просто. Позитивные кейсы проверяют работоспособность сценариев при ожидаемом поведении пользователя.
Напр. вбил валидный емейл и пароль, они совпадают с теми, что есть у зареганного ранее пользователя -> авторизация прошла успешно.
Нажал кнопку "Восстановить пароль" -> на почту ушло письмо с восстановлением пароля.
И т.д.

Негативные сценарии покрывают ситуации, когда пользователь сознательно или случайно делает что-то не так - начиная от валидации значений, до дублирования запросов, всяческих инъекций и прочего.
Напр. кейс "Перевести деньги с карты -> Нажать назад в браузере -> Перевести ещё раз" будет негативным -> необходимо проверить, что предыдущий стейт страницы (в котором деньги ещё не выведены с карты) не даст пользователю вывести больше, чем у него есть.