Чувствуется, что у вас первый-второй небольшой проект, требующий внутренного тестирования. Все как-то поверхностно и спустя рукава.
Боль 1: управление процессами
Где храните все таски на будущее: фичи, доработки, переработки продукта? Часто они тоже лежат в системе управления проектом, чтобы и активность отслеживать и время затраченное видеть. И знать в каком релизе ожидать.
Боль 2: оторванность разработки от QA
Чат спорное решение, если проект большой и разрабы работают над разными частями. Обычно разрабы знают, что они передали релиз на тестирование. Видят задачу на тестирование. А баги на них распределяет их лид. Но для маленького проекта в самый раз.
Боль 3: сроки
Метрики. У вас ни слова о них. Да, если тестите одно и то же давно, то сроки уже опытным путем установлены. А вообще от сложности тест-кейса и считается от 10 до 30 минут на его тестирование, плюс процент на форс-мажоры.
Боль 4: рассогласование фронта и бэка
Тестирование api. Обычная работа для тестеров. Когда релизят новую версию api часто чисто ее и тестят.
Боль 5: повторные сообщения о багах.
У вас "странные" тестировщики, потому что их одна из первых обязанностей при заведении бага поискать не заведен ли уже такой. И про про структуру бага (название, приоритет, тело и т.д.) - это базовые знания, которые развиваются уже в первую неделю. Кажется, вам стоит провести обучение по этому вопросу.
Боль 6: ничейные задачи
Почему вы отдаете задачи QA-лиду. Это не особо его обязанность тыкать разраба в починку бага. Этим должен заниматься лид-разработки или ответсвенный за тот или иной блок по. Создать список и напомнить про них разработке можно, но висеть коршуном над ними - странно.