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