Alexej Simakov

Вы сказали подрядчику сделать систему и не сказали, что она должна уметь, а теперь не знаете как проверить, что сделал подрядчик? Эээ.. и никто не знает.
Как выйти из этой ситуации. Конечно, подрядчик скорее всего внедрил какое-то типовое решение, раз он согласился на выполнение без перечня требований. Нужно выяснить, что за решение он внедрил и какие возможности оно дает. Тогда уже и сверять годится ли система для выполнения ваших бизнес-сценариев или нет.
С другой стороны у вас есть бизнес сценарии, берите и проверяйте можно ли с предложеной системой их реализовать. А в случае если не понятно где кнопка "создать новый проект" звонить подрядчику и выяснять как работать с системой, либо просить его это это изменить под понятную вам последовательность действий.

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

С другой стороны странно, когда подрядчик не настаивает на конкретизации требований. Обычно крупные конторы имеют аналитика требований котоый будет вас "пилить" пока вы не расскажете ему "все о чем мечтаете".

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

Это просто кровавый энтерпрайз. У нас тоже так. У нас разрабы сразу говорят: "Не пытайся понять все это сразу, тебе понадобится минимум полгода чтобы понять и освоить устройство приложения и его частей [на таком уровне, чтобы работать автономно]."
Вам нужно больше задавать вопосов коллегам. Вы не успеете умереть от стыда - вопросы кончатся быстрее:)
Как молвит японская поговорка: "Спросить - позор на один раз. Не знать - позор на всю жизнь".
У нас например один из архитекторов добровольно сделал курс обзорных презентаций (3 раза по часу) по архитектуре приложения и это здорово помогло. Спросите тимлида, может он подговорит какого-нибудь опытного программиста или архитектора на такое доброе дело. Все понимают что новичкам надо помогать. Но сами по себе они не бросят все, чтобы заполнять ваши пробелы. Но все без проблем поделятся опытом. Это же для любого человека приятно - показать свои знания. Так что вы не бойтесь, они только на вид такие неприступные. Сядьте рядом с каким нибудь особенно разговорчивым и веселым коллегой. Он вам будет потихоньку все обьяснять. Посмотрите как он анализирует баги, и задавайте вопросы, это много дает. Никто не ожидает что от вас на первых порах будет много пользы. Так что не переживайте. Но все оценят если вы будете быстро впитывать полученные знания. У нас некоторые новички за 3 месяца освоились а некоторые и за год не в зуб коленом.

Это регрессионные тесты, в том случае, если эти тесты/проверки в состоянии распознать ухудшение в каком-то аспекте качества приложения, после внесения изменений.
Юзабилити тесты могут быть регрессионными. Мы лепили дизайн лепили, а потом выясняется что пользоваться стало невозможно сложно. Регресс в юзабилити. В перформансе или безопасности тоже может быть регресс. Разные аспекты.
Как правило, регрессионное тестирование автоматизируют, потому что человеку свойственно забывать о темных углах своего приложения.

у вас "#answer1" ".error1" "#q1" все - строки, создавайте их конкатенацией с индексом, как-то так "#answer"+i.toString(); и.т.д а потом вставляйте в скобки.

Как писать бестселлеры не привязываясь к языку. Нет, не получится. У каждого языка своя парадигма, свой менталитет. Читать много. То что понравится брать на заметку. Читать про сами языки, как они возникли, какие проблемы они хотели решить когда были созданы. Какие возможности эти языки предлагают, читать сравнительные статьи, холивары даже. Читать код всяких библиотек и sdk. Он обычно написан опытными программистами.
Изучатъ историю становления компьютерных вычислений как дисциплины. Пробовать разные языки, хотя бы на уровне базовых туториалов. Про паттерны почитайте. Например www.gameprogrammingpatterns.com - там рассматриваются некоторые в контексте разработки игр. В контексте игростроя вообще концепции легче воспринимаются, это область применения которая понятна и знакома практически любому человеку. Так же, например если хочешь получить практические навыки в автоматизации, нет ничего лучше чем начать с написания игровых ботов. Игры такой контекст который задействует практически все технологии и области компьютерных знаний.

Возможно чат-бот не решит вашу проблему.
Почитайте обязательно это:
Эпик-фейлы в онлайн-чатах, или почему продажи не растут
Если бездумно впилить чат-бота то у вас станет одной проблемой больше. Клиенты станут уходит еще и потому что нет личного контакта, а от бота кроме стандартных чаще всего бесполезных ответов ничего не добьешься.

Вполне вероятно, что вы пытаетесь решить не ту проблему. Проблема в том. что количество запросов возрасло - нужно понять почему. Может недостаточные описания на сайте? Может часто отправляют не то что заказывали. Оптимизировать нужно иммено в узком месте.
Почитайте про теорию ограничений. Хотя бы эту одну статью:

Как теория ограничений помогает зарабатывать больш...

В любом случае, сначала займитесь анализом - сгруппируйте темы запросов в кластеры.

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

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

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

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

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

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

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

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

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

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

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

у нас в договоре прописано, что любая другая работа только по согласованию с работодателем.

Узнаю себя четыре года назад, тогда казалось щас будем двигать горы, ну или как минимум бурить тоннель. А оказалось мы на них будем взбираться. В шлепанцах.

А горы все выше, а горы все круче, а горы уходят под самые тучи
— Айболит

Тест-менеджер, должен понимать специфику приложения, специфику проекта, чтобы принимать обоснованные решения.
Я по своему опыту могу сказать видение того как нужно поставить процесс тестирования, как распорядиться человеческим ресурсом (и своим ресурсом в том числе) эффективно, приходит только через 3-5 лет. Только тогда избавляешься от крайностей и начинаешь видеть компромиссные решения. Только тогда начинаешь думать о стратегии тестирования. Потому что успел на своем опыте убедиться что работает а что нет. Где рамки возможного. Лучше начинаешь понимать психологию команды.
И соответственно стратегия тестирования она для каждого проекта своя. А чтобы понять, что для этого проекта важно, нужно в нем повариться.
И начинать нужно с низов. Вы должны побыть и программистом, и автотестером, и ручным тестировщиком, и девопсом немножко. Изучить продукт, и код достаточно, чтобы когда программист рассказывает, что в коде он сейчас меняет сразу было ясно какие три-четыре проверки на продукте нужно будет провести.

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

https://www.artlebedev.ru/everything/process/
тут студия Лебедева рассказывает как создаются их продукты, от задачи к решению, с картинками.
А еще на главной странице можно выбрать любой представленный продукт и там прочитать секцию "процесс".