Тесты по требованиям и багрепортам
Пишет автотесты по требованиям и превращает баг в регрессионный тест
Тема готова к старту: сузить до MVP и работать
Область и границы
четыре роли · четыре ответаКому больно — и можно ли этого человека спросить?
QA-инженер или разработчик пишет тесты по задачам и разбирает прод-баги — работа регулярная и вечно в долг
Почему это не решается одним вызовом модели?
Требование написано словами, а тест — код, который должен запускаться и падать по делу. Проверить его нельзя иначе как выполнением, и он попадает в чужой репозиторий
Где должен появиться результат и что здесь необратимо?
Результат — pull request в репозиторий команды: код вливают люди и он остаётся в проекте
Что будет считаться успехом?
Тесты принимают без переписывания, а прод-баги перестают возвращаться второй раз
Багрепорт от пользователя с инструкцией и попытка провести через тест изменение кода, которое никто не просил
Есть публичные наборы или открытые данные; живой контекст добирается разговором
Открытые репозитории с историей багов и тестов — материала больше, чем нужно. Свой учебный проект даёт вторую половину: требования, написанные командой
О чём тема
Требование живёт в задаче, тест — в репозитории, и связь между ними держится на памяти команды. Система читает требование или багрепорт и предлагает тест: что проверяем, при каких входных данных, какой результат считается верным. Пришедший из прода баг превращается в регрессионный тест, который больше не даст ошибке вернуться. Тест уходит в PR — принимает его человек.
Зачем это людям
Связать требования с проверками и закрывать каждый прод-баг тестом, а не обещанием.
Что предстоит выяснить
ответов здесь нетГотового решения в каталоге нет намеренно: тема задаёт область и границы, а что и как строить — работа команды. Это и защищают на приёмке.
Взять эту тему
Тему из каталога берёт любая команда, одобрение не требуется. Одну тему могут взять несколько команд — на Demo Day видно, насколько разошлись решения.