KiT Maverik

Одна из стадий тестирования это генерация репортов.
Соответственно, раз кто-то его тестил должны быть как минимум логи или список объектов проверок (чеклист).
Кроме того, как клиент, вы должны были предоставить ТЗ, в котором четко указать что вам надо (ваши бизнес-цели). Если продукт не может выполнить эти бизнес цели, значит он не завершен. Можно ругаться.

Еще возможен вариант "А я сам проклацаю и все ОК будет". Если контора себя так повела и запросила с вас оплату за тестирование - это недобросовестно. Если вы как заказчик решили сэкономить на профессиональном тестировании, то нечего плакаться.

Вам стоит проверить компетенцию своего ментора. Утверждение "полностью протестировать" противоречит фундаментальному принципу тестирования "Exhaustive testing is impossible".
Предлагаю обеспечить достаточный уровень качества. К определению оного подойдем с менеджерской стороны.
Нет спецификации? Нужно ее сделать. Предлагаю следующий способ: представляете себе что с точки зрения бизнеса наиболее важно в этой форме (примеры: поиск существующего объекта, защита от SQL-инъекций, поиск по дополнительным настройкам, обработка ошибок таких как поиск несуществующего объекта) и засовываете это в список. ВАЖНО: включать в список только те пункты без которых форма не может считаться рабочей или удовлетворяющей требованиям бизнеса. Список озаглавливаете "Acceptance criteria" и несете заказчику на подпись. Без этой подписи он имеет полное право парить вам мозг вопросами типа: а что ты это (или то) не протестировал? А с подписью вы будете иметь документ определяющий достаточное качество на уровне user acceptance.
Тесты прошли? Значит критерии приемки соблюдены. Хотите больше тестов? Согласовываем новую спецификацию, дополнительный бюджет на тестирование и расширяем тестирование на новый уровень (надеюсь ваш ментор про уровни тестирования рассказывал?).

Отдать школе тестирования как подопытный проект?

В отношении дизайна?

Макетом.

Самый простой способ проверки соответствия макету это браузерная расширялка "Pixel Perfect".

В добавок к делам макетным можно провести:

• Кросс-браузерное тестирование. Посмотреть как себя ведет верстка на разных браузерах. Можно проводить топорно (на множестве браузеров в режиме один за другим), а можно воспользоваться утилитой "Browser Sync".
  
• Мобильное тестирование (если респонсив предусмотрен).
  
• Проверить унифицированность интерфейса. Интерфейс продукта должен быть однородным. Это не только красиво, но и улучшает ориентирование, интуитивность.
  
• Потестить правила форматирования инпутов. Как они хендлят слишком длинные значения, как отображаются хинты...
  
• Проверить usability продукта. Провести базовую проверку удобства использования. Например: навешал девелопер много модных анимашек и гордится этим; а клиент задалбывается ждать, пока необходимые элементы красиво приплывут из-за экрана. Эффект этого гэпа усиливается при многократном обращении к элементам.
  
• Проверить accessability продукта. Это проверка восприятия продукта людьми с ограниченными возможностями. Ну, это вариант для тех кому уже совсем делать нечего или просто денег слишком много. Тестируется с помощью различных браузерных надстроек.
  

Мне кажется ты смешиваешь мух и котлеты в блендере.

ВВОДНАЯ

• Функциональное тестирование это вид тестирования. Всего их два: функциональное и нефункциональное. Функциональное тестирование проверяет функционал продукта - ЧТО он делает. Нефункциональное проверяет характеристики функционала - КАК он это делает (пример: скорость загрузки сайта).
  
• Компонентное тестирование это уровень тестирования. Всего их 4: приемка, системное, интеграционное, модульное. Различаются они (!не запоминать - очень кратко!) глубиной проверки системы. Модульное тестирование это насколько возможно подробное тестирование одного компонента (изолированно).
  

ОБОСНОВАНИЕ
Глоссарий ISTQB

1. component: A minimal software item that can be tested in isolation.
   
2. component testing ("unit testing" and "module testing" are synonyms of CT): The testing of individual software components. [After IEEE 610]