Как выглядит правильный процесс тестирования?

Всем привет!
Я работаю в тестировании почти год после курсов, пошла, так скажем, туда, куда взяли.
Но начали закрадываться сомнения, что наш процесс тестирования работает не верно. Попробую описать простыми словами: на функционал у нас создаются задачи(в этой задаче обычно маленький кусок функционала), после тестирования этой задачи прикладывается(прям в комменты к задаче в трекере) тест-кейс с конкретными проверками по данной задаче. Конкретные сомнения начались, когда новый аналитик начал задавать мне вопросы почему мы тестим не по постановкам(документации), а по задачам.(на курсах мы тоже писали чек-листы и кейсы на документацию, а не к задачам) Эти тест-кейсы в конечном этапе "улетают в трубу", потому что никто их не хранит, не систематизирует и не фасует по разделам проекта. Получается, что как таковой нормальной документации у проекта вообще нет, хотя проект большой, есть несколько компонентов, связанных между собой, интеграции с другими системами. Были такие случаи, когда кусок функционала вообще не был протестирован, потому что не было задачи и это выяснилось прям уже перед финалом тестирования, просили создать задачу, чтоб потом к ней приложить тест-кейс.
Баг-репорты мы пишем прям в комментариях к задаче, а не создаем отдельные тикеты в спринте.
Лиду говорила, что у нас с процессом что-то не так, но в ответ получаю что-то вроде "исторически так сложилось, иди работай".
Коллеги тестировщики, расскажите пожалуйста, как у вас налажен процесс тестирования, куда вы вносите тестовую документацию для регресс-тестирования и как ведете себя, когда попадается баг в старом функционале и в новом, который только готовится для релиза. Прикладываете ли тест-кейсы к конкретным задачам и правильно ли это? Было бы здорово, если бы рассказали пошагово что у вас происходит от новой постановки на функционал до вывода сборки в релиз. Спасибо
  • Вопрос задан
  • 1041 просмотр
Решения вопроса 1
M23
@M23
Привет.
1) Заводить баги и тест-кейсы/чек-листы надо отдельно от задач, так как правиться и проверяться они могут сильно позже, когда задачу давно уже закрыли. Например, регресс. Писать в комментах к задаче - плохая практика :)
2) Кейсы пишутся на документацию к задаче, а не на то, как реализовали. То есть тестовая документация пишется еще до того, как ты приступила к тестированию.
3) Написанные кейсы можно прилинковать к задачам и наоборот.
4) Тестовая документация, баги и задачи могут находиться в разных TMS. Например, кейсы/чек-листы в Allure, а задачи и баги в Jira. Или все в Jira, но в отдельном плагине. Тут уж как в компании заведено или какие вы используете TMS.
5) Баги заводятся как отдельные таски в бэклог. Если это новый функционал, который в работе, то может будет удобнее, если напрямую передашь разработчику и он сразу поправит.

P.S. Сходи к коллегам из других команд (если такие есть) и посоветуйся с ними. В дальнейшем разговоре с лидом можно будет ссылаться на их мнение. Но менять процесс определенно стоит.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@cute_foxx73
Привет. Я на одном проекте уже 2,5 года.
В среднем и кратко процесс выглядит так,

пишут требования
разработка
когда задача готова к тестированию я знакомлюсь с требованиями, продумываю как тестить, замечания по текущей разработке оставляю в комментариях MR, разрабы фиксят и тд. Баги которые найдены по готовому функционалу создаю отдельными issue.

у нас на проекте отсутствуют тест-кейсы для ручного тестирования, так уж сложилось, никогда их не писала, но есть много автоматических тестов
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы